Advanced Search

PhracturedBlue wrote: My Tx is still stuck on the slow-boat, so I can't talk to the design, but I think Jumper should slow down a little. As I've said before, many iterations of the Tx is bad for us. It is hard to manage on the software side. First, we really need them to provide a method of detecting the hardware version (something stored in the bootloader probably). Next, I would then rather have them provide a list of specific features they plan to implement in the next revision that we could then discuss. I get the feeling they are over-eager here, and trying to appease everyone as quickly as possible is a recipe for disaster.

Thanks PB, I will let Jumper know this message.

Also, this type of power supply is used in Radiolink - MC34063 (if memory serves) down to 5V, then 1117s to MCU, RF module, and buzzer.
I agree, buzzer may be a bit extreme, on the other hand it generates a lot of noise.

Re switches and POTs/Ele direction - if we'd have a way to distinguish versions the question would be moot. I doubt they'll diligently change bootloader with every hardware change, though, so it's probably better to leave them as is.

@dc59 - I rescind my point 1 - leave controls as they are now.

dc59 wrote: 6. Linear reg as a first stage - better use switch DC-DC converter, then separate linear reg for MCU, RF module, and buzzer.
Jumper : Will DC-DC converter cause interference issue to RF module?

My experiments with the UniversalTx showed no RF impact using a DC/DC switching regulator directly for the RF when using a high quality converter (TPS62172DSGT) and properly placed caps for RF/MCU. I would not recommend doing this for the TX though due to the higher power requirements. Instead, I'd probably use a similar DC/DC converter and a separate Linear regulator for the MCU and RF only (I think you could run the buzzer/backlight directly off the DC/DC?) A solution like this would allow a lot of flexibility in battery supply (anything from 1S to 16V) with high efficiency. The battery voltage monitor circuit may need to be tweaked a bit though. I would personally love to see USB charging supported, but that can't be easily done without precise knowledge of the battery, so I guess that isn't in the cards.

My Tx is still stuck on the slow-boat, so I can't talk to the design, but I think Jumper should slow down a little. As I've said before, many iterations of the Tx is bad for us. It is hard to manage on the software side. First, we really need them to provide a method of detecting the hardware version (something stored in the bootloader probably). Next, I would then rather have them provide a list of specific features they plan to implement in the next revision that we could then discuss. I get the feeling they are over-eager here, and trying to appease everyone as quickly as possible is a recipe for disaster.

vlad_vy wrote: By the way, if Jumper wishes we can enable flash memory chip auto detection for the series Microchip SST25VFxxxB and SST25VFxxxA, ISSI IS25CQxxx, Winbond W25QxxBV. So they can use different flash memory chips, with different capacity, and with slightly modified PCB it can be 150, 200 and 208 mil bodies. But I don't know if it has any sense for Jumper.

For testing only, T8SG with enabled flash memory type auto detection.

Attachment not found

Please don't propose that to them. The safest way for us to distinguish the product will be by a version coded in the bootloader. Anything else is fraught with danger.

Edit: I think I completely missed the point. On re-reading, I think you may be advocating that they can use arbitrary memory chips, not that we should use the memory chip as a designator for different models. I don't have any issue with that, but I also don't really see a need to do so. Having more variation within the same product leads to more problems in general. Let's not bend over backwards to make it easier for them to make our life more difficult.

Wow. It sounds like you have done all the right things to get it set up. Did you try this: remove the battery for at least a few hours, maybe overnight. If it works, the TX will just boot into Deviation (or whatever you last loaded).

If that doesn't work, I think your next step might be a new bootloader, but this isn't something I've done or can advise. I still don't really think it's a bootloader issue, because AFAIK a failed bootloader would just not load anything or respond to the DFUse software. Is it possible that the EXT button is stuck?

I searched this site for the bootloader instructions and found some relevant threads:
* www.deviationtx.com/forum/3-feedback-que...memory-content#54138
* www.deviationtx.com/forum/6-general-disc...oader?start=20#54139

I hope you can work this out. Let us know what you find.

victzh wrote: Unfortunately UC1705 and its prototype NT7538 do not have any identification commands. On the other hand, there can be differences in behavior, either in controller or in other physical connections. Needs to be explored more, and if this is a prototype, Banggood should be notified to change something just for the purpose of easier configuration.

Possible ways to ID Tx:
The bootloader is likely different since they don't show the walkera logo on boot. I'm guessing they made some minor changes to bypass the screen initialization.
They may use a different flash chip. I believe these do have unique Id for each vendor. This may not work, since some users of the 7e-256 may swap the flash too, in which case we have no idea what to expect.

I think we will likely end up with a unique target eventually, because they've already indicated a willingness to rev the hardware based on feedback, and at some point it will likely be different enough. What I would rather not have is separate targets for 'rev1', 'rev2' etc. Until we get a better feel for their mode of work, I'd rather hold off on creating the new target. Probably at a minimum until some samples are available, and we can see what options we might have.

PhracturedBlue wrote: Walkera's bootloader is basically the stock bootloader with a button-test check, code to enable the display and show their logo, and the obfuscation code.

Thanks for the clarification, I had never looked into that and I though there was more Walkera IP involved.

Actually, you don't need an ST-Link if you screw up the bootloader. The ROM bootloader on USART1 (as described in AN2606 ) just needs a TTL-level serial connection. The protocol is described in AN3155 , and there's an open source implementation of the protocol. On the other hand, that's not much of an improvement. I'm not comfortable requiring a path that is that painful to back out of, but I'd like to see the builds made available for users who are comfortable with the standard tools.

FWIW, there's a dfu usb bootloader in the libopenc3 examples. If we were going to use one, that's where I'd start as we're already using libopencm3.

We already support the AT9 which doesn't need any encryption. the changes the Deviation are primarily is mucking with the ld file to deal with where program loading should start and disabling encryption (and ensuring there are DFuSE tools available. Walkera's bootloader is basically the stock bootloader with a button-test check, code to enable the display and show their logo, and the obfuscation code. There is an AN somewhere with the recommended stock DFuSE bootloader, and I think this Tx would have more than enough room for it. But as I mentioned, if they are planning to ship next week, it is already too late. To ease user support it would be better if they keep things consistent across time rather than change things that provide minimal end-user benefit but make support more difficult.

As far as swapping the bootloader, the big issue is that if you screw it up, you need an STLink. If you screw us firmware loading, you just do it again. I am not comfortable providing a recommendation that has any significant risk of bricking a user's Transmitter. We've already had enough issues with users not being able to install Deviation; I don't even want to comprehend the horror that would go with a bootloader upgrade.

goebish wrote: Replacing the USB bootloader requires some work on Deviation, that's not just a matter of burning another one.
I could have a look at that but probably not before October.

I looked into this a while back. From what I saw, it shouldn't require any changes to the firmware. The last step in the build process takes a standard dfu file and obfuscates it ala Walkera. That involves a per-tx parameter that tweaks the obfuscation a bit. Setting it to 0 results in no obfuscation, so you should be able to just create a new build target that sets it to 0. Maybe just skip the step.

Of course, I never actually tested this, so...

If we can replace the Walkera bootloader and have a copy of it available, then we can put it back with the same process used to replace it. It does make going back harder, but is certainly possible.

IIRC, the Arduino_STM32 bootloader is timing based. After either a hardware reset or one of the USART control flow pins toggling (DTR?), it watches for a signal on the USB serial comm for a few seconds. If that happens, it goes into the dfu loading process. Otherwise, it jumps into application code. Not really what we want. I believe the dfu loader proper is from an ST Micro app note that provides a sample dfu bootloader, by way of the Maple project.

I'm pretty sure using a different bootloader would require a different build, or at least our own custom dfuse program to take care of the Walkera code obfuscation that the Walkera bootloader currently handles. Personally, I'd rather go with more builds - let's let people use standard dfuse tools.

If you really wanted to save bootloader space, the STM32F103 ROM bootloader enables the STM32 protocol on USART1, which is what the trainer port connects to. That would require hardware mods to activate the ROM bootloader, hardware mods to the trainer port which break Walkera's detection of the trainer cable, and that code doesn't use the screen. I think the µcu upgrade is probably a better option.

Replacing the USB bootloader requires some work on Deviation, that's not just a matter of burning another one.
I could have a look at that but probably not before October.

PhracturedBlue wrote: Appears so. what is the upgrade procedure for this tx? Does it detect as a '7e' in the walkera uploader?

Do you want me to try to build you a firmware using their driver to get it so your screen is the right way around?

We might recommend that they not use walkera's bootloader, but if they are about to ship, it may be too late. As I mentioned above, it isn't as easy to change last minute.

I get this screen when I upgrade firmware with walkera tools



Is it detected as 7e by Walkera uploader?

I'll try to contact with them about bootloader change issue.

goebish wrote: I also suggest they replace the bootloader ...
Couldn't we use this one: github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Bootloader ?
That's what the stm32 multi-module is using.

Probably they could. It may need modification to detect bootloader mode ('m not sure having never played with it). It would require disabling the dfu encryption and a different firmware installer. In all it would likely slip their schedule to get it all working smoothly. I assume they've already done a production run, so almost certainly not going to happen on the 1st batch. If you do it on the 2nd batch, you now have incompatible installation procedures. i.e. a mess. It would have been nice had we been able to engage earlier in the process, a few low-cost changes could have smoothed out a lot of rough edges.

I also suggest they replace the bootloader ...
Couldn't we use this one: github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Bootloader ?
That's what the stm32 multi-module is using.

dc59 wrote: I downloaded NB Sep. 1 and try to update to T8SG with Walkera upgrade tool and got some problem.
1, When I entered upgrade procedure I got all dark screen.

2, It can upgrade FW with Wakera upgrade tool without problem,but after upgrade , I got inverted screen ....

I think they use Walkera bootloader , the problem about screen come from different LCD driver.
Is it correct PB?

Appears so. what is the upgrade procedure for this tx? Does it detect as a '7e' in the walkera uploader?

Do you want me to try to build you a firmware using their driver to get it so your screen is the right way around?

We might recommend that they not use walkera's bootloader, but if they are about to ship, it may be too late. As I mentioned above, it isn't as easy to change last minute.

Moeder wrote:

PhracturedBlue wrote: That just means they are using my usb filesystem code (which is expected). the question is how you update the firmware version.
I hope they didn't take Walkera's stupid bootlader I honestly doubt they did, as it would say 'Walkera' on it.

Maybe this is the time to finally write our own bootloader. I know you refrained from doing so to make it possible to downgrade from deviation to Walkera firmware, but having the option to flash our own bl (and as such freeing memory for devo7e users) sounds nice. I wonder how many users actually went back to Walkeras fw.... But we're off topic now.

On the 7e, we would get a very small amount of space back I think. We would still want to enable the screen and indicate that we're in boot mode, and we would want to use USB for the transfer. Those two tasks take quite a bit of memory. Maybe we could save a page of memory, but I'm not sure. Making use of it would be hard, because not every transmitter would use our bootloader, so we'd then need new targets just for this special case. Lastly, installing the bootloader is fraught with danger. You need a install a program which then installs the bootloader. If something goes wrong, it requires special equipment to restore. I just don't see there being enough benefits to warrant it.

PhracturedBlue wrote: That just means they are using my usb filesystem code (which is expected). the question is how you update the firmware version.
I hope they didn't take Walkera's stupid bootlader I honestly doubt they did, as it would say 'Walkera' on it.

I downloaded NB Sep. 1 and try to update to T8SG with Walkera upgrade tool and got some problem.
1, When I entered upgrade procedure I got all dark screen.



2, It can upgrade FW with Wakera upgrade tool without problem,but after upgrade , I got inverted screen ....





I think they use Walkera bootloader , the problem about screen come from different LCD driver.
Is it correct PB?

PhracturedBlue wrote: That just means they are using my usb filesystem code (which is expected). the question is how you update the firmware version.
I hope they didn't take Walkera's stupid bootlader I honestly doubt they did, as it would say 'Walkera' on it.

Maybe this is the time to finally write our own bootloader. I know you refrained from doing so to make it possible to downgrade from deviation to Walkera firmware, but having the option to flash our own bl (and as such freeing memory for devo7e users) sounds nice. I wonder how many users actually went back to Walkeras fw.... But we're off topic now.

PhracturedBlue wrote: dc59,
Can you ask them whether they have a USB bootloader installed in the firmware? Otherwise, it makes it much harder for an end-user to update their device.

I have connected USB to T8SG and copy my 7e-256 model files into T8SG, I think it's same as devo7e-256! but I will confirm it with maker again.