system_rtc_mem_read issue

[eyal]

I find the rtc_mem feature very useful and am using it. However, I find that while it works it doess not do what the doco says (2C page 20).

If I do something simple like

Code: Select all

system_rtc_mem_read (64, p, 4)

then I get the 4 bytes.

However, if I do

Code: Select all

system_rtc_mem_read (65, p, 4)

I do not get the next "block". The program reboots. Same for 62 and 63 but 64 is good again.

Moreover, if I read more data

Code: Select all

system_rtc_mem_read (64, p, 8)

I get 8 bytes which are the same as I get with

Code: Select all

system_rtc_mem_read (64, p, 4)
system_rtc_mem_read (68, p+4, 4)

The doco says very clearly that each item in src_addr represents a 4-byte block of memory, so address 65 should be 4 bytes later that 64 and 68 should be 16 byes later than 64. It is not.

What am I missing? I can see that this feature is used regularly so it must be working properly, something I want to understand.

TIA

[jackon]

hi, eyal
please use the newest version SDK to test again, version >= 1.0.0.

here is my test code:

Code: Select all

    uint8 rd[32];
    uint32 wr[2] = {
        0x12345678,
        0x87654321
        };
   
    system_rtc_mem_write(64, wr, 8);
   
    system_rtc_mem_read(64, rd, 4);
    os_printf("64 %x\n", *(uint32 *)rd);
   
    system_rtc_mem_read(65, rd, 4);
    os_printf("65 %x\n", *(uint32 *)rd);
   
    system_rtc_mem_read(64, rd, 8);
    os_printf("64 %x, 65 %x\n", *(uint32 *)rd, *(uint32 *)(rd + 4));


and the output is:
64 12345678
65 87654321
64 12345678, 65 87654321

[eyal]

Thanks @jackon

First, I am using v1.0.1b1 for the last 10 days.

Now I know that it is best to not involve other software but bear with me - I use lua fw.

Here is the function I use. It is mostly the code offered above which works for you, except for the way it presents the results.
os_printf() does not work for me, I assume lua is holding the serial port.

Code: Select all

static int misc_rtc_mem_test8(lua_State* L)   /* DEBUG */
{
    uint8 rd[32];
    uint32 wr[2] = {
        0x12345678,
        0x87654321
        };
    uint32_t nret = 0;
   
    system_rtc_mem_write(64, wr, 8);
 
    system_rtc_mem_read(64, rd, 4) ;
    lua_pushinteger( L, (uint32_t)*(uint32 *)rd); ++nret;

//  system_rtc_mem_read(65, rd, 4);
//  lua_pushinteger( L, (uint32_t)*(uint32 *)rd); ++nret;

    system_rtc_mem_read(64, rd, 8);
    lua_pushinteger( L, (uint32_t)*(uint32 *)rd); ++nret;
    lua_pushinteger( L, (uint32_t)*(uint32 *)(rd + 4)); ++nret;

    return nret;
}

You will notice that the access to address 65 is commented out. The program crashes if I allow it.
Here is the invocation, to prove that the function works

Code: Select all

> a,b,c=misc.rtc_mem_test8()print (string.format("64 %x, 64 %x, 65 %x", a, b, c))
64 12345678, 64 12345678, 65 87654321
> a,b,c=misc.rtc_mem_test4()print (string.format("64 x%x, 64 x%x, 65 x%x", a, b, c))
64 x12345678, 64 x12345678, 65 x87654321
>

It is clear that the correct data is written and read. The problem is that I cannot access address 65. To show that addressing generally works I now write/reads 32 bytes (8 blocks).

Code: Select all

static int misc_rtc_mem_test32(lua_State* L)   /* DEBUG */
{
    uint8 rd[32];
    uint32 wr[8] = {
        0x11111111,
        0x22222222,
        0x33333333,
        0x44444444,
        0x55555555,
        0x66666666,
        0x77777777,
        0x88888888
        };
    uint32_t nret = 0;
   
    system_rtc_mem_write(64, wr, 32);
 
    system_rtc_mem_read(64, rd, 4) ;
    lua_pushinteger( L, (uint32_t)*(uint32 *)rd); ++nret;

    system_rtc_mem_read(68, rd, 4);
    lua_pushinteger( L, (uint32_t)*(uint32 *)rd); ++nret;

    system_rtc_mem_read(64, rd, 32);
    lua_pushinteger( L, (uint32_t)*(uint32 *)rd); ++nret;
    lua_pushinteger( L, (uint32_t)*(uint32 *)(rd + 16)); ++nret;

    return nret;
}

And this is what I get:

Code: Select all

a,b,c=misc.rtc_mem_test8()print (string.format("64 x%x, 64 x%x, 65 x%x", a, b, c))
64 x12345678, 64 x12345678, 65 x87654321
> a,b,c,d=misc.rtc_mem_test32()print (string.format("64 x%x, 68 x%x, 64 x%x, 68 x%x", a, b, c,d))
64 x11111111, 68 x22222222, 64 x11111111, 68 x55555555

The first two numbers are from individually reading these two addresses. The second pair if from a single read of 32 bytes at 64.

As can be seen, directly reading address 68 returned x22222222, which is only 4 bytes in when it should be 4 blocks (16 bytes) and return x55555555.

The original problem remains: why can I not read address 65 (or any address not aligned on 4)? It seems that the function treats the address as a byte address and not a block address.
I tested (elsewhere) and found that it still limits the address to below 192 which is the number of blocks in the RTC memory.

Inspecting at 74880 or 115200 baud has no information apart from the usual bootup messages.

[later] I now see a recent b2 package available, I will install it and test soon.

cheers

[a bit later] I now tested with v1.0.1.b2 with the same results. This rebuild reminded me that there are two fixes I always have to apply for the build to complete. Could this be related?

1) in include/sys/fcntl.h we have at line 31

Code: Select all

#include <xtensa/simcall-fcntl.h>

I do not have this file so I removed the line. I later grabbed the missing header from the rtos repository.

2) in include/machine/setjmp.h we have at line 209

Code: Select all

#if __XTENSA_WINDOWED_ABI__

This symbol is not defined so I changed it to '#ifdef' (I actually tested #ifdef and #ifndef but saw no change in the results).

cheers
[I edited the reply to make it a bit shorter and clearer]

[ESP_Faye]

Hi,

Sorry for the inconvenience.

Could you offer your whole project for debugging ? And dump file, .s file , crash logs .

[eyal]

[earlier version of this post removed]

I grabbed the basic_example program
https://github.com/esp8266/source-code- ... ic_example
and inserted the short program presented earlier by @jackon and I do get the expected results.

I now need to figure out why I get different results when making the same sdk api call from the lua firmware than when done from the sdk directly.

I will follow up in their forum.

[later] Testing basic_example with SDK 0.9.5patch1 is showing the problem did exist then. Problem closed.

Thanks

[ESP_Faye]

Hi，

OK. Any update about this problem，please let us know ~

Thanks for your interest in ESP8266 !

[eyal]

I do not expect progress in the near future. The nodeMCU lua firmware is locked to SDK 0.9.5 (which has the bug, not now fixed) and all I can do is work around the issue and wait for the project to move to the SDK 1.0 series.

My threads there
https://github.com/nodemcu/nodemcu-firmware/issues/362
https://github.com/nodemcu/nodemcu-firmware/issues/311

As I said earlier, this issue should be closed, it is not an SDK problem.

Thanks