?? Binaries for "broken SD card hardware" ??

Skip to first unread message

Dan Newman

Feb 10, 2013, 12:24:01 PM2/10/13
to jetty-f...@googlegroups.com

In case anyone's curious about the .hex files I put up in the beta area
for "broken SD card hardware", here's the background info.

There's a SD Card Detect switch which can be used to detect whether or
not a card is inserted into the SD card slot. The switch is HIGH when
no card is inserted and LOW when one is. These switches, when they break,
tend to always read HIGH.

In the stock MBI firmware, most SD card operations start from scratch
with the SD card: re-initializing the SD card library and resetting the
current directory to the top ("root") directory on the FAT file system.
Only if there is a problem while re-initializing, does the stock firmware
then check to see if the SD card is present. So, the operation of that
Card Detect switch is only important when there is already a problem with
the SD card.

Why does the stock firmware do that? It's one way of dealing with
the user having had removed the SD card and inserted a new one without
the firmware knowing or worrying about it. The SD card library is very
bare bones with minimal error detection code. If you have it work with
incorrect file system information, the library can and will go off into
infinite loops. (I found that out the hard way.) So, always
reinitializing the library is one way of dealing with this.

In the new Sailfish firmware with folder support, it's not practical
to reinitialize the SD card library all the time -- that loses the
current directory state. That could be saved but consumes RAM and
puts a limit on depth of descent. (65 bytes for each level of descent
but there's not a lot of free RAM to begin with. Writing the info to a
temp file on the SD card then doesn't work with read-only SD cards.)
So, the new firmware watches the Card Detect switch pro-actively. If
the switch is broken and always reads HIGH then the firmware, which is
checking that in advance of errors, will think there's no card and
report an "No Card" error to the user. And, it won't attempt to access
the card, even if it is inserted. Consequently, on those bots with a
broken Card Detect switch, you cannot use the SD card with the Sailfish

Thus, this extra hex file for each bot: it's incase any users suddenly
have their SD card hardware go bad. They can load up this alternate
binary and still be in business, albeit without the benefit of folder
support. I felt it prudent to provide such binaries up front since there
are commercial users of Sailfish. If any of them have this forseeable
issue, then the workaround is immediately available. Yes, I could
have coded this up as an ON/OFF setting in the firmware and have it be
selectable via an EEPROM setting. However, I prefer to avoid adding
such code complexity for what is really just a workaround to malfunctioning
hardware which should be replaced. And, for all I know, no one will
have this problem. (Well, I have -- twice now on my Rep 2.)


Reply all
Reply to author
0 new messages