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

[Bug] Ensure smooth upgrade path to V3.6.0 #1846

Closed
laurensvalk opened this issue Sep 25, 2024 · 6 comments
Closed

[Bug] Ensure smooth upgrade path to V3.6.0 #1846

laurensvalk opened this issue Sep 25, 2024 · 6 comments
Labels
bug Something isn't working software: pybricks-micropython Issues with Pybricks MicroPython firmware (or EV3 runtime)

Comments

@laurensvalk
Copy link
Member

We have slightly changed the persistent storage area from V3.6.0b1 onwards. This firmware will also erase the user data if the stored firmware hash does not match that of the current firmware, to prevent issues with future updates. This makes the experience similar to that of the Technic Hub, which erases the data between updates.

But version V3.5.0 did not yet handle deletion in this way, so we'll want to make sure upgrading goes smoothly. If necessary, we can release a version V3.5.1 on the stable channel to prepare.


Trying to run (F5) a new program on 3.6.0b1 did the power-off. I did not try to start the "old" program.

For clarity and re-tested:

The program:

while True:
    pass
  • download 3.5.0 standard via beta.pybricks.com (over 3.6.0b1)
  • (F5) download a new program and run OK
  • download 3.6.0b1 over this 3.5.0
  • pull the USB cable (otherwise I do not see the hub power-off)
  • (F5) download a new program and run results (after ~ a second) in power-off.
    I see no animation on the display to indicate the program is running
  • then re-install 3.6.0b1 over 3.6.0b1 does not help.

Originally posted by @BertLindeman in #1577 (comment)

@laurensvalk laurensvalk added bug Something isn't working software: pybricks-micropython Issues with Pybricks MicroPython firmware (or EV3 runtime) labels Sep 25, 2024
@laurensvalk
Copy link
Member Author

Here's why this is happening. If you install 3.6.0b1 and then 3.5.0 and run a program, all seems to work fine, but the saved firmware version is unchanged since 3.5.0 does not erase it. So on 3.5.0 open a REPL and type:

>>> hub.system.storage(0, read=8)
b'e75cda81'

Which is the version corresponding to 3.6.0b1. So when you then install 3.6.0b1 again, it doesn't do the erase. But since it does contain a program loaded with 3.5.0, it fails and gets confused.

So to "fix" your hub, @BertLindeman, you can just enter the following on a REPL on version 3.5.0:

hub.system.storage(0, write=bytes(8))

Then turn off normally and install any version you like.

@laurensvalk
Copy link
Member Author

So maybe we need a checksum to account for hubs that did not yet store the firmware version, to ensure this isn't an issue when we release a beta version via Pybricks Code in a few weeks.

@laurensvalk
Copy link
Member Author

Fixed introduced. Switching between the latest nightly and 3.5.0 and back again should now work if you run a new program. So once we release this in Pybricks Code beta, everyday users should not be experiencing this issue.

@BertLindeman
Copy link

Just to confirm: install of nightly build over 3.5.0 (and back) does erase the existing program from the hub.

Just did the swap 3.5.0 build 3567. No problem anymore.

@laurensvalk
Copy link
Member Author

Thanks @BertLindeman, this was an important one, so I'm glad you caught it before we release the beta!

@laurensvalk
Copy link
Member Author

This is resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working software: pybricks-micropython Issues with Pybricks MicroPython firmware (or EV3 runtime)
Projects
None yet
Development

No branches or pull requests

2 participants