Sending EEPROM image via bluetooth / serial to re-program

Don M

This is a continuation from this thread...[URL] http://forums.parallax.com/showthread.php?129700-Booting-from-secondary-EEPROM-(non-SD-bootloader) [/URL]but thought it warranted it's own thread.

To further expand upon my idea- I would have a main loop running that among other things is monitoring the serial input on a pin. This serial input whether it be by bluetooth or other means, supplies commands that are used by the main program for other purposes. There would be one part of the main loop that looks for a specific command character that invokes the ability to receive an eeprom image file and write it to the eeprom. Once stored there could be a command character sent back via bluetooth / serial to the sending device to indicate that it is finished storing image. The main loop would then go back to doing whatever it needs to do. The remote device could then send another command to cause the Prop to re-boot. The re-booting would then utilize the new eeprom image.

So with this simple overview would it still be necessary to have to have some other boot loader? By the way the remote device would not be using the Prop IDE to send the image file.

So is this possible or is it just a pipe dream? Maybe this has already been done?

Thanks for your help.
Don

Rayman

Using the idea in this thread:
http://forums.parallax.com/showthread.php?136690-quot-Propeller-Eeprom-quot-works-for-upper-32kB-of-64kB-EEPROM-chip

You can easily store the incoming code in the upper 32 kB of a 64 kB Eeprom chip.
That way can make sure it's received properly.

Then, you can move it down to the lower 32 kB and reboot.

Mike Green

As has been described before, you basically have two options:

1) Your receiving program is always stored in the 1st 32K of the 64K EEPROM. When commanded, it writes the received program into the 2nd 32K of the EEPROM as it's received (and verifies it). When given another command, it uses something like the sdspiFemto.spin bootloader to directly boot off the 2nd 32K

2) Your receiving program, when commanded, writes the received program into the 2nd 32K of the EEPROM and verifies it. When given another command, it copies the 2nd 32K of the EEPROM to the 1st 32K, then does a reboot.
Presumably, this new program also contains the code to receive an update.

Don M

@Ray- Thanks I'll have a look.

@Mike- #2 is correct. I don't understand why I'd want to boot off the 2nd half of EEPROM. Can you give me a for instance why? As I understand the Propeller, whatever image is stored in the lower half of the 64K is what it uses for its image upon start up or re-boot without anything extra needed. Am I correct in understanding that?

Thanks.

Unsoundcode

Hi Don, I have done this using a Visual Basic GUI to download an EEPROM image over a hardwired connection but the basics are the same whichever platform you choose for the GUI. It will certainly work over Bluetooth.

At the Prop end I used Mike Greens i2cObject.spin, the main routine I used is the WritePage method and I would write a 32 byte packet each pass through a loop. The i2cObject allows you to select EEPROM chip address, memory address and SCL/SDA pins, so if you wanted to go into the top half of a 64K the option is there.

Also it is not necessary to write to the whole 32K, if you view info in the IDE and look at the spin byte image bytes 9 and 10 contain the size of the binary image, low byte and high byte respectively. Depending on file size this can reduce the download time significantly. For convenience I would always write 32 bytes and pad the final packet with zeros.

If you stay with the standard 32K EEPROM then after download verification you could issue the Prop Reboot instruction to load the new program.

Jeff T.

Mike Green

You'd want to boot from something other than the 1st 32K of the boot EEPROM if you have a control program in the 1st 32K that normally gets control on a reboot then, depending on 'the state of the world', may either boot a program in the 2nd (or other) 32K of the EEPROM or do some other action directly. Remember that you can use a 128K EEPROM too to get 4 x 32K and boot from any of the 32K 'pages'. If your programs are small enough, you can also boot from other than a 32K boundary (at least using sdspiFemto.spin). Back before the Prop could use SD cards, I had an operating system that stored file names in the last 16 bytes of a 32K EEPROM 'page' and you could boot, copy, delete programs files in the EEPROM. You could have 512K of EEPROM on any pair of I/O pins (including 28 and 29 - the default). You could also use a 32K 'page' for data if you were careful about not writing too often.

Cluso99

One advantage of storing your program in the upper 32KB and never overwriting the lower 32KB, is that you can then use the lower 32KB as a master boot. IIRC Mctrivia did something like this and put his code in the obex. If you made the master boot code a little more intelligent, you could check for a pullup on a particular pin (e.g. you could even use the SCL pin on the eeprom). This way, you would (i.e. should) never corrupt the master boot 32KB.

Oldbitcollector (Jeff)

@DonM

Were you ever able to accomplish this?

Jeff