Flash programming FLASH_CR_PER bit not clearing

[frackers]

Posted on May 26, 2016 at 03:06

When I try to program flash, I can erase it OK and at the end of erasing I clear the FLASH_CR_PER bit in the FLASH->CR register.

When I come to program a pair of half words, I get no errors (FLASH_SR_WRPERR and FLASH_SR_PGPERR clear, FLASH_SR_BSY clear) and FLASH_SR_EOP is set which I clear but the flash memory stays at 0xffffffff. At the point of failing the verify I have checked and see that the FLASH_CR_PER bit is set again despite clearing it after the page erase.I'm not using the HAL code directly as I'm rewriting the whole of flash (hence I'm RAM resident) and I've fixed the HAL bug that tries to clear FLASH_SR_EOP bit whereas the spec says to write a '1' to that bit to clear it but still no write :(Anyone any ideas?

[Tesla DeLorean]

Posted on May 26, 2016 at 04:50

An F3, observing in a debugger?

[frackers]

Posted on May 26, 2016 at 05:17

Its an stm32f303x8 (64k flash) and I am debugging under openocd and eclipse (and st-util and kdbg !!). I had a bug thinking the flash was in 0x400 byte pages so was erasing what I'd just written as I move to the next page. Now correct at 0x800. 

The programming code is running from CCMRAM @ 0x1000000.I still fail at 0x8007800, the page is erased OK but I don't seem to be programming it. At one stage I was getting an interrupt fault but I don't even get that any more.Coincidence that the vectors and init are in this page? I disable all RCC and NVIC interrupts (I think!) and do a __disable_irq() before my main programming loop but are there any vectors that might find an 0xffff opcode which causes the fault?The lr register contains 0xfffffff9 which doesn't look valid and presumably indicates things are going off into the sunset :(

[Walid FTITI_O]

Posted on May 26, 2016 at 16:14

Hi rackers,

Are you using the last version of STM32cubeF3  ? ''and I've fixed the HAL bug that tries to clear FLASH_SR_EOP bit whereas the spec says to write a '1' to that bit to clear it but still no write '' > I don't figure out your point here, because I checked it in the last version of driver and it is clearing by writing a 1 in the bit -Hannibal- 

[Tesla DeLorean]

Posted on May 26, 2016 at 17:36

He's indicating it reasserts.

I'd debug flash interaction using a console, not a JTAG/SWD based connection.I'd put the vector table in RAM, not memory I was erasing. Hard Faults should provide some more detail of offending code if properly decoded.Magic values in LR is common for context-switches, ie into faults, where LR signals which stack to use to recover the faulting context. Executing 0xFFFF,0xFFFF opcodes, or jumping to such, is likely to result in failure. Disabling interrupts will not stop faults.

[frackers]

Posted on May 30, 2016 at 01:59

I explicitly clear the FLASH_CR_PER bit on writing a word so that problem has gone away now :)

My preference would be just not have any interrupts and hence no vector table. The first 15 pages (up to 0x7800) all program without a problem, its just that when the flash page that contains the default vector table destinations is erased I get a fault. Odd that the new code going in has a different vector table and that gets overwritten OK even though at that point the old destination (at 0x7800) is still present.If I could disable ALL interrupts I wouldn't have this problem!!

[frackers]

Posted on May 31, 2016 at 02:24

Good call Clive

I put a minimal vector table into RAM and discovered the problem was nothing to do with interrupts or vectors but one function in my RAM resident programming code was still in flash due to a mis-spelt __attribute__((section(''.ccmram''))). This just happened to be co-located with some of the vector destinations which led me down the wrong path.All is now good :)