Booting .eeprom files from SD cards

Phil Pilgrim (PhiPi)

I wrote a lesson for my students that showed them how to boot their programs from SD card EEPROM image files, rather than uploading them. This is important for the class ROVs, since it makes it easy to swap students' programs in the field without having to have PCs present. So I wrote the following simple loader program:

CON

  _clkmode      = xtal1 + pll16x
  _xinfreq      = 5_000_000

OBJ

  sdc   : "SD-MMC_FATEngine"

PUB start

  \sdc.fatEngineStart(22, 23, 24, 25, -1, -1, -1, -1, -1)
  \sdc.mountPartition(0)
  \sdc.bootPartition(string("myprog.eep"))

and tested it with a simple LED blinky program. It worked as I expected it to, so I wrote it up as a lesson.

Come class time, two kids were able to complete the lesson, but no blinky-blinky. I brought one of their SD cards home to try on my bot and had the same issue. The card that worked for me is a 4GB HC from Kingston; the one that didn't, a 32GB Ultra Plus HC(I) from SanDisk. The kids are able to write to their 32GB SD cards from Spin using SD-MMC_FATEngine. It's just the booting that seems to be an issue.

-Phil

JonnyMac

Phil,

I wrote my own loader for BINARY files. It uses FSRW. You're welcome to it if you think it will be helpful. I went with BINARY images as they're smaller.

The process works well -- I recently deployed it in a customer project that has three distinct behaviors. When they power up the device (laser tag weapon), they can select which option to load by holding a specific button.

Phil Pilgrim (PhiPi)

Thanks, Jon, but I've got too much invested in Kye's object to switch to FSRW.

I deleted all the files on my student's 32GB SD card and copied myprog.eep back to it. Now it works, but I have no idea why or what the difference was.

-Phil

Cluso99

I have used a SanDisk 8GB Ultra successfully with Kye's drivers. I boot from them using the same driver in eeprom.
However, I am not exactly doing what you are doing.

The other thing I found with SD cards is that they don't always release the DO pin. This was a problem for me because I share the DO pin with SRAM so it's probably not your problem. I had to modify the various SD drivers to output some more clocks after deactivating the SD card (ie after CS=1).

My PropOS contains the modified Kye's driver. I split the code in two parts, ready for some other things that I never got around to completing.

Mike Green

I thought SD-MMC_FATEngine correctly dealt with booting a file that is not a contiguous 32K allocation. I know that the boot loader in FemtoBasic requires a contiguous 32K SD card area. The scenario in post #3 suggests this as the problem (attempted boot of a non-contiguous 32K area).

Phil Pilgrim (PhiPi)

Thanks, Mike. That makes sense. I've thought about repartitioning the SD card, so that partition 0 contains only the boot file, with partition 1 containing everything else. But, apparently, Windows will not recognize other partitions on SD cards, so saving waypoints on those partitions and collecting survey data from them may prove difficult.

-Phil

Dave Hein

Mike Green wrote: »

I thought SD-MMC_FATEngine correctly dealt with booting a file that is not a contiguous 32K allocation. I know that the boot loader in FemtoBasic requires a contiguous 32K SD card area. The scenario in post #3 suggests this as the problem (attempted boot of a non-contiguous 32K area).

If that's the problem it can be handled by formatting the SD card with a cluster size of 32K.

Phil Pilgrim (PhiPi)

The SD card in question is already formatted with 32K clusters. (I determined that by saving a 3-character file to it, and noting that it occupies 32K on the SD card.)

-Phil

kuroneko

Just an observation (driver rev 1.9):

BootPartition finally calls readWriteBlock. The latter expects a sector address as its first parameter. Internally it adds the hidden sector count to form the final address.

PRI readWriteBlock(address, command) ' 12 Stack Longs

  CIDPointer := @CIDRegisterCopy
  [color="orange"]cardSectorAddress[/color] := [color="red"](address + hiddenSectors)[/color]
  cardBlockAddress := @dataBlock
  cardCommandFlag := command

  repeat while(cardCommandFlag)

  if(cardErrorFlag~)
    abortError(Disk_IO_Error)

That said, BootPartition misuses said parameter to pass the hub address of the boot image sector chain.

lockFileSystem("R")
    [color="red"]readWriteBlock(@bootSectors, "B")[/color]
  unlockFileSystem

The PASM section extracts it like this:

rdlong  buffer,                sectorPntrAddress            ' [color="orange"]sectorPntrAddress := @cardSectorAddress[/color]

rebootSectorLoadLoop    rdlong  cardRebootSectors,     buffer                       ' Get all addresses of the 64 sectors.
                        add     buffer,                #4                           '
                        add     rebootSectorLoadLoop,  fiveHundredAndTwelve         '
                        djnz    counter,               #rebootSectorLoadLoop        '

This works as long as hiddenSectors is 0. IOW, readWriteBlock(@bootSectors - hiddenSectors, "B") would be my candidate for a fix.

Phil Pilgrim (PhiPi)

Thanks, Marko! I've made the change you suggested, and it didn't make things worse for the card that worked. I'll try it in class today on one of the cards that did not work to see if anything changes.

-Phil