ESP8266 Community Forum

- Mon Apr 06, 2015 11:51 am #13647 Hello all,

I have made working compilation chain with eclipse/mingw as described everywhere.
Everything looks working fine. I played with nodemcu firmware from examples and I do not understand two strange things :
1) there is used readvdd33() function. I can not find any header for it all around ( any file containing this text, only several appearances of libphy.a in esspresiff folder). So how is compilation possible ? Any trick with linker or so ?
2) I made my own lua commands, for read and write to RTC memory. The strange thing is with addresses in memory.
In manual of sdk api is written prototype bool system_rtc_mem_read ( uint32 src_addr, void * des_addr, uint32 save_size),
but in user_interface.h ( all in nodemcu and sdk folders ) is prototype bool system_rtc_mem_read(uint8 src_addr, void *des_addr, uint16 load_size)
So what is format of src_addr ? And, the more strange thing is when I try to access memory of multiple 4 numbers ( like 0,4,8,12,16 ... ) it looks working, but accessing other ( non multiple 4 ) addresses causes the ESP to reboot. This looks like there is not done the multiplication as in SDK API guide, but then 8bit address is not enough to be used for 768 bytes. Also it looks like there is repetition each 256 adressess, e.g. I read the same from address 4 and 260 ( or 64 and 256+64 ).

Can somebody help me to understand ?

- Mon Apr 06, 2015 12:15 pm #13649 Oh, so I can answer readvdd33 part now by myself - viewtopic.php?f=9&t=2040.
But I still do not understand to rtc memory problem ...

- Mon Apr 06, 2015 12:53 pm #13651

I made my own lua commands, for read and write to RTC memory. The strange thing is with addresses in memory.
In manual of sdk api is written prototype bool system_rtc_mem_read ( uint32 src_addr, void * des_addr, uint32 save_size),
but in user_interface.h ( all in nodemcu and sdk folders ) is prototype bool system_rtc_mem_read(uint8 src_addr, void *des_addr, uint16 load_size)
So what is format of src_addr ?

Reading system_rtc_mem_read disassembly I'd say that its prototype is
bool system_rtc_mem_read ( uint32 src_addr, void * des_addr, uint32 save_size).
It analyzes and uses 32-bit value passed as first argument. It also analyzes 32-bit value passed as third argument, but later only uses 16 bits of it.
The first argument is not a byte address or byte offset, but a 32-bit word offset. The last argument is however a byte count.

And, the more strange thing is when I try to access memory of multiple 4 numbers ( like 0,4,8,12,16 ... ) it looks working, but accessing other ( non multiple 4 ) addresses causes the ESP to reboot.

With this API you can't access addresses in RTC that are not multiple of 4 bytes. And addresses in your data memory shall be aligned properly. Also if you pass non-multiple-of-4 length the function rounds it up to the next multiple of 4 and uses extra memory in des_addr.

This looks like there is not done the multiplication as in SDK API guide, but then 8bit address is not enough to be used for 768 bytes. Also it looks like there is repetition each 256 adressess, e.g. I read the same from address 4 and 260 ( or 64 and 256+64 ).

The math there looks correct to me.

- Mon Apr 06, 2015 2:07 pm #13658 Thanks a lot for answer.
So, the prototype is like in SDK manual. Clear.
This is what is in manual :
Function: Read user data from RTC memory. Only “user data” area here can
be used by user.
|_ _ _ _ _system data _ _ _ _ _|_ _ _ _ _ _ _ _ _ user data _ _ _ _ _ _ _ _ _|
| 256 bytes | 512 bytes |
Note: RTC memory is 4 bytes aligned for read and write operations. Parameter
“src_addr” means block number(4 bytes per block). So, if we want to read some
data from the beginning of user data area, “src_addr” will be 256/4 = 64,
“save_size” will be data length.
Prototype：
bool system_rtc_mem_read (uint32 src_addr, void * des_addr, uint32
save_size)

Then, if the function behaves also like in manual, it should accept as first parameter values 0-63 for system data and 64-191 for user data. API function will internally multiply by 4, and this will result in 4-byte alligned adress.
So why odd ( not multiple 4 ) values causes restart ?

OK, lets say the function do not behave like in manual, but takes address just as a number. I have to take care about it, that it can be divided by 4. This explains the reset. But why the values then repeat each 256 bytes - can it be because the header files use only 8bit prototype for address by mistake ? I will have to give it a try.