Problem accessing Flash

[niksa]

Posted on May 06, 2008 at 09:56

Problem accessing Flash

[niksa]

Posted on May 17, 2011 at 12:34

Hi, I am using STM32F103 Cortex chip in ''Big'' package (the one with most Flash available). My application receives some data over USB, stores it on the Flash, and later retrieves the data. I was using functions as described in FLASH Example 1 (FLASH_ProgramWord etc), and everything worked fine: FLASH_Unlock, erasing pages, writing to and reading from the Flash.

Until... I accidentally (I wasn't reading the manual, bad me!) wrote my own function FLASH_ProgramByte which was supposed to write a single byte to flash. After calling this function, my Flash seems to be extremely corrupted, and I can't get it back to work again. Now the Flash behaves like this: - FLASH_Unlock() works fine, and it unlocks the Flash write protection (checked the SR Flash register, and lock bit is removed). - FLASH_ErasePage() returns success - FLASH_ProgramWord() freezes the processor. If I remove prior call to FLASH_ErasePage(), then FLASH_ProgramWord() will return with ''page error''. If I remove prior call to FLASH_ErasePage(), but call FLASH_ProgramWord() with value of ''0'', it freezes the processor. I don't have any problem with downloading my code to flash using Flash Loader application. But I do have problems with accessing the FLash from within my code. I have tried erasing the whole Flash (both from Flash Loader application and from my code), but it did not help. I also tried to remove the Page Write protection from my code, but it didn't help. My program is only ~16kB large, and I was writing on Page 24, so there is no problem with overwriting the program code (I also checked the linker MAP file). Should I just throw the chip away, or there is a way to fix this? Thanks, Niksa

[niksa]

Posted on May 17, 2011 at 12:34

A minor update: the processor freezes when it reaches the following line in FLASH_ProgramHalfWord() function:

*((vu16*)Address) = Data; In the meantime I have tried to use various latency times, tried to switch prefetch buffer off/on, but none of this helped resolve my problem. I have also tried erasing/writing to another page, but the problem still persists. What puzzles me the most is the fact that I don't have any problems writing to flash through Flash Loader Application. But I cannot write to the memory from my own application. Please help, any suggestions (even if you consider them stupid) are EXTREMELY welcome. Best regards, Niksa

[niksa]

Posted on May 17, 2011 at 12:34

Thanks for your reply, however, yes, I did unlock the Flash. This is the code part:

#define FLASH_START_ADDR 0x08006000 .... FLASH_Unlock(); FLASH_ErasePage(FLASH_START_ADDR); // returns FLASH_COMPLETE FLASH_ProgramWord(FLASH_START_ADDR, FLASH_MAGIC_NUMBER); // freezes Cortex ... And using FlashLoader 1.1 tool I can check that there is no read/write protection on any of the Flash pages. Best, Niksa

[16-32micros]

Posted on May 17, 2011 at 12:34

Hi Niksa,

May be you should first Unlock your Flash before programming or Erasing as decribed in The PM0042 Page 12 and 13 : 2.3.2 Unlocking the Flash memory After reset, the FPEC block is protected. The FLASH_CR register is not accessible in write mode. An unlocking sequence should be written to the FLASH_KEYR register to open up the FPEC block. This sequence consists of two write cycles, where two key values (KEY1 and KEY2) are written to the FLASH_KEYR address (refer to Section 2.3.1 for key values).Any wrong sequence locks up the FPEC block and FLASH_CR register until the next reset. Also a bus error is returned on a wrong key sequence. This is done after the first write cycle if KEY1 does not match, or during the second write cycle if KEY1 has been correctly written but KEY2 does not match. The FPEC block and FLASH_CR register can be locked by the user’s software by writing the LOCK bit of the FLASH_CR register to 1. In this case, the FPEC can be unlocked by writing the correct sequence of keys into FLASH_KEYR. and this Using this function before programming and checking if lock bit is set or not. void FLASH_Unlock(void) { /* Authorize the FPEC Access */ FLASH->KEYR = FLASH_KEY1; FLASH->KEYR = FLASH_KEY2; } Hop this helps you. Cheers, STOne-32.

[niksa]

Posted on May 17, 2011 at 12:34

Another update. I tried my code on another chip (brand new), and I have the same problem. So the cause of this problem is not (as I suspected) the fact that I tried to write a single byte to Flash.

Has anybody ever experienced the FLASH_ProgramWord() function to freeze the processor? Ever? Best, Niksa

[niksa]

Posted on May 17, 2011 at 12:34

Problem solved. Finally :p

So, the problem was that I had ADC set up to trigger an analog watchdog interrupt. The watchdog range was stored on Flash. After the flash was erased, the range was erased to 0, so as the analog watchdog window was set to range of 0, I was constantly getting an interrupt - including the interrupt between these following two statements in FLASH_ProgramWord(): FLASH->CR |= CR_PG_Set; *(vu16*)Address = (u16)Data; Maybe I wasn't reading the manual through, but you need to make sure that no interrupt occurs while you are accessing the Flash. Thanks for reading my posts everybody, and I hope my experience helps someone else. Best, Niksa

[jj]

Posted on May 17, 2011 at 12:34

Hi Niksa,

It is heartening to see that you tried another chip/board. Our firm ''never'' allows development on a single chip or board - it is SO valuable to be able to test across a number of boards. (unfortunately we read of many forum users ''stuck'' to one problematic board - eating time/money/effort/morale) Try this: (from STOne-32) void FLASH_Unlock(void) { /* Authorize the FPEC Access */ FLASH->KEYR = FLASH_KEY1; FLASH->KEYR = FLASH_KEY2; } a) Enter an incorrect value for for the keys. b) Confirm that you are still locked. c) Now enter correct values. d) Confirm that you are now unlocked. If unsuccessful - review your xtal, PLL settings - all timing issues. Also be sure that your power supply is ADEQUATE and that you have sufficient number of bypass caps on ALL power pins. Your application is pretty typical - the chip should be able to achieve your objective. Please do keep us posted. Good luck.

[jj]

Posted on May 17, 2011 at 12:34

hi again Niksa,

Of course - as I wrote my response - you succeeded with your debugging! Good for you. Special thanks for your clear report of the problem's Cause AND Solution. This will be valuable to many - you have likely saved forum users THOUSANDS of hours! Hope that others will follow your model and provide their success/ work-around solutions...