cancel
Showing results for 
Search instead for 
Did you mean: 

Self programming STM32

DiBosco
Senior II
Posted on December 09, 2010 at 02:55

Self programming STM32

15 REPLIES 15
Posted on May 17, 2011 at 14:17

''... write your own code that sits in memory and when you reset it jumps off to this code which can look for a pin being held down or any other external stimulus. If that stimulus isn't there it jumps to the normal program start and execute the program; if the stimulus is there it runs code that allows you to get new code from anywhere you like and program the program area of flash from the bootloader section.''

 

That is exactly what the ST In-Application Programming (IAP) (or ''Bootloader'') examples do!

There really are two entirely separate and distinct issues here:

  1. The mechanism for allowing the code to be updated;
  2. The mechanism for transferring the data into the microcontroller

AN2557 uses the YMODEM on a USART to transfer the data but, as it says, there is nothing to stop you using any other trandfer peripheral and/or process of your choice...

stforum2
Associate II
Posted on May 17, 2011 at 14:17

If you have an image in SPI memory then all you have to do is to write a short routine that runs in on-chip SRAM and reads this SPI memory and writes it to the on-chip flash.  There is no need to rely on anything in the bootloader.

Yes, you write 16-bits at a time to the on-chip flash.

trevor23
Associate III
Posted on May 17, 2011 at 14:17

I would go for writing your own small custom bootloader (as in the IAP app note referred to above) rather than running flash programming code in RAM for the simple reason that if power is removed half way through your reprogram then the custom bootloader approach would just start loading from SPI flash again on the next startup until all the new code was programmed. The code in RAM approach would lead to a dead board.

Posted on May 17, 2011 at 14:17

''all (sic) you have to do is to write a short routine that runs in on-chip SRAM''

But how does it get into on-chip SRAM...?

Also, you wouldn't want to reprogram the entire application every time the chip starts - for at least two reasons:

  1. That would make for very long startup times;
  2. You could wear out the Flash
''There is no need to rely on anything in the bootloader''

You need some kind of Bootloader to get the ''short routine'' into the SRAM...

stforum2
Associate II
Posted on May 17, 2011 at 14:17

What I meant was:

There is no need to rely on anything in the ST bootloader.  (The one that is in system memory).

Posted on May 17, 2011 at 14:17

I would go for writing your own small custom bootloader (as in the IAP app note referred to above) rather than running flash programming code in RAM for the simple reason that if power is removed half way through your reprogram then the custom bootloader approach would just start loading from SPI flash again on the next startup until all the new code was programmed. The code in RAM approach would lead to a dead board.

Running code in RAM, is no more likely to trash the FLASH memory, than running from FLASH. The trick is not to be erasing and writing the entire FLASH.

Running a loader in RAM, is however likely to run more quickly and be more stable than code executing from FLASH, and stalling all the time.

To mitigate Andrew's concern about re-writing on every power cycle, the bootloader should checksum the content on the SPI memory, and compare it against the current FLASH image. This ensures a) that the image is correct/intact, and b) that the firmware only updates if different to the current one.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Posted on May 17, 2011 at 14:17

''code executing from FLASH, and stalling all the time''

As, for example, the AN2557  example does.
DiBosco
Senior II
Posted on May 17, 2011 at 14:17

Folks,

Many thanks for all the replies - not sure why I'm not getting notifications of these replies.

I had seen AN2557 and since reread it, but I am still none the wiser as to what the situation is. I'm guess it's partly because I'm used to other manufacturers' terminologies, but I find ST stuff incredibly difficult to follow.

Is the ''bootloader section'' the 12k starting from 0x8000000? Or is it entirely up to me at what point after 0x8000000 I start the ''normal'' program? In the AVR you set fuses to determine the size of the bootloader section.

I don't need anything complex at all in my custom ''bootloader'' as I am   running FreeRTOS which takes the new imagine in from the USB port, will put the new image into external flash and I want my little simple SPI handler to take that out of the external flash with a little run-to-complete program in the boot loader section. I can't see anything anywhere that shows you how to self program. I'm not talking about code, I'm talking about stuff like ''load register x with this and register y with that, set a flag and wait until the area of memory is programmed.'' I can see how to do the erase, but not the programming. Is there a document anywhere that describes this please?

Thanks again,

Rob

Posted on May 17, 2011 at 14:17

''is it entirely up to me at what point after 0x8000000 I start the ''normal'' program?''

 

The vector table for the bootloader

must

be at the start of Flash; ie, 0x8000000

At startup, the bootloader's vector table informs the processor where the bootloader code starts - so, in principle, you could put the code anywhere you like.

However, the flash has to be erased in pages, and you obviously don't want to go erasing the page that contains the bootloader's vector table! Therefore, it makes sense to use the rest of that page for the bootloader code.

You can then put your application anywhere you like in the rest of flash - bearing in mind the alignment requirements of the vector table, and the page boundaries for flash erasing.

''I can't see anything anywhere that shows you how to self program.''

 

 

You need the PM0075 Flash Programming Manual

''I'm talking about stuff like ''load register x with this and register y with that, set a flag and wait until the area of memory is programmed.''

 

The FLASH routines in the Standard Peripheral Library do that; the source is provided if you want to study it.