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

Custom heap broken #1994

Closed
mikee47 opened this issue Dec 10, 2019 · 2 comments · Fixed by #1996
Closed

Custom heap broken #1994

mikee47 opened this issue Dec 10, 2019 · 2 comments · Fixed by #1996
Labels
Milestone

Comments

@mikee47
Copy link
Contributor

mikee47 commented Dec 10, 2019

Code built with ENABLE_CUSTOM_HEAP=1 doesn't run.

See #1825 (comment).

e.g. Basic_Blink sample:

make flash ENABLE_CUSTOM_HEAP=1 COM_SPEED=74880

builds and flashes, stops here:

python -m serial.tools.miniterm --raw --encoding ascii /dev/ttyUSB0 74880
--- Miniterm on /dev/ttyUSB0  74880,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---

 ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x40100000, len 1116, room 16 
tail 12
chksum 0x0d
ho 0 tail 12 room 4
load 0x3ffe8000, len 576, room 12 
tail 4
chksum 0xdd
csum 0xdd

rBoot v1.4.2 - richardaburton@gmail.com
Flash Size:   32 Mbit
Flash Mode:   DIO
Flash Speed:  40 MHz

Booting rom 0 at 2000, load addr 30f90.

This was supposed to have been fixed in #1745, but that commit doesn't work either.

@mikee47
Copy link
Contributor Author

mikee47 commented Dec 10, 2019

Found the issue, umm_info is getting called before UMM has been initialised (on first call to malloc). This is the fix:

diff --git a/src/umm_info.c b/src/umm_info.c
index 6868c00..6e25ae3 100644
--- a/src/umm_info.c
+++ b/src/umm_info.c
@@ -20,2 +20,5 @@ UMM_HEAP_INFO ummHeapInfo;
 void *umm_info( void *ptr, int force ) {
+  if(umm_heap == NULL) {
+    umm_init();
+  }

@mikee47
Copy link
Contributor Author

mikee47 commented Dec 11, 2019

There's a call to xPortGetFreeHeapSize() very early in the boot (in call_user_start()) located in libmain.a, part of the Espressif SDK, which triggers this issue. I've checked against SDK version 2.0.0 (which is part of the UDK and I would have been using at #1745) and this issue is not present, so it got changed at some point after that.

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

Successfully merging a pull request may close this issue.

2 participants