Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix check for rtc mem sdk api in ESPClass #5330

Closed
wants to merge 8 commits into from
Closed

Fix check for rtc mem sdk api in ESPClass #5330

wants to merge 8 commits into from

Conversation

devyte
Copy link
Collaborator

@devyte devyte commented Nov 9, 2018

Also:
-added extra check to disallow zero-size read/writes
-added some comments to explain the rtc mem layout, api, interface
Fixes #2875

@devyte
Copy link
Collaborator Author

devyte commented Nov 9, 2018

Looks like I messed something up with git, but I think it should be resolved once #5327 is merged.

@mcspr
Copy link
Collaborator

mcspr commented Nov 11, 2018

I think it should also mention Updater/eboot interaction, see #619 (comment)

void eboot_command_write(struct eboot_command* cmd)

eboot_command_write(&ebcmd);

OTA update will overwrite first 128 bytes of user section

@devyte
Copy link
Collaborator Author

devyte commented Nov 12, 2018

@mcspr I don't think that's correct. I think eboot is using the first 128 bytes (i.e.: first half) of the system data, not part of the user data.
What is interesting in your linked comment is that the second half of the system data appears to not be used at all. Per the referenced testing, it seems to be safe to use by the user. Still, it is specified as reserved by Espressif, which means it could be used in the future.

@mcspr
Copy link
Collaborator

mcspr commented Nov 12, 2018

Per https://github.com/esp8266/esp8266-wiki/wiki/Memory-Map#memmory-mapped-io-registers
0x60001100 is system section, for 0x100 / 256 bytes
0x60001200 is user section

#define RTC_MEM ((volatile uint32_t*)0x60001200)

eboot writes to the user portion here, am i wrong?
e.g. writing using 64 offset and reading directly from that address would return the same data value:

#define RTC_MEM 0x60001200
uint32_t data = 1751720192;
system_rtc_mem_write(64, &data, 4);
data = ((uint32_t*)RTC_MEM)[0];
Serial.println(data);

(nodemcu source used as reference, checking how rtcmem used there)

edit: and sorry for hijacking the pr, as it is only partially related. maybe this is better served as a documentation issue instead of adding code comments.

@devyte
Copy link
Collaborator Author

devyte commented Nov 12, 2018

@mcspr I misread the RTC_MEM define at a glance.
So you're right: that means that the first 128 bytes of the RTC user mem can't be used if Updater is in play. Please open an issue with request for documentation, and reference this discussion. In the meantime, I'll update the comments in this PR.

Note: comments should be added to the Updater section and ESP-specific APIs section.

Explain interaction between RTC user mem and OTA, where Updater saves the eboot command in the first 128 bytes of RTC user mem.
@devyte
Copy link
Collaborator Author

devyte commented Nov 24, 2018

Closing in favor of #5372 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants