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.

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.