STM32f334 BootLoading of Custom Board

[ambrose]

Posted on March 29, 2016 at 09:27

This discussion is from an

/public/STe2ecommunities/mcu/Lists/STM32Discovery/Flat.aspx?RootFolder=https%3a//my.st.com/public/STe2ecommunities/mcu/Lists/STM32Discovery/Calling%20stm32429I-Eval%20Bootloader&FolderCTID=0x01200200770978C69A1141439FE559EB459D75800084C20D8867EAD444A5987D47BE638E0F&currentviews=442

 

'' QUOTE

''''

Hello Clive, I am sorry to put this in an old thread. But I am just trying to get my head around the bootloader/in application programming. I have looked through ST examples and have gone through several threads here (some you recommended), but I am still at sea about how to go about it.

The product(s) is(are) rack-system where we have a control board that interfaces with the board via I2C. I need to be able to update the firmware of 3 or more boards in one click of a button - meaning different I2C addresses. I am not really sure how to start with the bootloading. I have looked through the ST example. I am using STM32f334. T '''' UNQUOTE''

One Response (Clive):QUOTE ''''STM32F334/I2C

Yes, this perhaps should have been a new thread as it is sufficiently off-topic. I'd rather a new thread that cites the old one, if relevant, than have the context changed in old threads.

Is the firmware the same for each? Does your hardware self-identify which slot in the rack each of the 3 is located? How did the board designer(s) imagine this would occur?

'''' UNQUOTE  null

[ambrose]

Posted on March 29, 2016 at 10:31

Thanks very much Clive, 

Is the firmware the same for each?

Yes the firmware is the same for each board.Does your hardware self-identify which slot in the rack each of the 3 is located? Yes. this is done using a resistor, so the board I am working on has to do an ADC conversion at start-up to identify its I2C address.How did the board designer(s) imagine this would occur?I guess, this is same as above.I have done some more reading and what I find id that the application note(s) assume knowledge of boot-loading.Here is an excerpt from Ride (the tool-chain I use) start-up code:Reset_Handler: /****************************************************************//* Enable the FPU as specified by ARM */.if(1) /*you can comment this out to disable the FPU configuration*//* CPACR is located at address 0xE000ED88*/ LDR.W   R0, =0xE000ED88/* Read CPACR*/LDR     R1, [R0]/* Set bits 20-23 to enable CP10 and CP11 coprocessors*/ORR     R1, R1, #(0xF << 20)/* Write back the modified value to the CPACR*/STR     R1, [R0] /* wait for store to complete*/DSB/*reset pipeline now the FPU is enabled*/ISB/* Enable the FPU as specified by ARM */.endif /*you can comment this out to disable the FPU configuration*//****************************************************************//* Initialize external memory if required.This must be done with stack in internal SRAM and before setting SP to the user-defined valueand before initializing data and bss because the user SP value and/or the dada and/or the bssmight be in external memory(ies).You must make sure that your SystemInit_ExtMemCtl function does not access any .data nor .bss,because at this point they are not initialized and they will be overwritten later.*/  bl SystemInit_ExtMemCtl/* restore original stack pointer */    ldr r0, =_estack  msr msp, r0/* Call the system init function.You must make sure that your SystemInit function does not access any .data nor .bss,because at this point they are not initialized and they will be overwritten later.If your SystemInit function needs to access some data or bss,then you must move this call after the piece of code below.But this will slow down the execution of the init.*/        ldr     R0, =SystemInit        blx     R0

[Tesla DeLorean]

Posted on March 29, 2016 at 16:59

The System Loader (ROM based boot loader) I don't think is going to be helpful here. You'll want to focus on the IAP examples, and figure out if you want to split the firmware into pieces, ie a loader and application portion. In an ideal world you code your loader sufficiently robustly that you don't need to replace it. The loader needs to be capable of validating the application image, erase it, flash it, and perform recovery. The biggest vulnerability in the firmware update process is a loss of primary power during the update, which leaves the application image incomplete.

That they share a common image should allow them to program each other. Or that the update can be provided as a single stream that all can handle simultaneously.You'll perhaps want to start by getting your ADC, slot recognition code working. Then on testing I2C slave connectivity, unique addressing and communications. Then on the mechanics of your updateThis book has a chapter on boot loaders

http://shop.oreilly.com/product/0636920017776.do

[ambrose]

Posted on March 30, 2016 at 10:50

Thanks, I have gone the route of IAP:

I have this: int main (void) { ADCInit(); if(0) { BootLoader_I2C_Init(); } //else //{ if(1) { programAddress = *(__IO uint32_t*) (ProgramStartAddress+4); JumpToApplication = (pFunction) programAddress; __set_MSP(*(__IO uint32_t*) ProgramStartAddress); JumpToApplication(); } //} } I added the main program image *hex) to this IAP code, but it does not seem to work, as the MSP is never (or not) set to program address. I also tried it the other way around (adding IAP hex to main project) but the code just runs up to the end of the IAP code. On that book, I will buy it, but from the UK store as I am in the UK. Thanks a lot for your answers. EDITH: The application is getting stuck somewhere and on the debugger (IAP side), it shows as RTC_Interrupt, but I am not using RTC anywhere. I found

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a//my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/How%20to%20Disable%20all%20Interrupts%20before%20jumping%20to%20Application&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C...

, but I dont fully understand. Still on it... I also found

https://my.st.com/public/STe2ecommunities/mcu/Lists/ARM7%20STR7/Flat.aspx?RootFolder=https%3a//my.st.com/public/STe2ecommunities/mcu/Lists/ARM7%20STR7/Creating%20Bootloader&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580004D3EAEF5F50E4C4889D23E54433129E0&currentviews=1310

, though a different product, but I have edited the file:system_stm32f30x.c (line 122 in my file) ''#define VECT_TAB_OFFSET 0x2000'' - changing the offset from 0x0000; I also changed the off-set setting in project properties on Ride7. The image seems okay now (at least both images now work together and the main app runs). It seems it had nothing to do with any interrupt or vector table reset... Thanks a lot Clive, I will keep this updated so that it can help someone in the future (''??''). Changes: changing the offset and editing the file seems to push the whole code deeper into the flash, so I have had to reset the offset to 0x00 under project properties.