BL602: latest release 1.18.24 not starting

[Ga-Ol-St]

Build 1.18.24 not starting, Build 1.18.23 working fine.

Firmware:

• Version: 1.18.24
• Device: Scimagic-RC
• Chip/model: BL602
• Device config:
  { "vendor": "Tuya", "bDetailed": "0", "name": "Full Device Name Here", "model": "enter short model name here", "chip": "BL602", "board": "TODO", "flags": "1074266116", "keywords": [ "TODO", "TODO", "TODO" ], "pins": { "12": "DS1820_IO;0", "14": "Rel;49", "17": "WifiLED_n;46", "21": "Btn_Tgl_All;49" }, "command": "backlog startDriver DS1820;", "image": "https://obrazki.elektroda.pl/YOUR_IMAGE.jpg", "wiki": "https://www.elektroda.com/rtvforum/topic_YOUR_TOPIC.html" }

To Reproduce
Steps to reproduce the behavior:

1. update firmware (OTA or by UART) to 1.18.24
2. See error during boot

error.log.txt

[openshwprojects]

So this commit must be at fault:
77efc7e
Can you help us investigate - flash older version, remove startup command line and then retry newer version? Does new version still crash wih empty command line?
@giedriuslt do you have BL602 and can check?

[openshwprojects]

Maybe stack size is the issue.

[giedriuslt]

I see the same issue, removing command line in safe mode makes it work back.

[openshwprojects]

Can you check is it a stack size issue?

[openshwprojects]

Temporary fix (revert to single line execution):
bc35f97

[divadiow]

with 1.18.24 on BL602 mine stops here

Main_Init_Delay done
Current task sp data:
RA:23093b08, mstatus:80007880
A0:00000128 A1:00000000 A2:00000000 A3:00000000 A4:4201d820 A5:00001000 A6:00001000 A7:000000d6
T0:2308c490 T1:4200f9ec T2:ffffffff T3:00000001 T4:0000000a T5:6e6e6168 T6:43646461
S0:4200e9cc S1:00000118 S2:4200e438 S3:4200e9cc S4:00000ed8 S5:00001001 S6:00000000 S7:00000000
S8:00000000 S9:4201d484 S10:4200f644 S11:a5a5a5a5
Exception Entry--->>>
mcause 38000007, mepc 23093828, mtval 00000004
Exception code: 7
  msg: Store/AMO access fault

this is with loop code

setChannel 30 0
again:
addChannel 30 1
echo Hello $CH30
delay_s 1
goto again

[divadiow]

I wonder if the new SDK does the same thing

[giedriuslt]

Traced crash to realloc call on g_scrBuffer, seems like that does not work with null pointer (or at all?) on bl602
This explains why it worked before, running scripts normally allocates that buffer somewhere else.

[openshwprojects]

https://github.com/search?q=repo%3Aopenshwprojects%2FOpenBL602%20realloc&type=code

We are missing realloc on bl602?

[openshwprojects]

or should it be defined to pvPortRealloc