USART Bootloader Protocol- Read command

[ttatakis]

Posted on September 01, 2015 at 14:24

I have an STM32F4 Discovery board and I'm trying to talk to the boot loader.  I have brought it up and I have successfully executed the 'Get', and 'Get Version and Read Protection Status' commands.  When I try the 'Read' command, I get a NAK on the length byte.  I am sending 11 EE 10 00 00 00 10 0F F0 (checksum bytes in bold)- trying to read 16 bytes at 0x10000000.  I get ACK's after the command and address but a NAK after the length byte checksum.

The Get Version and Read Protection Status command returns the following:

BL Version: 3.1

 Option 1: 0x00

 Option 2: 0x00

I am following the flow charts in AN3155 and have referenced 2606 and various other app notes.  What am I missing?  Any help is appreciated.

Tom

[Tesla DeLorean]

Posted on September 01, 2015 at 18:26

The STM32F4-DISCO USART1 (PA9/PA10) port is not viable, might be semi-functional at very low speeds.

Consider USART3, don't recall the pins

Check the 0x08000000 256 Read command sequence in

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/STM32F4%20bootloader%20write&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=1664

, waiting for the checksum at each stage. No sure 0x10000000 is supported, would need to check the code.

[Tesla DeLorean]

Posted on September 01, 2015 at 18:37

Not sure 0x10000000 is supported, would need to check the code.

I don't think CCM is a supported region in the loader code, SRAM address should be above 0x20002000, or 0x20003000 depending on loader version.

Addresses passed in are sanitized against a list of regions and sizes, so the processor won't Hard Fault on your request.

[ttatakis]

Posted on September 01, 2015 at 20:00

Turns out it was the address.  I guess I expected the address to get NAK'd in that case- but I should have tried another address to begin with I suppose.  I am using PB10 and PB11 (USART 3)- I found that issue at some other point in time.  Thanks for your help on that, it is working now.

Is there a way to 're-sync' with the bootloader.  Once it is up and the baud rate handshake sync has completed, it does not respond to the 0x7f anymore.  I have to reset the board to get it to respond to the sync character again.  It's a little cumbersome because while I'm debugging, everytime I make a change to my app, I have to reset the board.  I would like to be able to have the app come up and detect the boot loader.  Is there a recommended way to do this?

[Tesla DeLorean]

Posted on September 01, 2015 at 20:57

It technically doesn't listen for 0x7F, it's looking for the symbol/signal to measure the bit timing against the internal clock. It's a one-shot deal.

I think it should respond to 0x7F with an ACK or NACK in normal operation, you could probably EXEC against 0x1FFF0000 to reset the part.

Provided you haven't changed baud rate you can probably send some sequences to see if it responds and resync that way.