2016-10-24 06:36 AM
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
2016-10-25 11:50 AM
Hey Clive,
Seems that running without the debugger works well. I'm trying to get a serial port running to the PC but need the 5v to 3.3v converter. Could the debugger be stepping on the flash storage area at 0x0800F000? Thanks, John C. gcc version: gcc version 5.3.1 20160307 (release) [ARM/embedded-5-branch revision 234589] (GNU Tools for ARM Embedded Processors (Build 16.04-3))2016-10-25 12:20 PM
SiLabs USB-to-CMOS Serial works well and directly. Tend to prefer this over going to RS232 levels.
The debugger tends to be more invasive than most people appreciate. ie enabling clocks, tweaking registers, etc2016-10-26 07:05 AM
Got the serial working with a RS232 to USB TTL converter that also had a 3.3v or 5v jumper. The serial code I got from an example in the standard peripheral library that uses the Tx/Rx interrupts. It seems fine, but I was curious if you used the DMA capabilities for serial receiving/transmitting?
Thanks, John C.2016-10-26 08:16 AM
To be honest I'm not hugely into the Cortex-M0, it is a bit of a regression, I've been using 32-bit systems for some 30 years, no one had to pry an 8051 from my cold dead hands..
I've use DMA TX on the USART of several STM32 parts, and provided numerous examples on the forum. I'm not a big fan of doing DMA RX unless dealing with continuous streams, as the management overhead vs an efficient IRQ seems hard to make in most cases. ie prefer simplicity and robustness.On the TX side a scatter-gather, or chain implementation is quite easy2016-10-26 08:22 AM
One of the stated design goals of the Cortex-M0 was to finally club all the 8-bit micro-controller adherents in the head...
2016-10-26 12:16 PM
Hey Clive,
Thanks for the input on the TX serial DMA(I did not like that the interrupts keep firing when the transmitter is empty.) I do understand your point of view as my last 25 years it was always 32bit. Where I am now has PIC's, but with the price/performance of the M0's it is a pretty easy decision. Thanks again for all the help. John C.