-
Notifications
You must be signed in to change notification settings - Fork 5
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
Not all data in DMAMEM/RAM2 survives a warm reset/restart #14
Comments
Wrote test sketch to MALLOC DMAMEM and test in 1KB blocks. Locked T_4.1 pollutes first 39-40KB, and also 1KB more at start +~64KB? Unlocked 1062 startup pollutes the first ~34KB Cold start - no block matches of course Will update if the sketch cleans up nicely for posting and perhaps improve results display. |
shared this https://github.com/Defragster/TeensySketches/tree/main/RamPersistTest DRAM Persist test Start Address 0x20203088 End at 0x2027fc88 |
In : https://github.com/TeensyUser/doc/wiki/The-Watchdog-timer
This is not entirely true. Some portion of lower (?) DMAMEM is used by the security HAB (?) code before startup and data stored there will be wiped and overwritten. There is a forum post somewhere - or it could be tested - some 32KB (???) area is disturbed as the processor wakes up and verifies chip security. Any area above that - that was flushed from cache - will be retained. The area used may be different between Locked and UnLocked as well???
// DMAMEM causes allocation in 'static' RAM2 on Teensy using 1062 processor
// It is not initialized and will retain value while powered
// BUT - it writes through a cache that must be flushed to assure it is current
// This works for any DMAMEM allocation of any variable type or structure
The text was updated successfully, but these errors were encountered: