RAM memory issue on STM8L151G6

[johnhulst9]

Posted on September 28, 2012 at 17:41

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

John

[luca239955_stm1_st]

Posted on September 29, 2012 at 09:42

post the assembler that your compiler generated for that loop (listing file or disassembly window)

[johnhulst9]

Posted on October 03, 2012 at 12:10

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.

John

[johnhulst9]

Posted on October 22, 2012 at 13:36