STM32F205 bootloader resets when RDP is enabled

[andy]

Posted on March 10, 2015 at 15:05

Hi,

I have a design using an STM32F205. It needs the capability to be upgraded via the USART interface, and I'd like to be able to use the built-in bootloader for this purpose. My application contains a command which causes a jump to the bootloader, and this works fine if I don't have readout protection (RDP) set in the option bytes. I can connect to it using the ST ''Flash Loader Demonstrator'' without difficulty. However, the finished product will be going out with RDP set (level 1), and this seems to cause different behaviour. I can still jump to the bootloader from my application code OK, but as soon as the MCU receives the first 0x7F byte from the PC, it drops straight back into my application as if it's been hard reset. The expected ACK is never transmitted. As far as I can see from the docs, the range of serial commands supported by the bootloader when in RDP protected mode is limited, but it shouldn't go so far as to lock out access from the PC entirely. I expected the MCU to ACK, and to accept commands from the PC to erase/unprotect the Flash before reprogramming it in the usual way. The only things I can find reference to that should cause a reset, are if it thinks the USB or CAN interfaces are active but there's no HSE. In this case, there actually is a valid HSE source, and anyhow, the USB and CAN pins aren't doing anything different just because RDP is enabled. Can anyone please suggest what might be causing a reset when RDP is enabled?

[Tesla DeLorean]

Posted on March 10, 2015 at 15:45

I can still jump to the bootloader from my application code OK, but as soon as the MCU receives the first 0x7F byte from the PC, it drops straight back into my application as if it's been hard reset. The expected ACK is never transmitted.

What happens is you reset with BOOT0 High? Does it respond to the 0x7F properly then? Because that's my experience, and RDP while it limits the System Loader's functionality it doesn't bomb out in the manner you have described.

[andy]

Posted on March 10, 2015 at 17:48

It seems to work fine if I power up the chip with BOOT0 high, but not if I branch to the bootloader from user code.

[andy]

Posted on March 10, 2015 at 18:19

Upd: looks as though I was neglecting to set the MSP before branching to the bootloader. Setting this correctly means it now works... BUT...

It appears that the bootloader doesn't support any Flash writes until the read protection has been removed, and this involves erasing the entire Flash (OK) and then rebooting (not OK!). Rebooting the CPU exits the bootloader, leaving it with no firmware and BOOT[1..0] = 00. In other words, bricked. This seems like a major limitation... I can't see any way to use the ST bootloader to upgrade a read-protected unit, unless BOOT0 is externally accessible. Any other options besides writing my own bootloader?

[Tesla DeLorean]

Posted on March 10, 2015 at 19:21

Well as you can't use the System Loader for anything other than plain text images, using it at all would seem to open a vulnerability you could drive a truck through...

Don't recall it precluding writes, I know it stops READ and GO