ESP8266 Developer Zone The Official ESP8266 Forum 2015-04-17T08:25:40+08:00 https://bbs.espressif.com:443/feed.php?f=7&t=347 2015-04-17T08:25:40+08:00 2015-04-17T08:25:40+08:00 https://bbs.espressif.com:443/viewtopic.php?t=347&p=1379#p1379 <![CDATA[Re: system_rtc_mem_read issue]]>
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

Statistics: Posted by eyal — Fri Apr 17, 2015 8:25 am


]]>
2015-04-16T16:11:15+08:00 2015-04-16T16:11:15+08:00 https://bbs.espressif.com:443/viewtopic.php?t=347&p=1365#p1365 <![CDATA[Re: system_rtc_mem_read issue]]>
OK. Any update about this problem,please let us know ~

Thanks for your interest in ESP8266 !

Statistics: Posted by ESP_Faye — Thu Apr 16, 2015 4:11 pm


]]>
2015-04-15T16:32:25+08:00 2015-04-15T16:32:25+08:00 https://bbs.espressif.com:443/viewtopic.php?t=347&p=1338#p1338 <![CDATA[Re: system_rtc_mem_read issue]]>
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
20150415.tar.gz

Statistics: Posted by eyal — Wed Apr 15, 2015 4:32 pm


]]>
2015-04-15T10:01:59+08:00 2015-04-15T10:01:59+08:00 https://bbs.espressif.com:443/viewtopic.php?t=347&p=1328#p1328 <![CDATA[Re: system_rtc_mem_read issue]]>
Sorry for the inconvenience.

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

Statistics: Posted by ESP_Faye — Wed Apr 15, 2015 10:01 am


]]>
2015-04-13T13:22:57+08:00 2015-04-13T13:22:57+08:00 https://bbs.espressif.com:443/viewtopic.php?t=347&p=1306#p1306 <![CDATA[Re: system_rtc_mem_read issue]]>
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:

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:

> 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:

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:

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:

#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:

#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]

Statistics: Posted by eyal — Mon Apr 13, 2015 1:22 pm


]]>
2015-04-13T10:00:15+08:00 2015-04-13T10:00:15+08:00 https://bbs.espressif.com:443/viewtopic.php?t=347&p=1302#p1302 <![CDATA[Re: system_rtc_mem_read issue]]> please use the newest version SDK to test again, version >= 1.0.0.

here is my test code:

Code:

    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

Statistics: Posted by jackon — Mon Apr 13, 2015 10:00 am


]]>
2015-04-10T22:19:29+08:00 2015-04-10T22:19:29+08:00 https://bbs.espressif.com:443/viewtopic.php?t=347&p=1289#p1289 <![CDATA[system_rtc_mem_read issue]]>
If I do something simple like

Code:

system_rtc_mem_read (64, p, 4)

then I get the 4 bytes.

However, if I do

Code:

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:

system_rtc_mem_read (64, p, 8)

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

Code:

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

Statistics: Posted by eyal — Fri Apr 10, 2015 10:19 pm


]]>