DFU: LEAVE does not jump to application.

[re.wolff9]

Posted on January 13, 2015 at 16:52 I want to jumper my STM32F072 processor for ''boot to system memory'': DFU mode. Then I want to use software to ''start the application''. This should be possible.AN3156 section 5.5 tells me that after a set address a zero-sized download request will cause the processor to use that address as a reset vector. The ''dfu-util'' program that I'm using has the following code:

dfuse_special_command(dif, dfuse_address, SET_ADDRESS);
dfuse_dnload_chunk(dif, NULL, 0, 2); /* Zero-size */

I've checked ''dfuse_address'' is the proper 0x8000000. The processor then enters ''dfuMANIFEST state''. But it in fact just re-enumerates as the DFU bootloader.

This would be consistent with no address having been set. Any ideas as to what can be going wrong? The idea is that I don't want to physically change th

[Tesla DeLorean]

Posted on January 13, 2015 at 17:31

So not clear here, are you jumpering BOOT0 High now? Or are you calling the System Loader from your application?

Perhaps the problem is that the Cortex-M0 does not permit the relocation of the Vector Table in the same way the M3/M4 do?

[re.wolff9]

Posted on January 16, 2015 at 14:31Yeah, consider my boot0 pin jumpered high. And boot1 jumpered so that I boot from system memory. (I thought about it, came to a conclusion, wired the board accordingly, tested it and forgot the details.)I then use DFU to download my application, and then I try to start the application from the computer using the command from the appnote (download 0 bytes). IF I tell it to jump to address zero, that's where the system memory will be mapped, but I'm telling it to jump to address 0x08000000. What you're saying is that my app might be causing an interrupt, which then goes through the interrupt table at 0x00000000, jumping ''unexpectedly'' into the system memory and eventually through maybe a few exceptions it restarts the boot loader? Update: WAIT! How do I activate the bootloader from my app? In 90% of the cases, my app hasn't crashed, so I might be able to ''ask it politely'' to jump to the bootloader. But for the remaining 10%, it is still useful to be able to run my application with the boot pins configured for ''system memory boot mode''. 

[Tesla DeLorean]

Posted on January 16, 2015 at 15:04

I'm just trying to understand what's going on, as I don't have a lot of time invested in M0, but understand some of the traps.

The app note was originally written for M3/M4 parts, and while I don't see any special considerations for the M0, I suspect the behaviour might have to be a bit different. You might want to look at the two vectors currently at 0x08000000. The DFU should exit there by default without setting the address. The other consideration in the application code is how it maps itself to zero (or if it expects to be), or if it copies the vector table into RAM and remaps the RAM at zero. The following placed at the front of SystemInit(), would get you closer to the normal boot conditions, if the app is otherwise unaware, or assumes initial conditions.

/* Enable the SYSCFG peripheral clock*/
RCC_APB2PeriphResetCmd(RCC_APB2Periph_SYSCFG, ENABLE);
/* Remap FLASH at 0x00000000 */
SYSCFG_MemoryRemapConfig(SYSCFG_MemoryRemap_Flash);

[Tesla DeLorean]

Posted on January 16, 2015 at 15:16

Looks like you edited while I was composing the response.

I've post other example of how to get into the System Loader, have to dig to see if I did one specifically for the M0 parts. You'd typically want to enter in near reset conditions, so HSI clocking, no interrupts, etc. I typically set a RAM variable, reset, catch that in the Reset Handler, and then jump to the ROM vector, in this case after mapping the ROM back at zero to replicate the BOOT0=High conditions.

[re.wolff9]

Posted on January 19, 2015 at 14:28

I'm  using a arm-none-eabi - gcc toolset under Linux. I've glanced at the ''link script''. It mentions that it wants ''vectors'' and ''text'' linked to be at 0x08000000. So, upon normal boot, the CPU gets the reset vector from address 0x00000000, and that's the end of using the ''remapped'' area. There should be no accesses to that area from then on. 

Except of course if the interrupt vector table is located there. I'll look into it. Update: The ''programming manual'' hints a few times to the possible relocation of the vector table, but refers to details to ''page 24''. Page 24 then states:  > On system reset, the vector table is fixed at address 0x00000000.which hints at ''other things might be possible AFTER system reset. On the other hand, the place for the VTOR register in the SCB is ''empty'' on cortex-M0. In short: executing code-from-flash (with interrupts) is not possible if said flash is not remapped to address zero by the BOOTx pins. Correct?

[re.wolff9]

Posted on January 19, 2015 at 15:16

Ah! Found it. in SYSCFG_CFGR1 I need to set boot mode to x0 to remap main flash to boot memory and use my own vector table. 

I'm not sure if the ''crash to system memory'' happens before or after executing my ''main'' routine. My ''main'' should normally start executing with interrupts disabled and such, so I should have time to fix the SYSCFG register. 

[Tesla DeLorean]

Posted on January 19, 2015 at 16:20

In the more general case (boot loader + app) the method to use a different vector table on the Cortex-M0 is to carve out an area at the from of the SRAM, and copy the table there, and then remap so the SRAM is shadowed at ZERO.

[re.wolff9]

Posted on January 19, 2015 at 18:29Found itAfter adding the setting of the syscfg to map flash into the boot memory, it was still coming back up as DFU boot loader.... My application was enabling power to a daughterboard. The charging of capacitors on the daughter board apparently browns out the STM.... Ooops! Without the daughterboard it boots into my app nicely. (I have very cheap but very good P-fets that I use to switch the power to that daughter board.......)