STM32F107 Jump To System Memory - Bootloader

[Morten Sissener]

Posted on July 15, 2017 at 18:36

I'm using the STM32107 and want to use application code to activate the STM32 bootloader in system memory. I've consulted the AN2606 Application Note where it states...

'In addition to patterns described above, user can execute bootloader by performing a jump to system memory from user code.'

My hardware/board is already designed and the Boot0 is already hard wired to ground (logic 0) and I don't want to have to redesign the board just to activate the STM32 bootloader. 

So far so good. When I scroll down in AN2606 to 'Table 3 - embedded bootloaders' I notice that for STM32F105/107 processors there's a 'NA' shown under the Bootloader ID and Memory Location. 

Is this ST's way of saying you can't jump to the bootloader by performing a jump to system memory from user code? Or is ST suggesting that because the STM32F105/107's are too complex to pull this off successfully so you're not even going to provide the info? 

The approach I'm planning to use is to write a value into a register, do a system reset, check the register value as 1st line of code and if register is set then jump to bootloader in system memory. This approach should make sure the processor is in reset/default state prior to the jump. 

Thanks in advance for any insight/guidance on this. 

Regards, 

Morten

[Tesla DeLorean]

Posted on July 16, 2017 at 03:36

Hard wiring it to ground does seem to foreclose on some opportunities to use it in manufacturing and in the field.

The F1 is problematic from a couple of perspectives, there isn't a remapping register to emulate the ROM being mapped at zero, and if using USB you're likely to need to have interrupts working, which is not an issue with the USART implementation which basically spins in polling loops.

The F105/107 has a larger ROM, so doesn't share the smaller USART loader found in the F103/F100 type parts.

It shouldn't be that hard to just try using it. From the FLASH Reset Handler you should be able to set SCB->VTOR, load the initial SP and PC from the ROM, and then confirm if the USB (DFU) or USART (Flash Demonstrator) actually function. 

[Morten Sissener]

Posted on July 16, 2017 at 14:59

Your comment about UART polling got my wheels turning. The root of my problem relates to interrupts while the vector table is being overwritten. If I suck it up and figure out how to handle UART receivce bytes via polling instead of interrupts then I can code my own flash bootloader app which I can park up in high memory and jump to that code instead of the (maybe) built-in ST bootloader. 

What I'm working on is having one processor send its image to another processor via UART and have the 2nd processor flash the image. That way a customer only has to update the main processor via its bootloader (not the ST built-in) and then that processor will update any other processors connected to it. 

[STOne-32]

Posted on July 16, 2017 at 16:10

Dears,

As you said ;-).  we do not recommend that usage by jumping from user code to STM32F105/107 built-in boot-loader for multiple reasons :

1) It may work by chance depending on your user code as we re-initialize many settings of clocks and other bits as we are out of hardware reset, Interrupts and vector table used for USB.

2) This is the first STM32 product we introduced USB DFU boot-loader in 2009, in addition to the famous UART/RS232 and our implementation has been improved in next generation products and we designed it to work by hardware Boot0=1 and at that time no Boot-loader version is specified.

as ST, we can not guarantee the function and usage, even it may work  for some user code.

Cheers,

STOne-32.  { 10 Years of STM32 }

[Tesla DeLorean]

Posted on July 16, 2017 at 16:29

SPI based host

https://community.st.com/community/stm32-community/blog/2017/05/02/stm32-spi-bootloader-host

 

Not sure I'd use high memory, but rather a boot loader in the low blocks starting at 0x08000000, and push the app code deeper into flash. The USART protocol is not unduly hard, I'd lean to using my own protocol that is more familiar with the hardware I've surround the core with. I've got library code for X-MODEM that works well for me, and inherently has flow-control. You can run code from RAM also, this avoids stalling execution you'll see if you write/execute from FLASH, but entirely erasing FLASH does make you prone to failure in power loss type situations.