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