STM32F030 flash read problem

[CharlieMangold]

Posted on October 24, 2016 at 15:36

Hi,

We are using a STM32F030C8T6 and are storing configuration data at the end of flash memory. We carved off 4K of the 64K of flash(via the .ld linker file) for the storage area so our config storage is at address 0x0800F000. The data is stored there correctly when viewed from the debugger. During operation of the system we copy the data into ram, insure that the config CRC's are correct and use the data that is now in ram. The problem that we have is that during normal operation we insure that the ram data matches the original flash data by reading both ram and flash and comparing the bytes. During this process a byte of data that is read from the flash appears as a 0xFF and the compare fails. We are only reading from the flash so there are no writes going on. I have not found/read any reason a flash read could get corrupted so I'm looking for some help. tempByte1 is the data from flash and tempByte2 is the data from ram. The error checking is run at random times during program execution but the failure normally occurs on the first byte read(when i = 0.) The ram byte is correct and the flash byte is showing up as 0xFF. I thought that maybe the tempByte's were getting blasted because of stack space but the error always seems to come from the flash byte read. Are there any issues doing single byte reads from flash? Thanks, John C.

uint8_t read_flash_byte(uint8_t *addr_p)
{
return(*(__IO uint8_t *)addr_p);
} // End of write_read_byte()
// Function where error occurs...
uint8_t tempByte1, tempByte2;
uint8_t *ptr1_p, *ptr2_p;
/* Make sure the both flash copies match RAM copy we are using. */
ptr1_p = (uint8_t *)&UL1;
ptr2_p = (uint8_t *)&UL2;
for(i = 0; i < 
sizeof
(EE_UL_CRIT_DATA); i++)
{
/* check this byte in Copy1 */
tempByte1
= 
read_flash_byte
(ptr1_p++);
tempByte2
= 
UsedULData
->Val[i];
if(tempByte2 != tempByte1)
{
/* Flash and Ram are different throw a critical Error */
HandleError();
}
/* check this byte in Copy2 */
tempByte1 = read_flash_byte(ptr2_p++);
if(tempByte2 != tempByte1)
{
/* Flash and Ram are different throw a critical Error */
HandleError();
}
} // End of for loop

[waclawek.jan]

Posted on October 24, 2016 at 15:45

What is

read_flash_byte

()? JW

[CharlieMangold]

Posted on October 24, 2016 at 16:26

It was just a small function to separate the flash read from the rest of the code. You can see it at the top of the code section. I was using it to test different ways to read from the flash without effecting the main checking loop.

John C.

[waclawek.jan]

Posted on October 24, 2016 at 17:01

Ah now I see it... 🙂

And the pointer points where exactly (as verified by single-stepping in the debugger)? JW

[CharlieMangold]

Posted on October 24, 2016 at 17:41

Yes all the pointers are correct. What is strange is that when I break on the error and then look at the flash contents(not the stack data that was read from it), it is fine. So my thought was stack corruption or some strange flash read issue.

John C.

[waclawek.jan]

Posted on October 24, 2016 at 18:18

OK, so produce a minimal, but complete compilable example exhibiting the problem and post it together with the disassembly.

JW PS. I meant, *tell us* the value of the pointer, not whether it's correct or not.

[CharlieMangold]

Posted on October 24, 2016 at 19:35

The two flash data structures are defined to the flash array memory sector:
 const uint8_t __attribute__((section (''.flash_array''))) UL1[sizeof(EE_UL_CRIT_DATA)] __attribute__((aligned(4))) = UL_SETTINGS;
const uint8_t __attribute__((section (''.flash_array''))) UL2[sizeof(EE_UL_CRIT_DATA)] __attribute__((aligned(4))) = UL_SETTINGS;

The flash_array section begins at 0x0800F000 and that is what ptr1_p is assigned to when it callsread_flash_byte() during a failed condition. That flash location is on a 4K boundary. I'd love to simply post my debugger screenshot but the web site will not allow for anything over 100KByte pics. John C.

[waclawek.jan]

Posted on October 24, 2016 at 19:47

OK, so now the minimal, but complete compilable example exhibiting the problem.

JW

[CharlieMangold]

Posted on October 24, 2016 at 20:20

Hey JW,

             Before I go down that road let me ask if you know of any issues involving reading flash from a STM32F030 device? The key for me to post working code would be to remove any company information from UL1/UL2 data structure. That would take me a small amount of time to do and I'm not against that, but the main reason I posted was the hope that someone would know of a flash issue and reply(as I've not seen any flash read issues in my searches.)  Thanks,      John C.

[Tesla DeLorean]

Posted on October 24, 2016 at 20:48

I've not really heard of any issues with the FLASH of the F0 parts, there are no ART or cache issues.

It is far more probable that your tool-chain or debugger are introducing failures. You'd want to look very carefully at the generated code, with particular attention to optimization, volatile memory, and code/register folding.You can do the assembler code analysis yourself. That you use some other non-proprietary data in the test eliminates specific pattern sensitivity from the mix. Your time creating a stand-alone demonstration will not be wasted, the simpler the better, it will either prove you have a demonstrable problem or not, and will advance a case with ST support, and the user base of the forum, who don't work for ST and have no vested interest in your issue. If there is not an issue called out in the errata, you'll need to demonstrate it is a hardware fault.