White Screen after attempting update from older dev version: v0.9.0.1

Bug Reports and Fixes
1

I’m not sure if this is the right place for this, but figured there might be other dev folks coming back to check out the release firmware and might get into a similar spot.

How I got here
I was attempting to update from an older firmware version (v0.9.0.1… ) using the USB Stick / SD Card in-system update method. I got a verification error when it was trying to figure out if I had a wifi card, and I thought maybe I should try an earlier firmware and incrementally upgrade. I tried loading v0.11 and that seemed to go well, but when I power cycled after the power-cycle instruction screen, it just rebooted to a white screen.

Trying USB-DFU
When trying the USB-DFU approach (holding down the rotary encoder during power-on), the webdfu sees the device as:

DFU in HS Mode @Device ID /0x500 , @Revision ID /0x0000 ...

and when I attempt to connect, it gives me a variety of partitions to connect to, none of which seem to successfully accept the main.uimg file.

One other detail is that when booting with the rotary encoder pressed, the green button LED never comes on.

I’m wondering if I should have updated with the ‘bl’ firmware? That might have updated my bootloader, but I thought since I was past v0.6 that didn’t seem needed.

Trying JTAG programming
Next I pulled down the latest repo to macOS, and built the main branch. Using make jprog with the Freeze Jumper in place, my J-Trace connects and identifies the Cortex-A correctly but fails to burn the device (I should be able to pick up a J-Link from the office next week, in case that is better).

Success with booting from SD card
However, on a positive note, booting from SD Card using make flash-app-sd works perfectly (with the Boot Select switches set appropriately). I tried running a firmware update from there using a USB Stick with the latest release version, and that worked perfectly this time. It saw that I didn’t have a wifi expander and dealt with that correctly. But, when I set the Boot Select switches back to normal (top->left, bottom->right), it still booted to the white screen. (It probably updated the SD Card, which would make sense.)

Unit is physically fine
So it seems like the unit is functioning perfectly well, but there’s something about the boot process that I’ve damaged and don’t know how to fix.

How to recover, or is booting from SD card okay?
I’d welcome any suggestions or requests for tests! And mostly just don’t want this to eat up valuable support time, but I’m looking forward to testing out the release firmware. Maybe booting from the SD card is fine?

2

In retrospect, I skipped to firmware v 0.11 because of the vcv version of 0.9 just before it in the release list, and I still hadn’t quite clocked the difference between them, otherwise I really ought to have done v0.10 first.

3

Ah yes, older firmware versions gave an error if the wifi binaries are in the update files but no wifi expander is connected. The error is actually just a warning – assuming you got no other errors, then the firmware was probably updated OK.

I don’t think this is the MetaModule. Could it be that it found some other device on your USB bus?
The MetaModule is detected as:

Name: STM Device in DFU Mode
MFG: STMicroelectronics
Serial: 375xxxxxxxxx
DFU: [0483:df11] cfg=1, intf=0, alt=0, name="STM Device in DFU Mode" serial="375xxxxxxxxx"
Selected memory region: NOR Flash (13.5MiB)
0x70080000-0x70dfffff (readable, erasable, writable)

Hmm… yes, it sounds like the MetaModule never connected to the webdfu, and you picked a different device by accident?

Do you by chance have the Freeze jumper installed? That will halt execution before the USB DFU bootloader gets a chance to run, so remove it if you want to use DFU.

Yeah, Cortex-A support from segger is only for certain J-Link devices, and not for J-Trace devices. We’ve actually gotten the J-Trace to successfully flash the Cortex-A sometimes but it’s not reliable and segger officially says the device does not support it.

No, it would have flashed the internal flash. The in-app updater will always write to internal Flash regardless of the startup method.
So, booting with the SD Card and then using the in-app updater is how I would recommend getting it up and running again. Try flashing using the all.zip file from v0.9.0 and see if it boots. Then incrementally work up to v1.0.
BTW in pre v1.3-ish firmwares, the wifi firmware files are called application.bin, bootloader.bin and filesystem.img. Attempting to flash them without a Wi-Fi expander connected will give an error which can be ignored. If you want, you can edit the metamodule.json file in the firmware folder and remove the entries for those three files.

Also, booting from the SD Card is totally fine. It’s slightly slower (perhaps that depends on the SD card’s speed class?), but once startup is done there is no difference in execution regardless of how you started up. All that happens whether you boot from SD Card or from internal flash is the firmware is loaded into RAM. After you see the GUI screen, you can remove the SD Card and it will run 100% fine (that’s actually how we do our initial flashing of blank/new units).

4

Perfect, thanks for this!

I was able to recover by booting from SD and then reloading the old v0.9.0 firmware.

With reference to your suspicions about the USB-DFU connecting to the wrong device, I have two observations just in case they are of use in the future:

  1. I was able to closely correlate the mystery USB device closely with the Metamodule, i.e. when I plugged it in the device appeared in the list, when I unplugged it it disappeared. Also confirmed that the Freeze jumper was off for these tests.

  2. Now that I have recovered and am successfully booting internally to v0.9.0, the correct USB-DFU behavior has appeared. Previously when I booted with the rotary encoder held down, there was no LED indicator and that strange device was present. But now the indicator blinks green and the correct “STM Device in DFU Mode” shows up in the USB list.

So it seems like whatever state I got it into was interfering with the correct USB DFU mode.

Now I’ve been able to upgrade from v0.9.0 to v0.10.0 using the USB Stick, so I think I’m on my way.

Thanks again for the help! Recovering via the SD card was a very smooth experience once I tried putting the last good firmware on.

5

In case anybody else runs into something similar, I was able to get to 1.4.5 relatively easily using these firmware releases:

v0.9.0
v0.10.0
v0.14.2
v1.0.0
v1.4.5

6

Great! Thanks for documenting the progression.

Strange about the mystery DFU device. I’m trying to think of something we did between v0.9 and preset that could have caused that. Hmm…

Well, glad the SD Card method worked. It’s the “emergency back door”, which comes in handy in situations like these.

1 Like
7

It could have been some combination of first trying to upgrade to v1.4.5, and then seeing some errors and trying to upgrade to v0.11 without power cycling?

I haven’t tried to duplicate the way I got it into that state, but if I have a little time later this week, I’ll see if I can repeat my steps and make it happen again. But hopefully it’s not something any normal user will end up facing.