Tufty w/ Firmware 1.20.1

[insanire-monachus]

Tufty will not turn on after flashing it w/ firmware v.1.20.1 - revered back to 1.19.18.

(1) Flashed Tufty 2040 w/ 1.20.1
(2) System didn't boot nor turn on afterwards.
(3) Tried different USB ports on my laptop - nada
(4) Tried different USB cables - nada
(5) Bootloaded back to 1.19.18 - system booted, no issues.

[helgibbons]

Yep, I'm getting this with 1.20.1 too.

[Gadgetoid]

I can replicate this, though my local builds work fine. Trying to figure out why.

In the interim, v1.19.18 and v1.20.1 are basically the same.

[Gadgetoid]

This should be fixed in the next release. I think somehow the Tufty firmware was overwriting itself with the user filesystem since there are no checks and balances during compilation to make sure the two don't overlap.

[insanire-monachus]

Curious, could you please explain further the details on how the Tufty firmware is overwriting itself? - Why has it not happened before, in the previously builds? - And why... there are missing checks and balances?

Always good to learn how things are put together...

[insanire-monachus]

Gadgetoid: Confirmed Tufty is back in action w/ 1.20.1 firmware. Awesome!! - Thanks so much!! 💯

[insanire-monachus]

One item I noticed - previously to 1.20.2 firmware I was unable to run my badge under 565 due to memory error. But now it works. Though if I set the WHITE to 255, 255, 255 I get screen flickers (bad). So instead my WHITE is 246, 246, 247.

[Gadgetoid]

Curious, could you please explain further the details on how the Tufty firmware is overwriting itself? - Why has it not happened before, in the previously builds? - And why... there are missing checks and balances?

Always good to learn how things are put together...

Whew, this is a complicated one. It's a side-effect of how MicroPython handles the flash.

The long and short of it is that both the firmware and the user filesystem live on the same, contiguous, flash chip.

The firmware is configured to know where the user filesystem should start, but it's not very smart about it. All we get is a config constant from the Pico SDK board config which says how much flash the board should have, and another constant from MicroPython's board config which says how much user filesystem there should be.

The practical upshot of this is that - in MicroPython's RP2 port - there is no check at compile time, and no check at runtime to see if the firmware and user filesystem regions overlap. I tried to venture some means of accomplishing this via micropython/micropython#8680 but it's not straight forward to fix.

Oh and it has happened before, I just usually catch those 😆 but both our code and MicroPython tend to grow/shrink sporadically so it's difficult to predict where we might end up.

I am still absolutely baffled why it happened with Tufty in particular, and not entirely sure it is what happened. But as long as it works now I'm not going to rock the boat too much. I've been doing a lot of work to make our builds less weird, fragile and against-the-grain but there's still more to do.

Though if I set the WHITE to 255, 255, 255 I get screen flickers (bad)

Is this with PEN_RGB565? It could be a side-effect of a recent change: 652de85

[helgibbons]

The flickering sounds like you might be running into #567 ?

[Gadgetoid]

Eek, that seems plausible @helgibbons - I don't know how that sailed by me. I can very easily replicate it but I don't have any great ideas why it's happening. Have moved over to that issue to explore further.

[insanire-monachus]

"The flickering sounds like you might be running into #567?" -- yes it is.

[helgibbons]

Closing this one as I think the original issue is sorted.