AN2606 bootloader question: Go command

[dale2]

Posted on March 14, 2008 at 05:21

AN2606 bootloader question: Go command

[bob239955]

Posted on May 17, 2011 at 12:22

Dale, this post was very helpful thanks.

See Post;

http://www.st.com/mcu/forums-cat-6520-23.html

I was wondering if your bootloader PC-ware managed to quicken reads (and writes) to RAM (and Flash) faster than the bootloader demonstrator 1.0 at

http://www.st.com/stonline/products/support/micro/files/um0462.zip

I managed to read 64k in 16 to 18 second at 115200 [an 'effective' rate of 42560 baud] which was faster and without the manual data re-entry requirement - since my app is a console (batchable)application. It is not yet distributable since its purpose so far is only to evaluate/explore how fast the STM32 bootloader can work, but I may post it when/if it is distributable.

[ This message was edited by: bobz on 14-03-2008 09:40 ]

[dale2]

Posted on May 17, 2011 at 12:22

Never mind - I figured it out by trial & error.

The ''Go'' command does not behave as described in AN2606:

''When the address is valid and the checksum is correct, the program counter of the CPU automatically jumps to the address.''

The ''Go'' command always replies with an ''ACK'' no matter what kind of address is sent. AN2606 indicates that invalid addresses (outside FLASH or SRAM areas) are rejected and a ''NACK'' is returned. I have tried the following addresses:

0x00000000 - returns ACK, stays in bootloader mode (invalid address)

0x00000001 - returns ACK, stays in bootloader mode (invalid address)

0xFFFFFFFF - returns ACK, stays in bootloader mode (invalid address)

0x08000E74 - returns ACK, stays in bootloader mode (reset() vector)

0x08000E75 - returns ACK, stays in bootloader mode (reset() + 1)

Sending the address of the beginning of the FLASH memory works:

0x08000000 - returns ACK, jumps to firmware in FLASH & executes.

I hope this helps other bootloader utility writers in the future.

Thanks,

Dale Wheat

[dale2]

Posted on May 17, 2011 at 12:22

I'm using AN2606 to help me write my own command line boot loader application for the PC under Windows XP. Hopefully what I get working here should be easily ported to any other platform. Hopefully. I have the basic communication with the on-chip bootloader working but I am puzzled by the behavior of the ''Go'' command.

I use the ''Get'', ''Get Version'' and ''Get ID'' commands to interrogate the bootloader and confirm that it is running version 2.0 of the bootloader firmware as described in AN2606. I then execute the ''Read Memory'' command to read out the first part of the FLASH memory, where the vector table resides. I have a simple test application running on the chip that flashes the LEDs on the STM3210B-EVAL board. I use the ''reset'' vector as read from the FLASH memory at address 0x 0800 0004 to give me the starting address of my application program. The number that gets read back is 0x 0800 0E85, which is the address (+1) of the reset() vector in my program. I have tried it with the +1 and without it, and either way the bootloader replies with an ACK to the address + checksum but it does not begin executing the program. It stays in bootloader mode.

Am I missing a step? Any ideas why the chip doesn't start running the test code?

Also, the 2nd flowchart (page 20, figure 11) showing the device side of the ''Go'' command has a duplicate ''Send ACK byte'' block in it.

I know that the ''Go'' command works because the STM32 flash loader demonstrator program causes a newly-downloaded program to start executing, and I assume that it issues the ''Go'' command or perhaps some other, undocumented, command to do so.

Any insight into this mystery would be appreciated.

Thanks,

Dale Wheat

[dale2]

Posted on May 17, 2011 at 12:22

bobz,

The limiting factor in downloads is the 115,200 serial baud rate, plus the overhead of only being able to send 256 bytes at a time. There's just no getting around these limitations when using the built-in bootloader code.

One way to improve download times is to always do a ''mass erase'' of the part instead of an optimized erase that only clears the affected sectors. The mass erase clears all locations simultaneously, whereas the sector-by-sector erase clears them one at a time, which can take up to 40ms per sector.

[bob239955]

Posted on May 17, 2011 at 12:22

Thanks Dale, it is true there is an upper speed limit at 115200 baud (bits per second) and there is an overhead due to reading blocks of 256 bytes. But theses are NOT the main limitations because the effective baud rate is SO much less than the configured baud rate.

It seems the code (at both ends) has big deliberate embedded delays that slow things down a lot -to make it more reliable- while it waits for data. My aim is to minimise the delays at the PC side and re-evaluate the speed of the firmware. Until that is done we don't know how much of the slowness is due to the PC software or the firmware.

So like you I have therefore written my own bootloader for the PC and found the following;

Conclusion

1) the existing version 2.0 system bootloader firmware can transfer data faster by writing your own PC ware. It allows 115200 baud to be used reliably on all PCs at an 'effective' rate of 42560 baud, reading 64k in 16s.

2) The firmware bootloader is worthwhile because of this, and because

3) it allows a firmware upgrade via Uart1 without the need for costly development equipment in the field.

4) It may even be possible for ST to further reduce delays at the firmware side slightly, since an 'effective' baud rate of 52535 baud should be possible at 115200 baud (because my STR712 boootloader transfers data at that 'effective' rate [118k in 23 seconds] which includes 4s to erase).

[ This message was edited by: bobz on 14-03-2008 09:45 ]

[ This message was edited by: bobz on 14-03-2008 10:29 ]

[bob239955]

Posted on May 17, 2011 at 12:22

I would be interested know how fast anyone can read data from the stm32 using the bootloader-demonstrator-1.0 at 115200 baud. On my computers it does not work at all at 115200, I have to use 9600 baud.