2012-09-28 08:41 AM
RAM memory issue on STM8L151G6
When using the RAM there are five addresses that I cannot change by software: 0x102, 0x12F, 0x237, 0x24D and 0x2A9.
I am using the following test code;
for (i=(unsigned char *)0x000;i<(unsigned char *)0x7ff;i++) *i= 0x11;// RAM test
When running the test code I see with the ST-Link SWIM debugger that the memory for the five addresses stays unchanged.
This is also valid for memcopy or the
_fctcpy('F')
.
I can change the contents with the SWIM without a problem (for example a fill memory).
It is like these RAM addresses are blocked for writing from software.
The addresses are not always the same, but mostly it is in the same memory range. When changing the location of the RAM segment in the linker the first two addresses move also, for example setting RAM to 0x300 instead of 0x100: the “bad� address 0x102 become 0x302.
Also by changing the board the addresses were identical!
Sometimes I do not see the issue at all. On the zero page RAM (that we use for all variables), I have never seen an issue.
Do you have any idea what this issue might be?For me it sounds like the environment is somehow blocking RAM for changing, although I don’t see how RAM can stay blocked.
The RAM is required to run block flashing and block erasing routines from RAM to optimize the flashing and reduce the energy usage.
Thanks John2012-09-29 12:42 AM
2012-10-03 03:10 AM
Hello Luca,
Thanks for your reply. I don't suspect the assembly, while I see the same issue with the standard _fctcpy('F') and memcpy at the same addresses. John2012-10-22 04:36 AM