STM32F4 flash erase for IAP

[lesaint]

Posted on July 04, 2013 at 14:53

Hi everybody,

I'm trying to make the IAP exampe code from ST running on the Olimex board E-407 (STM32F4) but when i want to erase the flash, a hardfault occurs. More precisely, it happens right after setting the STRT bit in the FLASH_CR register when erasing the sector1 (address 0x08004000, while the IAP code has been uploaded in the sector0, at 0x08000000) So i'm thinking about a protection problem but: - the control register is unlocked - All the read/write protections of the FLASH registers are disabled - the status register has the value 0x00000000 (no error detected here) Other disturbing fact: I can erase other sectors properly (2,3,...) and write on them but then i can read only zeros... Please, help !! Pierre #iap-jump-issue #iap #iap #stm32-flash-erase-page

[lesaint]

Posted on July 15, 2013 at 09:59

Does anyone have any idea ?

[Tesla DeLorean]

Posted on July 15, 2013 at 14:47

It's difficult to determine what you're doing wrong from the information presented, the Hard Fault suggests you are erasing code, vector table or interrupt handlers that the processor expects to be seeing.

If you want others to assist with code issues you'll need to post a sufficiently complete test case.

[stst9192]

Posted on July 18, 2013 at 11:43

Hi,

How are the flash banks organised at the F40x ? You may have a write while read code from same bank problem if sector 0 and 1 are in the same bank. But refer to the data sheet/manual and errata about that - i am just guessing. I am facing a problem with jumping from my F103cbt6 application back to the bootloader. Jumping from boot to application works fine but when I want to jump from application to the bootloader using the same code snippet from IAP but with the bootloader base address used I end up in Nirwana. Has someone any idea ? Pls, feel free to get in touch with me via tom@tktronic.de cy, tom.

[Tesla DeLorean]

Posted on July 18, 2013 at 13:22

Has someone any idea ?

Round here we use a debugger to understand where the execution goes, and what it does. If I had to guess I'd suspect SystemInit() in system_stm32f1xx.s makes assumptions about the CPU running at 8 MHz off the HSI (ie Reset conditions), and jams up the HSE/PLL which the CPU is actually running from when you enter via the App. For many of the FW library releases SystemInit() is not adaptive to entry conditions.