Invalid `PRUSA SN` observed
I got a very strange error.
It appears that my Prusa stored invalid `PRUSA SN` in a eeprom: "N0 M11CZPX1721X004X". Now, on why it happened.
From what I see:
1. Prusa FW on a first boot tries to send `;S` to read SN from EEPROM
2. Read string is not sanitised so there might be another user of UART (in this case Octoprint over USB) mangling with the communication. Thus why `N0 M11` prefix. This is usually not set by default unless connected to PC, since atmega32u2 is not powered unless PC is connected. Now, if PC connected there's a big chance that Octoprint is on the other end, and it tries to connect very early when Prusa starts.
3. The SN is considered valid as long as it is 19 bytes received in a given period... There's no further validation, so an invalid `SN` can be stored.
4. This prevents `Prusa-Link` from starting as it does not understand returned data.
What I had to do:
1. Disconnect Octoprint
2. Keep PC/SBC connected
3. Do a full factory reset
4. Give it a few moments
5. Validate via Terminal `PRUSA SN`
This will be a problem likely for some users, since this is pretty easy to get. Likely Prusa FW should validate the SN, and reject invalid, and likely retry reading from UART.
RE: Invalid `PRUSA SN` observed
Hi, sorry for the late response. In 3.10.0 there was a bug where updating using the octoprint plugin resulted in exactly this happening. The FW tries to copy the SN from a chip, that's powered only while serial communication is active through USB. There was no validation then, but I think there is now