stm32f4 reprogramming from externan nand memory

[davhak]

Posted on January 21, 2015 at 18:13

Dear All,

I know that the question about jumping to the bootloader of STM32 without boot0/1 has been answered many time especially by clive1. My goal is to reprogram STM32F4 from the attached external NAND memory (connected over SPI). I guess in this case one should write from scratch his own custom bootloader to properly read from the NAND the BIN data? or are there possibilities to use the default bootloader? With a custom bootloader I guess the procedure would be as described by clive1 here:

/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Help%20with%20application%20jump%20to%20system%20memory%20boot&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=1020

i.e. jump to the default bootloader and then jump again to the custom bootloader and from there perform the application reprogramming? Is this the right procedure? In case if customer bootloader is required, this should be like a another application code (project) which will sit at an address space of internal flash of STM32F4 which do not interfere with the main application program (for example the custormer bootloader should occupy address from 0x8000000 to 0x80001FFF) and the application program should be started from 0x80002000? Thanks a lot for any information. #stm32-stm32f4-bootloader

[Tesla DeLorean]

Posted on January 21, 2015 at 18:32

The System Loader is not going to be able to do anything with you NAND device.

The processor is not going to run code from an SPI attached NAND device. You'd need to copy code from it to RAM, and execute the code in RAM. You could also read data out of the NAND and write it into internal FLASH. You're going to need to code your own bootloader to manage this, the first 16KB of the STM32F4 should be sufficient for such a task.

[davhak]

Posted on January 21, 2015 at 19:01

Dear clive1,

Thank you for your prompt reply. Sorry if I wasn't clear enough. Yes, I wish to reprogram the internal flash by the code stored in the SPI attached NAND memory and run the application from the internal flash. So the custom bootloader that I need to write should be possible to be accessed if I write the appropriate jump procedure under the ''; Add other choices'' line of the code which you posted by the following link?[DEAD LINK /public/STe2ecommunities/mcu/Lists/STM32Discovery/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/STM32Discovery/STM32F4Discovery%20Bootloader%20activation%20without%20BOOTx%20Pins&FolderCTID=0x01200200770978C69A1141439FE559EB459D75800084C20D8867EAD444A5987D47BE638E0F&currentviews=63]https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Discovery/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2FSTM32Discovery%2FSTM32F4Discovery%20Bootloader%20activation%20without%20BOOTx%20Pins&FolderCTID=0x01200200770978C69A1141439FE559EB459D75800084C20D8867EAD444A5987D47BE638E0F&currentviews=63 and that the code below the ''; Normal startup path'' should call the main application's SystemInit and main? Thank you very much for your help.

[Tesla DeLorean]

Posted on January 21, 2015 at 19:54

Yes, you could do it that way or call it directly from your Boot Loader's C code.

You'd build your application for the 0x08004000  or 0x08008000 address, and have it suitable the vector table (SCB->VTOR) setting in SystemInit() You should review the IAP examples, and the STM32F4-DISCO firmware update example where it pull data off a USB Flash Stick.

[davhak]

Posted on January 21, 2015 at 20:01

Dear clive1,

Thanks a lot for your answers. I'll look at the examples you mentioned. Thank you again.

[davhak]

Posted on February 17, 2015 at 16:40

Dear clive1,

I address you this question since you helped me with understanding the bootloader point. Yet 2 more questions: 1. if one follows your suggestion and check the presence of the magic word in the startup code upon reset (presumably reset occured from within the application code) then it jumps to the custom bootloader. Similarly, the custom bootloader should also have its one startup code and probably its own magic2 keyword and when it reprograms the application section it sets the magic2 word and upon reset the bootloader's startup code upon checking against the magic2 keyword now jumps to the application section? So application's startup jumps to the bootloader address and the bootloader's startup jumps to the application address upon matching of the magic words? Is this the supposed way of handling or I complicate things? 2. Just for testing I set the application's start address from 0x0800000 to 0x08008000 in the linker script as well as set the offset of the VTOR to 0x8000 and programmed the application with help of the swd programmer to the address 0x08008000. So nothing was between 0x08000000 and 0x08008000. The application in this case does not start. I assume this should be expected since the controller knows only about 0x08000000 as the starting address for either application or custom bootloader right? Thank you very much for your time and great help.

[Tesla DeLorean]

Posted on February 17, 2015 at 16:51

1) Seems unduly complicated, I just tend to flag that I want to update the application, from the application, and reset. The boot loader catches this and performs the erase/update. In normal operation the boot loader would check/validate the application, and then jump to it if it's valid. If it's not valid it stays in the boot loader to permit the device to be updated from there, or unbricked.

2) Correct, the processor only knows about the base of memory, nominally ZERO, and whatever is mapped there by the BOOTx pins, namely FLASH, ROM or RAM. You'd need your own loader that understands your SPI NAND device, and how it's attached to your system.

[davhak]

Posted on February 17, 2015 at 21:10

Dear clive1

Thank you very much for your continuous help. Probably my confusion about this reset/startup scheme is due to my misunderstanding of a simple and basic thing about stm32 reset. If the application program resides for example at address 0x08008000 then the Reset_Handler (defined in the startup ASM file) can be called only by the following chain? System Reset -> Custom Bootloader (programmed at 0x08000000) check and jump to -> application program's Reset_Handler ? Or there can be other cases when a reset event occurred in the application program immediately brings into application's Reset_Handler procedure (skipping the System Reset and bootloader's own Reset_Handler)? If there is no such condition then what you said and explained is all clear but then I would say that the Reset_Handler name is somewhat misleading as this is more just an entrance point of an application and not the point that catches a reset (like System reset for example). One other question which you could clarify is that in many posts in this forum I saw the address of the internal bootloader of STM32 was mentioned the 0x1FFF0000. But in AN2606 documentation for the bootloader memory location the address 0x1FFF77DE is mentioned or 0x1FFF76DE, or for STM32F10xx family it is 0x1FFFF7D6. So where does the 0x1FFF0000 come from? As always thank you very much for your kind help. 

[Tesla DeLorean]

Posted on February 17, 2015 at 22:14

System Reset -> Custom Bootloader (programmed at 0x08000000) check and jump to -> application program's Reset_Handler

Yes, exactly this. Different STM32 family devices have system memory at different addresses, for the F103 is 0x1FFFF000, for the F2/F4 it's at 0x1FFF0000. It's really a function of how large it needs to be to accommodate the functionality required. The 8K one only supports USART connectivity, ones supporting USB, CAN, etc will be bigger. The Data Sheet and Reference Manuals would be the controlling documentation, and you could verify in a debugger quite easily. The other addresses are for ID numbers associated with different versions of the loader.

http://www.st.com/web/en/resource/technical/document/application_note/CD00167594.pdf

[davhak]

Posted on February 17, 2015 at 23:31

Dear clive1,

Thank you so much for all your help and time and for the reference. I contrived to miss the System memory address from the AN2606. Everything seems to be clear now. Thank you again.