Hardware design considerations for bootloader in a STM32F103 board

[mostafanfs]

Posted on August 14, 2015 at 09:54

I'm designing a hardware for STM32F103 and I want to be able to upgrade the firmware through GPRS later. I've already implemented a 128MByte NAND flash in the design but after a while I figured that NAND flash is probably not a source for booloader and according to documents they are USB, SPI, UART and ... so I figured to put a W25Q32 (32MBit SPI flash) as a boot source. Is that correct and enough? Or more hardware considerations have to be taken care in this phase? 

#stm32f103-nand-flash-bootloader

[Nesrine M_O]

Posted on August 14, 2015 at 15:47

Hi mostafanfs,

Have a look to this

http://www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/CD00167594.pdf?s_searchtype=keyword

, it can be useful. -Syrine-

[Tesla DeLorean]

Posted on August 14, 2015 at 16:26

Been a while since I've reviewed the F103, but pretty sure the SPI is not a bootable source. You can of course write your own loader, and it can do anything you want with your specific hardware.

In an F103 design I would make sure I exposed USART1 PA9/PA10 to a header, or otherwise brought it off the the board, and use other USART internally on the board if required. Exposing BOOTx pins and NRST will also make manufacturing programming easier.

[mostafanfs]

Posted on August 15, 2015 at 12:28

Thank you. Seems like you're right. 

From CD00167594.pdf in ''

STM32F10xxx devices bootloader'' section USART1 has been marked as Bootloader. What does this mean? It's manufacturer internal default bootloader? 

Well in that case I don't have any available USART/UART at all. Plus I wanted to upgrade from a memory not a PC's TX/RX connection and there is no memory with USART connection so USART is not good for me after all. What should I do?  

[Tesla DeLorean]

Posted on August 15, 2015 at 17:07

You're not going to be able to use the ROM based System Loader.

You can download, and stage, new firmware code into the NAND or SPI Flash. When your loader starts it can recognize it has new application firmware on the NAND/SPI, erase the portion of Internal FLASH holding the application, and then write the new one, before jumping to it. The application can download it's updates OTA (Over The Air) by using HTTP or FTP type transfers, where it connects to a server, and you write the file to the NAND/SPI Flash. You should review the USART/ETHERNET type IAP (In Application Programming) examples. Books on embedded programming should also give some coverage on boot loaders.