Porting IAP

[Daniel Hatcher]

Posted on January 03, 2018 at 10:16

Hello, I am new to STM 32 devices so go easy. I would like to port over the IAP included in the AN4854 which is for a STM32072B Evaluation board over to a STM32f746 Discovery board. I have read through the application note a few times. I have previous experience with IAP on other devices so the memory mapping is not the issue....at the moment. What I am struggling on is after changing the device name, my understanding is I then have to change the HAL drivers. What is the best way to go about this without incurring lots of errors?

Thank you

#stm32-f7 #stm32f7-hal #stm32-iap

[Andrew Neil]

Posted on January 04, 2018 at 09:59

STM32072B Evaluation board

So an STM32F072VBT6 microcontroller, then?

http://www.st.com/en/evaluation-tools/stm32072b-eval.html

 

So Cortex-M0

to a STM32f746

Which is Cortex-M7.

Is there not something closer to start with?

after changing the device name

Where?

You haven't said what tools you are using.

change the HAL drivers

Yes - you will need the particular HAL drivers for the chip in question.

The easiest way is often (usually?) to start a fresh project 

for the chip in question, and merge/port other code into that ...

[Daniel Hatcher]

Posted on January 04, 2018 at 10:24

Thanks for the reply. 

I am totally new to ST chips so please forgive me. I was advised to use the IAP example then port it over to the correct device. 

I am using system workbench for STM32. I have also created another project using STM32CubeMX. 

I have used an example project for the

STM32f746 Discovery board and create my own application which include a display.

So would it be better to create my own project using 

STM32CubeMX, then add in the function and header files which are needed for the IAP. I can then set the correct locations in the linker for my application. 

[Andrew Neil]

Posted on January 04, 2018 at 12:26

Daniel Hatcher wrote:

I am totally new to ST chips so please forgive me.

Not really specific to ST.

While the Flash subsystem (and other peripherals) is not directly related to the core type, my point with Cortex-M0 vs M7 is that M0 is 'bottom of the range', and M7 'top of the range' - so it is quite likely that an M7-based chip will probably also have a 'beefed-up' flash subsystem to match.

I was advised to use the (sic?) IAP example

Who advised?

I think there are several IAP examples - have you checked if there's one specifically for the 

STM32f7...

 ?

would it be better to create my own project using 

STM32CubeMX, then add in the function and header files which are needed for the IAP.

Probably.

then set the correct locations in the linker for my application. 

That's probably not the only thing that'll need changing ...

[Andrew Neil]

Posted on January 04, 2018 at 12:42

Some suggestions here:

https://community.st.com/0D50X00009XkXMoSAN

[Daniel Hatcher]

Posted on January 05, 2018 at 09:16

Thank you very much for the help. I will crack on today with your suggestion to start with the project located...

Repository\STM32Cube_FW_F7_V1.8.0\Projects\STM32F769I_EVAL\Applications\IAP and give you an update later on. Thanks 

[Daniel Hatcher]

Posted on January 08, 2018 at 16:29

I have created a project for my board. I can erase and write to a single address then read the address to check that the value has been written correctly which is does. I have then used the function in the examples for writing the whole file to flash and incrementing the address. I have also used a jump to application function for after the flashing. However, after flashing and jump to application the code does not seem to run.

I know that my jump to application function is correct, because if I set the address to jump to the start i.e.0x08000000. The code will then start to reflash and continue in this loop of erase/flash/jump to start.

So it seems to be something to do with my writing. Below is my writing to flash function.

__IO uint32_t read_size = 0x00, tmp_read_size = 0x00;

uint32_t read_flag = TRUE;

/* Erase address init */

LastPGAddress = APPLICATION_ADDRESS;

/* While file still contain data */

while (read_flag == TRUE)

{

/* Read maximum 'BUFFERSIZE' Kbyte from the selected file */

if (f_read(&MyFile, RAMBuf, BUFFERSIZE, (uint_t*) &read_size) != FR_OK)

{

}

/* Temp variable */

tmp_read_size = read_size;

/* The read data < 'BUFFERSIZE' Kbyte */

if (tmp_read_size < BUFFERSIZE) {

read_flag = FALSE;

}

/* Program flash memory */

if (FLASH_If_Write(LastPGAddress, (uint32_t*) RAMBuf, read_size) != FLASHIF_OK)

{

}

/* Update last programmed address value */

LastPGAddress = LastPGAddress + tmp_read_size;

}

f_close(&MyFile);

I have set my linker scripts to the following

Bootloader

FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 64K

RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 320K

Application

FLASH (rx) : ORIGIN = 0x08010000, LENGTH = 960K

RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 320K

#define VECT_TAB_OFFSET 0x10000

I am jumping to the address

0x08010000 too.

Is there a way back to read the device once programmed to see what exactly has been programmed and where? Any help on why my writing function does not work too would be greatly appreciated.

________________

Attachments :

mainV2.c.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyD0&d=%2Fa%2F0X0000000b4c%2FBkHcWeL_ATbzxhmN9E3TT6SW2B2Ydxvxx9bbgKbIsoE&asPdf=false

[Tesla DeLorean]

Posted on January 08, 2018 at 16:43

The ST-LINK Utilites can read back the device content. You could also save content back onto the SDCard.

Would tend to CRC the data written to FLASH and compare that to the binary file I generated in the linker. Use serial port to output progress/telemetry.

The debugger should permit you to walk into your own code. Have a Hard Fault handler that outputs diagnostics if you end up there, and make sure SCB->VTOR is actually set properly. ie use SCB->VTOR = &__Vectors; rather than the VECT_TAB_OFFSET nonsense.

[Daniel Hatcher]

Posted on January 08, 2018 at 17:17

I have used the ST LINK Utilites software and have found that as I suspected the application is not being flashed. I have debugged the function and it fails due to 

if (tmp_read_size < BUFFERSIZE) {

read_flag = FALSE;

}

[Daniel Hatcher]

Posted on January 09, 2018 at 10:48

So, I was opening the BIN file incorrectly which caused the flash to happen incorrectly, in my case not at all. I have managed to get the device to flash and have read back the device memory and all seems okay. I have opened the file view a hex viewer and starting at 0x0801000, the correctly areas of the device have been flashed with the correctly data. The only issue is that after I jump to application nothing happens. How can I check to set that 

SCB->VTOR is set correctly? Also is there any other common errors that would cause the processor to flash and jump to app but not run? 

Thanks

[Tesla DeLorean]

Posted on January 09, 2018 at 20:21

You could inspect in the debugger, or print it out via USART or SWD

If you jump to the wrong address, or the code is built for the wrong address, things will break.

Random interrupts firing, or expectations that the system is in some specific state can cause issues.

>>The only issue is that after I jump to application nothing happens.

Something happens, you'll need to inspect and step the code to understand what. Or add instrumentation until you can see what is happening.

If you have HardFault_Handler() and Error_Handler() functionality that is simply a while(1) loop things will die silently. Best that these things output a message or drive a GPIO/LED so you understand where/why something died.

[Thomas Fischer]

Posted on January 09, 2018 at 11:22

Hello,

in older IAP examples

SCB->VTOR was set in main.c,

however in newer versions of the HAL lib,

SCB->VTOR is set in file system_stm32??xx.c  in function SystemInit().

SystemInit is called from function Reset_Handler in startup_stm32??.s,

that means before main()

So the #define VECT_TAB_OFFSET in file system_stm32??xx.c must be set correct.

It's also useful to disable interrupt global before jumping to application.

Best regards

Thomas

[Daniel Hatcher]

Posted on January 10, 2018 at 09:56

We have lift off!! I have got the bootloader working changing between 2 simple LED sequences. I am trying to now load up my main application and it loads unsuccessfully. I have changed the following in the application project which is what I changed in the simple LED project;

FLASH (rx) : ORIGIN = 0x08010000, LENGTH = 960K

RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 320K

#define VECT_TAB_OFFSET  0x10000 

However, no luck bootloading the project. Is there anything else I need to change? Also is there any way to see how much flash and ram the project takes up, in other software I have used you can view the amount of free space etc. I am using system workbench for STM32 by the way.

Thanks for all your help so far!! 

*EDIT*

I have found what is causing the issue but not how to solve it yet. The main application is based upon a display example located in STM32Cube\Repository\STM32Cube_FW_F7_V1.7.0\Projects\STM32746G-Discovery\Applications\Display and have tracked down the issues to LCD_Config();. If I put my led sequence with a while(1) loop before LCD_Config is called the app runs fine however if I put the led sequence after LCD_Config it crashes, with it commented out it then crashes on the I2C part of my application. 

Could it be that LCD config and the I2C part needs to called in the bootloader code rather than the application code?