Page 1 of 1
Page erase problem.
Posted: Sat Jan 03, 2015 4:53 pm
by rew
I want to store some "rarely changing" data in flash of my STM32F030R cpu.
Unlock:
Code: Select all
if (FLASH->CR & FLASH_CR_LOCK) {
FLASH->KEYR = 0x45670123;
FLASH->KEYR = 0xcdef89ab;
}
and then write the data:
Code: Select all
FLASH->CR |= FLASH_CR_PG;
for (i=0;i<len;i++)
((unsigned short *)FLASH_EE_REGION)[i] = ((unsigned short *)data)[i];
FLASH->CR |= FLASH_CR_LOCK;
Simple! Works!
...... once: you need to erase the page if the page is not empty to begin with.
Code: Select all
if (i != len) {
flash_wait_nb ();
FLASH->CR |= FLASH_CR_PER;
FLASH->AR = FLASH_EE_REGION;
FLASH->CR |= FLASH_CR_STRT;
flash_wait_nb ();
FLASH->CR &= ~FLASH_CR_PER;
}
The "if" tests for the "erase needed". I expect the first instruction in "flash_wait_nb ()" to lock, waiting for the flash operation to finish, just like when programming the data the fetch of the next instruction will lock the CPU until it is finished. I also must confess that interrupts are enabled, so there might be interrupts that hang waiting for the flash operation to finish. So? Things should continue as soon as possible after the flash module finishes the program or erase.
I've added all sorts of "print" statements to debug this. The AR register does not seem to change by my assignment. That is expected, as it is write only.
I've checked a few places for example code, but everybody seems to be following this pattern and claims that it works...
Re: Page erase problem.
Posted: Sat Jan 03, 2015 6:44 pm
by Giovanni
Hi,
Are you executing that code from RAM?
Giovanni
Re: Page erase problem.
Posted: Sat Jan 03, 2015 10:53 pm
by rew
Nope. I expect the CPU to lock and wait for the erase to finish the first instruction after setting the STRT bit. That's what the manual tells me would happen, or am I misinterpreting things?
(I didn't check the datasheet for the "times" that things take, but from the reference manual, the same happens when I program a single location. That works. )
Update: checked the datasheet. Word-program time: 53 microseconds, page erase time 30ms. So my bold move would cause the CPU to hang for about 30ms....
UPDATE: Got it! Somehow the "CR->PG" bit was set. When that's set it is not allowed to set the PER bit.
Code: Select all
> write Thisisiatest
my flash size 10000CR: 80 unlocking CR: 0
Need an erase... SR1: 24reset EOP SR2: 0 CR1: 2 SR3: 0 EER: 800fc00 CR2: 42erase done.
CR: 0 SR: 20
> dump 800fc00
800fc00 54 68 69 73 69 73 69 61 74 65 73 74 ff ff ff ff Thisisiatest....
P.S. "in the field" there will be about two "program operations" during the device lifetime. As the device comes "erased", the erase will never be necessary: the two program-moments write to different locations. But for my testing I need to be able to test the assignment of those parameters, And maybe some people in the field require reprogramming occasionally. So the occasional 30ms hickup doesn't bother me.
Haha! The "prefetch" is working! Right after setting the STRT bit (0x40), I read the CR to print it. I expected the CPU to stall until the STRT bit was reset by finishing the operations. Apparently the prefetch got the "read FLASH->CR" instruction ready-to-go without having to bother the flash for that....
Re: Page erase problem.
Posted: Sat Jan 03, 2015 11:26 pm
by Giovanni
30mS are a lot of time, you should make sure to stop drivers and the do the programming with IRQs disabled.
Giovanni
Re: Page erase problem.
Posted: Sat Jan 03, 2015 11:48 pm
by rew
I don't understand the difference between "disable IRQ, wait-for-BSY-to-clear , enable IRQ" or just having the hardware stall the CPU.
Of course I'll get e.g. overruns for devices that need an IRQ serviced more than once in that 30ms period. If that means I'm missing a serial-character, then that's too bad. There is nothing I can do about it except maybe disable the whole UART and start over. But that's going to potentially lose more characters than just stalling the CPU for 30ms.
For others I changed my code to:
to make it work.