esp32: ULP programs limited to 512 bytes #8709
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Allow esp32.ULP.load_binary() to use the maximum amount of memory available again (lost in 3d49b15), which is 2040 bytes unless MICROPY_HW_RTC_USER_MEM_MAX is customized.
|
That was definitely an unintended regression. Thanks for picking it up and creating a PR. Rebased and merged in cf550ad |
|
Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Is there a reason why in 3d49b15 (the move from sdkconfig.h to sdkconfig),
CONFIG_ULP_COPROC_RESERVE_MEM = 2040was removed, reverting to the IDF default value 512?This causes
esp32.ULP.load_binary()to fail withOSError: 260(ESP_ERR_INVALID_SIZE) on programs larger than 512 bytes, for no reason that I can see. It is possible to work around the limitation by rewritingload_binary()in Python (everything the underlying IDF functionulp_load_binary()does can be replicated usingmachine.mem32) and the ULP runs the resulting code just fine. (Interestingly enough,ulp_load_binary()only applies the limit to the .text and .data sections of the ULP binary, while the .bss section is allowed to overflow into “non-reserved” memory. I wonder what the point of that is.)In case that was an oversight, the attached commit restores it. As discussed in #3578, 2040 = 4096 -
MICROPY_HW_RTC_USER_MEM_MAX- 8 is the maximum size that fits into RTC slow memory next tortc_user_mem_{data|len|magic}, higher values cause a linker error.I have not looked into whether the value could be computed for non-standard values of
MICROPY_HW_RTC_USER_MEM_MAX, but for now am just restoring the hardcoded value that was there before. Nor have I looked into how to overlap the ULP andmachine.RTC.memory()ranges, as suggested in #3578 (comment).Tested on a UM_TINYPICO board, built with ESP-IDF v4.2.2.