T1000-E reboot breaks companion

[alexsporn]

It seems the filesystem or the prefs get corrupted and only a full erase and re-flash brings the device back.

Steps to reproduce:

• Erase Flash
• Flash 1.13.0 BLE Companion
• Connect MeshCore App to companion
• Trigger reboot (device will never be reachable again)

The only way to get the device out of this state is to do a full erase flash.

[alexsporn]

From researching issues and PRs I think this is something that might interest @oltaco

[IoTThinks]

My T1000-E is on v1.12.
You made me hesitate to upgrade to v1.13 and test.

The only way to get the device out of this state is to do a full erase flash.

[NO534221]

I tried to replicate this on my T1000e with 1.13 standard companion release. I rebooted a couple of times using reboot in the app. No problem here, all good.
Maybe you can try the Development FW?

[weebl2000]

nvm

Still not sure why this happens.

[IoTThinks]

I have just upgraded from v1.12 to v1.13 via uf2 method for my T1000e (2025) with full battery.
Works fine.

[alexsporn]

As I pointed out in my fix for this issue, adding a short delay on init consistently fixes this issue for my devices. Without it they won't boot up again (no buzzer sound, no blinking leds, nothing).

[weebl2000]

@alexsporn just to be clear, it only hangs if you've just flashed the companion after an erase and then reboot right after that?

FYI I went and ordered a T1000e and I received it today so I can help troubleshoot.

Could you try flashing this image:

http://mcimages.weebl.me/?variant=t1000e_companion_radio_ble&commitId=t1000e-boot-debug&MESH_DEBUG=1

It will allow looking at the serial debug logging before meshcore does anything.

[alexsporn]

@alexsporn just to be clear, it only hangs if you've just flashed the companion after an erase and then reboot right after that?

FYI I went and ordered a T1000e and I received it today so I can help troubleshoot.

Could you try flashing this image:

http://mcimages.weebl.me/?variant=t1000e_companion_radio_ble&commitId=t1000e-boot-debug&MESH_DEBUG=1

It will allow looking at the serial debug logging before meshcore does anything.

@weebl2000 this firmware works because you are adding a 15 second delay after boot to allow the USB serial to connect which always fixes the issue. If I comment your initial 15 second delay loop then the board won't boot up anymore.

A simple delay(150) instead of that loop just before board.begin() also fixes the issue. I tested and I could get it to boot with a delay down to 60-65ms, anything below that and the board won't boot reliably. I went with 150ms on my PR since that is more than safe for any hardware variance and it only happens on boot anyways.

This is the reason I added it in the T1000eBoard::begin() on my PR, so that it only happens on the T1000-E.

Using a simple digitalWrite(LED_PIN, HIGH); to see how far in the boot process I can get, I see that the issue is not on the radio_init(), but on the Bluefruit.begin() and adding the delay just before that call also fixes the boot issue. To me it seems there is some kind of issue between setting up the radio and setting up the softdevice for BLE.

[weebl2000]

Using a simple digitalWrite(LED_PIN, HIGH); to see how far in the boot process I can get, I see that the issue is not on the radio_init(), but on the Bluefruit.begin() and adding the delay just before that call also fixes the boot issue. To me it seems there is some kind of issue between setting up the radio and setting up the softdevice for BLE.

Thanks, that pointed me in the right direction. Can you try this PR #1939?

[alexsporn]

Thanks, that pointed me in the right direction. Can you try this PR #1939?

This does not fix it for me, it still hangs.

[weebl2000]

Thanks, that pointed me in the right direction. Can you try this PR #1939?

This does not fix it for me, it still hangs.

added a timeout at 2 seconds for when it never becomes ready.