Firmware - Potential Issue : 30 April 2019 (Latest Update)

A possible firmware issue has come to light which may impact a very small number of petSD+ users; in some circumstances, petSD+ does not appear to start up properly at power on. The particular circumstances that can lead to some petSD+ installations exhibiting this behavior are not well understood so finding a resolution is proving to be difficult.

What makes this even more difficult to understand is that the boot failures can appear very random; the system might boot successfully many times in a row, then have one or two, or even more, failures for no apparent reason, but the majority of devices have no issues at all.

 

Symptoms

The normal petSD+ startup sequence is described on this page, but on affected devices, on some occasions, powering up petSD+ with valid firmware loaded in the MCU and no firmware binary file in the root directory of the SD card (the usual case), petSD+ appears to stall when trying to start the application program. The Red (Error) LED flashes On then Off and the Green (Busy) LED comes on and stays On. The LCD fails to initialise which is indicated by two horizontal lines of solid block characters on the display.

In some cases, a simple reset of petSD+ is enough to get petSD+ to startup, in other cases, a slightly more complex reset procedure is required - see below.

 

What's Going Wrong?

That's a very good question and unfortunately, one for which I do not have a ready answer !

Based on conversation with Nils, it appears that the application is failing to get past the SD card initialisation routine (at this point, the LCD has not been initialised either so just displays those two lines of block characters). The boot-loader appears to be working as the LEDs change status as expected and replacement firmware can be flashed to the MCU if a firmware binary is present on the SD card.

I think that the application must be failing very early in the NODISKEMU code but additional diagnostic messages would help determine exactly what is failing. I am hopeful that Nils can include such additional status messages in the firmware but unfortunately, there is no timeframe for this.

What could be causing the error? Again, I really have no idea, but my "best guess" is that there is some subtle timing problem that is present on some petSD+ units, but not on others. Perhaps there is some component tolerance issue somewhere and most units operate happily, but where a component just happens to get close to the limit, the error occurs. Could it be slight variations in capacitance? Perhaps there a power supply variations (voltage / "noise")?

 

Update 8th July 2019

I am now convinced that the problem is a firmware issue. I did extensive regression testing with an MCU that exhibits the start-up problem and found that the issue appears to have been introduced with firmware version 2017-11-22. When the MCU is loaded with firmware revisions prior to this date, petSD+ starts up without issue on power on. Starting with the 2017-11-22 version and using a "suspect" MCU,  petSD+ does not start up properly without using the work-around described below. This behavior is repeatable, swapping firmware versions before and after this date gives consistent results.

Unfortunately, Nils has just advised me that he will not be devoting any more time to petSD+/NODISKEMU, therefore, there will not be a permanent fix for this issue. See here for details. I can only apologise for this situation, but I do not have the skills to be able to debug and modify the petSD+ firmware myself.

 

Possible Work-Around (Thanks to Andre Stauffer and Chuck Hutchins for providing feedback)

When petSD+ fails to boot, with no firmware binary file on the SD card, the boot-loader quickly scans the root directory, and not finding a firmware file, it immediately moves on to trying to start the application firmware loaded in the MCU. If, for some reason, the SD card does not initialise properly, the firmware appears to stall at this point, hitting Reset once or twice does not change anything and the application continues to fail to load - though sometimes powering Off/On is enough to get things running normally.

However, if a binary file is present on the SD card, even if it is the same version as the one currently loaded to the MCU, things are different. The boot-loader takes a little longer to check the SD card. In this case, as well as reading the SD card directory to find a firmware file, it must also open the file to be able to compare its contents with the firmware loaded in the memory of the MCU. It appears that the time taken to do this allows a slightly longer window in which the user can reset the MCU, probably at a different point in the code's execution. For this to work, the user more than likely needs to do a "double reset", i.e., when the Red LED is on, hit Reset again.

If using an external PSU, the order of powering up the equipment can also be significant - though it shouldn't be! Andre observed that when using an external PSU he needed to power up the PET first, then turn on the external PSU 1-2 seconds later. More puzzlingly, Andre also observed that without the IEEE-488 cable connected at both ends, petSD+ would not start up properly. Again, there is no known reason why this should be the case but it could be related to the Interface Clear signal (?).

If you are having problems with petSD+ starting up and you have previously followed the Troubleshooting Tips, please try this procedure :-

• Put a copy of the petSD+ binary file in the root directory of the SD card

• Insert the SD card

• Ensure the data cable is connected at both ends

• If powering petSD+ externally, turn it on first

• Power on the PET

• Reset petSD+ once

• Quickly reset petSD+ again when the Red LED is illuminated

Please let me know if you are experiencing this problem and whether the procedure above works for you.

 

Normal Startup The video shows a normal startup when the PET powering petSD+ is turned on. You can see the power LED come on immediately and a short while later, you can hear the PET startup "chirp" in the background. The Red and Green LEDs come on immediately as the boot-loader starts to run. The SD card is checked, no new firmware is found, so the boot-loader exists and the application code is started. The "Busy" (green) LED goes off, the "Error" (red) LED goes off, the "Busy" LED goes on and the display starts to initialise, shown by the two lines (1 and 3) of solid characters. The "Busy" LED goes out and the display shows the NODISKEMU boot screen. A few seconds later, the display reports the petSD+ device ID and operating mode, in this case, IEEE(-488).		Click image to Play Video
Missing / Bad Application Program This video shows petSD+ being powered up when the MCU contains a valid boot-loader but no application program is available, either in the MCU itself or available for loading from the SD card. The "Error" and "Busy" LEDs are initially turned on and then the "Error" LED starts to flash to indicate bad/missing NODISKEMU firmware. The "Busy" LED flashes as the boot-loader tries to access the (in this case, missing) SD card. The cycle repeats as the system retries to read the SD card. Note: if the boot-loader was not present in the MCU, both the "Error" and "Busy" LEDs would remain off, the LEDs are controlled by the boot-loader and/or application firmware, with neither are available, the LEDs are not enabled.		Click image to Play Video