Replace Devo7E bootloader?

SadSack wrote: There a minor downer using serial bootloader if you don't get right it hangs forever and a day before it times out. That why I added mod to boot 0 boot 1 After that I could hit bootloader everything. Having to move jumper on Dev boards get boring very fast.
Think I've posted details of mod on regroups let me look....

Be interested in seeing that. Mine seems to time out fairly quickly - could be a difference in the tools, But as you say, moving the jumper and/or hitting reset gets old. That's the genesis of the bootloader project: just plug in the USB cable, forget the serial line, and only use the STLINK for debugging. Of course, the stlink may just get used all the time, since it is a dev board.

My take on the embedded vs. firmware boot loader take is that if we can get the embedded bootloader to work the same way the dfu one does - just hold the button on power on to start it - then not having any display is a small price to get back the full 12K. If not, then the work of flashing a new one once to get half that back is also worth it. The question then becomes what functionality we put into it.

Update. I have the bootloader working. Just needs some configuration facilities and documentations.

The space savings is 4K, not 6K. However, that's enough that I've built a 7E dfu file that has the layout editor enabled, and it's still got over 2K free.

Busy weekend coming up, so I'm not sure when I'll be able to get tweak it to work on the Devo, then try a new version on my 6S. If you really want to look at the code, the repository is at chiselapp.com/user/mwm/repository/DFU_Flash_Bootloader/home . But it's using the wrong IO ports for the Devo....

If you want a few more features than the embedded boot loader provides then write a tiny stub to do what you want, then call the embedded loader.

Also, I suspect if you enable boot0 and connect the Devo USB port to your computer that you'll see a boot device show up there. Probably need a driver on your computer to access it.

Richard96816 wrote: If you want a few more features than the embedded boot loader provides then write a tiny stub to do what you want, then call the embedded loader.

Also, I suspect if you enable boot0 and connect the Devo USB port to your computer that you'll see a boot device show up there. Probably need a driver on your computer to access it.

Please read the thread. We've already covered this. According to STM AN2606, the embedded bootloadesr in the STM32F103's used in the various Devo Rx's only support the USART1 boot loader. Nuts, even the XL-density versions only support a second USART, and none of the Tx's use those. This is what I see on the bench: the embedded bootloader doesn't provide any flavor of USB devices.

The USART protocol is documented in STM AN3155, and the only command it supports other than reading and writing various bits of memory is the "GO" command to start the application.

They do support ST-LINK, but an ST-LINK adapter isn't available without opening the Tx, so that's a non-starter. Using the USART bootloader only would be ok - even without any hooks - if the lines are available outside the Tx.

mwm wrote:

Richard96816 wrote: If you want a few more features than the embedded boot loader provides then write a tiny stub to do what you want, then call the embedded loader.

Also, I suspect if you enable boot0 and connect the Devo USB port to your computer that you'll see a boot device show up there. Probably need a driver on your computer to access it.

Please read the thread. We've already covered this. According to STM AN2606, the embedded bootloadesr in the STM32F103's used in the various Devo Rx's only support the USART1 boot loader. Nuts, even the XL-density versions only support a second USART, and none of the Tx's use those. This is what I see on the bench: the embedded bootloader doesn't provide any flavor of USB devices.

The USART protocol is documented in STM AN3155, and the only command it supports other than reading and writing various bits of memory is the "GO" command to start the application.

The date and version of the particular chip is apparently important.

On page 19 of AN2606 it suggests the ability to query the processor for the actual bootloader support for the chip in hand via the Get Version command. That information would be preferable to dated app-notes.

Edit: I don't know what I looked at before the earlier part, but I found the page Richard was referring to. You can indeed figure out what interfaces are available on an STM32 chip by looking at the ID info from it. Apologies for any problems my confusion may have caused.

That said, I really can't see either ST adding interface to the embedded bootloader on a chip without giving the new chip a new designation, or walkera upgrading the chips they use in their txs so long as the old one was available. The only exception I can see would be if the new chip were otherwise identical to the old chip, and using the new one in place of the old one saved by replacing two small production runs with one large one. Unfortunately, ST doesn't seem to make a chip that would provide that upgrade for what's in the 7e.

Well, I've got the firmware to test - and nothing to test it on. Which means I'm stuck without some help from somewhere.

The 6 has jumpers similar to those described by PB in the "flash the 7E bootloader", but my ST-link isn't getting a response from it. So - can someone tell me how to flash the bootloader on a 6? And also, it'd be nice to have a 6 bootloader before I try this. There isn't one in the collection of Walkera bootloaders.

Alternatively, I have a custom bootloader for the 7e, and a deviation build for it to load. It's the current nightly with the layout editor enabled. If someone is willing to test that, I can upload both here. But I wouldn't recommend it unless you're comfortable flashing the bootloader, and maybe have done so with walkera's bootloader.

My best guess use devo8 bootloader but you could just dump yours to the serial port. It all in the code main.c DUMP_BOOTLOADER. Took me a while to figure out to get it to work. Then when I did couldn't work out how turn out put in to bin/hex....no surprise there I'm no coder And Pb came back and bootloader magical appeared!
Tx will boot as normal.
Tx will boot!

Once STlink is connected you only need to use jumper for power only. STlink ignores boot0 boot1 that's only needed when using internal bootloader. You will need to reset fuses to erase bootloader.

FYI if you get stuck without for what ever reason....
Flash deviation to 0x08000000 with erase
Then flash again 0x08004000 without erasing << last is important

And just a thought for later...

Wouldn'tit be possible write code that's loaded by DFU loader which then rewrites your bootloader?
Wouldn't need any special hardware then. Looking at PB's boot dump he's changing fuses to dump bootloader.

SadSack wrote: Once STlink is connected you only need to use jumper for power only.

SadSack, any idea what this jumper connects to / what it does?

RoGuE_StreaK wrote:

SadSack wrote: Once STlink is connected you only need to use jumper for power only.

SadSack, any idea what this jumper connects to / what it does?

My understanding it's a bypass jumper for power. When you switch off tx that tells mcu I want to power down, it then switchs of tx off!

www.deviationtx.com/articles/17-hardware...hardware-connections

Looking there it puts 3.3v to GPIOA:2: output to 0 to shut off Tx

The primary worry would seem to be this error:

Could you have missed a change in usbdfu.c?

For that matter, that you have to change the includes (not sure how) after changing OPENCM3_DIR seems to indicate that OPENCM3_DIR isn't pointing to the right thing. Possibly an older version of libopencm3? In particular, I'm using the latest release, not what's bundled in the deviation sources.

Just one thing we haven't talked about. How do we change deviation code so it runs from 0800200? When I tried adjusting

CRC_OFFSET := 8192 OPTIMIZE_DFU := 1 MODULAR := 0x20004000 DFU_ARGS := -c 7 -b 0x08003000

bitbucket.org/deviationtx/deviation/src/...er=file-view-default

wouldn't complie, OK no surprise on my part but will need something to test bootloader.

FDR wrote: Can you tell me which target is called "pill"?
Actually I want to adopt the bootloader for the "arduino" like STM32 modules. I've just received my ST-Link clone...

The "pill" is an STM32F103C8T6 (same CPU as in the 7e, except doc'ed as having 64K of flash instead of 128K, only they all appear to actually have 128K) gum stick form factor board sold as a "minimum system development board" like this one: www.ebay.com/itm/STM32F103C8T6-ARM-STM32...o-DHUS-/321569700934 It has either a red PCB or a blue PCB, and are identical modulo resistor values on some of the pins. They're called the "red pill" and "blue pill" boars on the STM32duino.com forums. You might want to check out their dfu boot loader, as it's designed to work with the Arduino IDE.

The folks at stm32duino.com have their own dfu bootloader, specifically designed to work with the Arduino IDE. I suggested that because you mentioned Arduino-like.

I use open source tools on my Unix desktop instead of the STM tools, but they should be compatible. I've used an stlink V2 and - after installing the pill bootloader - a dfu flash utility. I've also used gdb via the stlink hardware to debug things.

SadSack wrote: Just one thing we haven't talked about. How do we change deviation code so it runs from 0800200?

Sorry. missed this earlier. If you clone ssh://hg@bitbucket.org/mwm/deviation, the custom-dfuse branch builds. Unfortunately, it also has my FrSky-telem-names patch in it, as it's a quick hack to get something to build, and I wasn't planning on creating a pull request from it.

All the changes are in src/target/devo7e:

Makefile.inc: "DFU_ARGS := -b 0x08002000". The -c arg is what causes the "encryption" for the Walkera version of dfuse.

devo7e.ld: Just change the rom origin to 0x08002000

devo7e_opt.ld: Fix rom origin as above, length to 120K

I also set HAS_LAYOUT_EDITOR to 1 in target_defs.h, as I figured it would be nice to have something to tempt people to actually try it .