cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F730Z8 bootloader over USART - problems with erase flash

JCase.1
Associate III

I am writing an external bootloader for the STM32F730Z8 - (why? I need one windows code that can run the bootloader for the STM32, or use the STM32 to reprog a connected ATF1508 for my client). I've done this before, using info in AN3155 and AN2606. On lesser CPUs, this has had no difficulty (i.e. STM32L4P5). In this case, I try the same:

1-cycle \RESET & BOOT0 to boot to supervisor mode

2-autobaud successfully

3-send 0x00 to get the list of commands, successfully

4-send 01 to get the version and protection, successfully (vers 49, rp and nt both 0)

5-send 02 to get chip id (0x0452), successfully

6-send 0x73 to write-unprotect flash, successfully (i.e. receive back two ACK)

7-send 0x44 to begin an extended erase (intending only to erase sector 0).

This is where it fails. I get neither ACK nor NACK - it just times out. I don't even get to the second half of the extended-erase command where I send it the sector info.

I've tried very long waits & repeat loops to wait for the ACK (many minutes). From past experience this should be fast, it is only the second stage where I tell it how much flash to erase that takes any significant time.

I've inspected the protection option areas of memory, at 0x1FFF0010, 0018, and they are unprotected, as per factory defaults.

I'm communicating over an FT231XS-R, using the D2XX driver calls. I can mess with the baud rates and such, but that only prevents it from autobauding...and we're doing that fine (9600/8/1/E). I've played with the D2XX SetTimeouts - if set too hasty that only screws up earlier commands. I'm wired to a 20 MHz crystal, and the application runs at 200 MHz, but my understanding is that the bootloader just runs at the internal RC clock rate.

I'm certainly missing something stupid, but I didn't see it in the documentation. Help?

Jeff Casey / Rockfield Research Inc. / Las Vegas, NV

1 REPLY 1
JCase.1
Associate III

Fixed, disregard.

The fineprint of AN3155 clued me in.

On the description of the Write Unprotect command, it says that a system reset will be performed after completion. How did I miss this on the STM32L4P5? I just didn't read it. But why did it work then? In the really fine print next page, in a footnote to the flowchart, it says that they were just foolin'....system reset is only called for some (..list omitted..) and for other STM32 products no system reset is called for.

My earlier success had the following sequence:

reboot-supervisor

autobaud

get

gvrp

gid

wpun

xerase

wpun

write

verify

reboot-user

obviously that doesn't work for the F730. what works is:

reboot-super

autobaud

get

gvrp

gid

wpun

reboot-super

autobaud

get

gvrp

gid

xerase

reboot-super

autobaud

get

gvrp

gid

write

verify

reboot-user

(obviously I can skip a few of the repeated steps, like get-id, but basically it needed a reboot and re-autobaud.)

note that i had to reboot-super a 3rd time...this was because the write attempt timed out after the xerase unless i went through the whole sequence again. funny, though, the spec doesn't say anything about resetting after an erase. Perhaps this will ping the STM32 docs folks to add a footnote there?

Thanks for reading, cheers. Jeff