xdata & sleep issue

RE: xdata & sleep issue

Håkon Alseth — Tue, 24 Oct 2017 08:16:39 GMT

Hi,

"const" does not always mean that the variable is placed in flash in C, therefore the "code" is a 8051-specific keyword to force the value into flash.

In your scenario, option 1 can be located in RAM, while option 2 shall be placed in flash.

Best regards,

Håkon

RE: xdata & sleep issue

mr_creosote — Mon, 23 Oct 2017 15:53:19 GMT

Ahhhh... So

const int c[] = { 10,20,30};

// means c, basically an int*, is read-only and stored in flash, BUT array contents are not, whereas,

const code int c[] = { 10,20,30};

// means c and array contents are both read-only and stored in flash.

Is my understanding correct?

Thanks!!

RE: xdata & sleep issue

Håkon Alseth — Mon, 23 Oct 2017 13:59:47 GMT

Hi,

You have 16kB of flash, and you have a lot less RAM.

It is quite common to run out of RAM first, therefore; try placing most of your code in flash where you can (ie: arrays that are read-only for instance).

Best regards,

Håkon

RE: xdata & sleep issue

mr_creosote — Mon, 23 Oct 2017 13:41:01 GMT

Hi Hakon, I hope all is well. what's the value of putting code in flash? Thanks!

RE: xdata & sleep issue

Håkon Alseth — Mon, 27 Mar 2017 07:15:46 GMT

Hi Mahesh,

You need to declare it as "const code" to place it in flash.

Declaring a buffer like this will place it in xdata RAM:

xdata uint8_t buf[size];

Best regards,

Håkon

RE: xdata & sleep issue

mr_creosote — Mon, 27 Mar 2017 07:12:00 GMT

Hi Håkon,

That's what's confusing. Code should be in flash. So what's it doing in RAM? I understand the general way microcontrollers startup and hand off control to main(), but how does that involve code in RAM?

Thanks,

Mahesh

RE: xdata & sleep issue

Håkon Alseth — Mon, 27 Mar 2017 06:24:49 GMT

Hi Mahesh,

Sorry for the late reply.

Remember that your code in this case is placed in RAM, and RAM needs power to hold the content valid.

Flash does not need power to hold it's content.

When you wake up, it depends on how your firmware is set up how you initialize values.

You can read about startup code on keil's website:

http://www.keil.com/support/docs/1728.htm

Best regards,

Håkon

RE: xdata & sleep issue

mr_creosote — Wed, 22 Mar 2017 14:13:29 GMT

Thanks Håkon! Also, why does code use a memory retentive block for? once the firmware is uploaded, isn't it already retained? Thanks! Mahesh

RE: xdata & sleep issue

Håkon Alseth — Wed, 22 Mar 2017 12:03:29 GMT

Hi Mahesh,

Only parts of the RAM is retained in memory retention mode (in order to save power), which is why you'll need to place your buffer in the retained area of the RAM. If you want the full RAM to be powered in sleep, use RegisterRetention.

The RAM is powered off, then you cannot trust the content at all when it is powered on again, and you will get random values. I cannot give an explanation to why it was the same "garbage values", but I suspect that if you add more functions or libraries, or change the behavior in any way, the "garbage values" would also change upon wakeup.

Best regards,

Håkon

RE: xdata & sleep issue

mr_creosote — Wed, 22 Mar 2017 06:57:31 GMT

Hi,

Why does code need a memory retentive block? once the firmware is uploaded, isn't it already retained?

in the example i gave, prior to moving variables into the retentive area, all the values of _p_outbufs[][] were set to 0x55, but were changed to a random-looking but specific data pattern (F4 F0 F0 F8...) which is always the same at every wake-up. what was actually happening? the pattern was not random.

thanks,

mahesh

RE: xdata & sleep issue

Håkon Alseth — Tue, 21 Mar 2017 07:57:45 GMT

Hi,

B & C:

Only half of the RAM (512 bytes of a total 1k) is retained in "memory retention":

A special feature of the nRF24LE1 SRAM block is that it is composed of two physical 512 byte blocks called DataRetentive (lower 512 bytes) and DataNonRetentive.

DataRetentive, in contrast to DataNonRetentive, keeps its memory content during the Memory Retention power down modes (see chapter 11 onpage 105).

DataRetentive is the retained block (powered block in PWRDWN=2 or 3), while the upper 512 bytes are turned off to lower power consumption.

If you want all the RAM powered in sleep, I'd recommend to use "register retention" (PWRDWN=4;).

RegisterRetention does not cause a reset upon wakeup either, which can be beneficial.

The compiler should give you a warning, or possibly a linker error, if you try to do this.

This would be the same as this:

uint8_t xdata a[2] = {0xFF, EE};

uint16_t xdata *b = a;

And that should give b=0xEEFF.

The linker will organize your data to ensure that variables with the _at_ keyword is not conflicting with variables declared without it.

Best regards,

Håkon

RE: xdata & sleep issue

mr_creosote — Tue, 21 Mar 2017 06:05:05 GMT

Hi, I was able to get retention using the _at_ keyword and moving variables, thanks!!! even so, could you still give me answers to the questions above? i believe the answers are:

A. Yes.

B. Yes.

B. (should be C). i don't know the answer to this -- why does code need a memory retentive block? isn't all code already retained?

C. why does this happen?

D. Yes, that was the problem.

E. if there's an overlap between absolute placement of variables, the compiler raises a warning. does this mean that i could deliberately superimpose two variables, e.g.

uint8_t xdata a[2] _at_ 0x004;

uint16_t xdata b _at_ 0x004;

a[0]=0xFF;

a[1]=0xEE;

the value of b will be 0xEEFF. is that correct?

RE: xdata & sleep issue

mr_creosote — Mon, 20 Mar 2017 18:14:39 GMT

Hi Håkon,

A. does Fig. 37 & table 26 mean that the 2 data blocks are *always* contiguous?

B. please confirm: the blocks can be set to be EITHER location; there are NOT two sets of blocks at both 0x0000 - 0x03FF AND 0x8000 - 0x83FF. i have to choose one of the two.

B. isn't code already stored in non-volatile memory? what is the use of marking the SRAM data blocks as code?

C. in the example i gave, all the values of _p_outbufs[][] are set to 0x55, but get changed to a different data pattern (F4 F0 F0 F8...) which is always the same at every wake-up. it isn't a random loss of memory. any idea what is actually happening?

D. _p_outbufs starts at 0x020C in the .M51 file, which is outside the retentive range of 0x0000-0x01FF, if SRAM starts at 0x0000 by default. this might be my problem.

E. i was looking at the _at_ keyword yesterday :-). please confirm: if i use the _at_ keyword, i'm responsible for any conflicts between THOSE variables. the compiler will handle the rest. so if i have two variables at the same absolute location, it won't flag an error. this might be useful for union-like behavior.

Thanks,

Mahesh

RE: xdata & sleep issue

mr_creosote — Mon, 20 Mar 2017 14:51:22 GMT

Hi Håkon,

What is the memory range that's retained? Could you take a look at the .M51 file i sent and see if the storage area for _p_outbufs falls within that range?

Also, could you give me an example of using the _at_ keyword that falls within the retention range?

Thanks!

Mahesh

RE: xdata & sleep issue

Håkon Alseth — Mon, 20 Mar 2017 11:44:35 GMT

Hi,

Memory retention retains only the first 512 byte block of memory, while the upper 512 bytes are powered off. Here's a snippet from chapter 7 in the PS:

A special feature of the nRF24LE1 SRAM block is that it is composed of two physical 512 byte blocks called DataRetentive (lower 512 bytes) and DataNonRetentive.

DataRetentive, in contrast to DataNonRetentive, keeps its memory content during the Memory Retention power down modes (see chapter 11 onpage 105).

Could you try absolute placement on the buffers that you need retained (using the _at_ keyword)?

Cheers,

Håkon