cancel
Showing results for 
Search instead for 
Did you mean: 

Porting IAP

Daniel Hatcher
Associate II
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
13 REPLIES 13
Daniel Hatcher
Associate II
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

Thomas Fischer
Associate II
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
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.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Daniel Hatcher
Associate II
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?