Update Project from SD Card
JonnyMac
Posts: 9,208
I'm sure others have tried this and I hope those that have will offer suggestions and their experience with "gotchas."· While talking with a potential customer last week he asked if we could update the data for the project from the SD card that was already there; "Sure, no problem.· In fact, " I continued, "we could even update the proudct, too."
Well, I thought I should actually test my theory and it turned out to be sound.· Mind you, this is a butt-simple experiement but it was done to prove a point (mostly to myself).· The attached program (setup for a Demo Board) has a method called checkupdate that, 1) attempts to mount the SD card, 2) looks for a file called "update.pgm", 3) checks to see if the file is 32K.· If all that is true then it moves it, 64 bytes at a time, to the boot EEPROM and reboots the Propeller.
In the end, my goal is to allow SD enabled products to be easy to update, even for my tech-nervous customers.· I created two EEPROM images with different LED patterns and have happily gone back and forth between them by copying the desired image to "update.pgm."
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA
Well, I thought I should actually test my theory and it turned out to be sound.· Mind you, this is a butt-simple experiement but it was done to prove a point (mostly to myself).· The attached program (setup for a Demo Board) has a method called checkupdate that, 1) attempts to mount the SD card, 2) looks for a file called "update.pgm", 3) checks to see if the file is 32K.· If all that is true then it moves it, 64 bytes at a time, to the boot EEPROM and reboots the Propeller.
In the end, my goal is to allow SD enabled products to be easy to update, even for my tech-nervous customers.· I created two EEPROM images with different LED patterns and have happily gone back and forth between them by copying the desired image to "update.pgm."
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA
zip
38K
Comments
Alternatively, you could build this whole logic into your program, but copy the 2nd 32K to the 1st 32K if the copy to the 2nd 32K succeeds.
The advantage with this scheme is that the copy from the SD card will not overwrite the 1st 32K in the first case or will only overwrite the 1st 32K if everything checks out. A failure during the SD card I/O will not "brick" the system.
I was originally thinking that based on the filename, it would either re-write the lower 32k, write to the upper 32k, or load directly from the card. If nothing was found, it would load the upper 32k.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Forums RSS Feed!
Gadget Gangster - Share your Electronic Projects
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
The extra costs are not to much and you can even put one EEPROM on top of the other in case you don't have the PCB estate.
Have you got some more info on how to find this object?
The OBEX is a great concept, but trying to find things there is like pulling teeth!
It took another 20 mins but I eventually found it ....
obex.parallax.com/objects/473/
Nick, this is exactly what you are looking for, at least according to the writeup on the OBEX.
cheers ... BBR
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cheers ... brian riley, n1bq, underhill center, vermont
The Shoppe at Wulfden
www.wulfden.org/TheShoppe/
www.wulfden.org/TheShoppe/prop/ - Propeller Products
www.wulfden.org/TheShoppe/k107/ - Serial LCD Display Gear
Post Edited (Brian Riley) : 5/6/2010 8:36:38 PM GMT
I downloaded three fresh copies of three SD based loaders
1 - jonnymac's - loads in EEPROM, runs and replaces itself with a program update from SD card. I am not sure what the point is (no offense jon), since te UPDATE.PGM overwrites the re-loader code in low EEPROM. But the code is very clean and all aspects work as advertised, right down to erasing the update file at the end. The i2c and spi code is fresh and clean.
2 - Nick's barebones loader with stays in low EEPROM, looks for and loads a file called RUN.BIN to RAM and it runs.
3 - Matthew Cornelisse's Bootloader 1.01 (OBEX #473), which does load a file called CODE.BIN to high EEPROM from SD, but then fails to erase the file and fails to execute the program in high EEPROM, remove the sd card and punch reset and it loads and runs the program in High EEPROM.
Very confusing ... Matt and Nicks code are similar but contain, as far as I can see subtly different versions of mike green's FEMTO code for I2C/SPI/SD. Jon's code is lots newer seemingly with advantages of all that time since Mike's work to get it all right. I particularly like Jon's approach to I2C because he explicitly passes the EEPROM ID ($A0) and start address ($0000 or $8000). If I use an SD add-on card with my Prop Platform, I could load the second EEPROM (ID is $A2) and have my choice. Mike's code buries the $A0 down deep but, alas, Jon's code doesn't have the bootEEPROM and bootSDcard routines that Mike's has.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cheers ... brian riley, n1bq, underhill center, vermont
The Shoppe at Wulfden
www.wulfden.org/TheShoppe/
www.wulfden.org/TheShoppe/prop/ - Propeller Products
www.wulfden.org/TheShoppe/k107/ - Serial LCD Display Gear
Post Edited (Brian Riley) : 5/7/2010 4:37:12 AM GMT
Unlike many others, I do not default to the ObEx; I tend to enjoy the experience of doing something for myself and writing code. It's tragic that some (not you, Brian) take the attitude, "It's already been done, why did you bother?" Why? Mount Everest has been climbed many times but others continue to do it for the challenge and the experience. Programming is fun; I like doing it -- even if the code I'm writing is not particularly unique. If it's new to me then that is good enough and I'm sure I'm better off in the end. If others are helped by my efforts, great; if not, no harm was done by me (or others) sharing.
The Propeller, and ObEx in particular, tragically, has encouraged a new level of laziness among some (mostly young and new) programmers who's default position is, "Where is the object to do this?..." (This is not unique to programmers; PJMonty told me yesterday it happens in the visual effects business all the time with new artists asking "Where's the plug-in?"). Even where objects exist I tend to go my own way when said target is within (or just beyond) my present comfort zone and abilities -- again, I enjoy the opportunity to learn.
I, for one, think objects should be small (as small as possible), discrete, specific, and flexible; hence my I2C object just provides I2C communications routines, but doesn't limit them to a single device address.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA
Post Edited (JonnyMac) : 5/7/2010 2:59:16 PM GMT
Slick application! It will save me from "recreating the wheel" in my current project, allowing me to spend my limited
propeller time creating other neat ideas and code. [noparse];)[/noparse]
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Are you Propeller Powered? PropellerPowered.com
Visit the: PROPELLERPOWERED SIG forum kindly hosted by Savage Circuits.
Thanks! Now... per my rant (grin) above, I think it's quite okay -- when one does have the time -- to reinvent wheels; this process often leads to better wheels (note to others: I'm not suggesting the above code is better than what other have done, it's just another offering).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA
D'oh! Boy did I miss that ..... I retract my don't see it with a few mea culpas ... makes perfect sense now
No apologies or qualifiers needed ... it works perfectly and the code is crafted nicely that it could be extended.
cheers ... BBR
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cheers ... brian riley, n1bq, underhill center, vermont
The Shoppe at Wulfden
www.wulfden.org/TheShoppe/
www.wulfden.org/TheShoppe/prop/ - Propeller Products
www.wulfden.org/TheShoppe/k107/ - Serial LCD Display Gear
This obj is cool (tried it) & easy for a rookie like me to understand. And, exactly what I was looking for (end-user update of new code)!
Thanks.
It works like this, in this priority order,
1 - inserting an SD/uSD card and assuming a 64K EEPROM - *
2 - looks for a file called RUN.PGM, if found it loads to RAM from SD card and runs - ***
3 - looks for a file called UPDATE.LDR, if found it loads from SD card into low EEPROM (lower 32K), then erases UPDATE.LDR from SD card - **
4 - looks for a file called UPDATE.PGM, if found it loads from SD card into high EEPROM (upper 32K), then erases UPDATE.PGM from SD card - **
5 - loads high EEPROM to RAM and runs
* - no SD card present - skips to step 5
** - if a file named NODELETE.TXT is on the SD card, the deletes do not get made
*** - this code doesn't work right yet, see below
if sd.popen(@RunNow, "r") == 0 sdspi.bootSDCard(sd.get_datablock, sd.get_filesize <# $8000)This code hangs in bootSDCard not sure why!
I added the two sd.get_ routines as PUBs in fsrw.spin to get at the private data. This code works in Nick's routine.
MMMMiiiiikkkeeeee!!!!!! Help! Please!
cheeers ... BBR
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cheers ... brian riley, n1bq, underhill center, vermont
The Shoppe at Wulfden
www.wulfden.org/TheShoppe/
www.wulfden.org/TheShoppe/prop/ - Propeller Products
www.wulfden.org/TheShoppe/k107/ - Serial LCD Display Gear
Using bootSDCard runs into the same problem, but it's more involved. sdspiFemto and sdspiqasm both start up a separate cog and both cogs will try to access the SD card using the same I/O pins. You have to stop sdspiqasm before calling bootSDCard, then you have to call initSDCard and provide the pin numbers for the SD card.
You might be better off using fsrwFemto along with sdspiFemto instead of using fsrw and sdspiqasm. You could even use the read / write routines for EEPROM that are part of sdspiFemto instead of the Basic_I2C_Driver routines. They're faster.
You might look at FemtoBasic since that includes routines that do much of what you want. In particular, the COPY statement can be used to copy a binary program from an SD card file to a 32K block of EEPROM. You might look at that routine in FemtoBasic.spin, lines 1087 through 1111.
You might also look at the SPIN statement in FemtoBasic.spin, lines 1068 through 1078. This executes a program either in an SD card file or a 32K block of EEPROM.
Post Edited (Mike Green) : 5/9/2010 3:41:09 AM GMT
But bootEEPROM works just fine in that code . I also do not understand why they would be going after 30/31 the eEPROM is on 28/29
Here is my problem. There's a number of minor variations and NOWHERE is there a roadmap! I used what I had because my baseline code was Matt's Obex #473 and that is what he used. But I was implementing ideas from Nick (he used your suggested scheme) and Jon (he used fsrw 2.6 and some other new code ... besides Jon cheated
Could you take a few words and differentiate the various pathes through the I2C/SPI/SD/EEPROM minefields.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cheers ... brian riley, n1bq, underhill center, vermont
The Shoppe at Wulfden
www.wulfden.org/TheShoppe/
www.wulfden.org/TheShoppe/prop/ - Propeller Products
www.wulfden.org/TheShoppe/k107/ - Serial LCD Display Gear
Attach is a recoded version of your loader using fsrwFemto and sdspiFemto and the routine from the COPY statement. It compiles, but I haven't tested it yet.
Thanks Mike, those two paragraphs have given me enough info to approach restructuring my code to use fsrwFemto and sdspiFemto with some confidence.
I would still be interested in a short tutorial on what is which in the fsrw/sdspi/i2c world.
cheers ... BBR
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cheers ... brian riley, n1bq, underhill center, vermont
The Shoppe at Wulfden
www.wulfden.org/TheShoppe/
www.wulfden.org/TheShoppe/prop/ - Propeller Products
www.wulfden.org/TheShoppe/k107/ - Serial LCD Display Gear
First came the I2C routines in the Propeller OS years ago. This was a PASM I2C driver that included an I2C boot loader.
This was extended to include low level SD card SPI routines including an SD card file loader and became sdspiFemto. I modified Rokicki's FSRW routines to work with it and these became fsrwFemto.
Rokicki did some experimenting with faster low level SD card SPI routines which are included with the 1.4 version of FSRW (for FAT16 only). This is sdspiqasm. They're somewhat faster than sdspiFemto, but can't load a file and they don't have the I2C routines.
There's now a 2.6 version of FSRW that can handle FAT32 formatted SD cards. It could be modified to use sdspiFemto, but I haven't done that yet. There are other SD card I/O drivers as well, one by Kye that's still under development that will include FAT32 support, subdirectories, and an SD card file loader. There's another one that's part of Sphinx that's completely in PASM.
Basic_I2C_Driver is a Spin-only I2C driver, mostly for reading and writing to EEPROMs. It has no EEPROM loader.
James Burrows also developed a Spin-only I2C Driver which included support for specific non-EEPROM devices. He originally had his own low level I2C driver, but later used the routines from Basic_I2C_Driver. Similarly, the BS2_Functions package now uses the low level I2C routines from Basic_I2C_Driver.
Post Edited (Mike Green) : 5/9/2010 3:14:54 PM GMT
Thanks also for the code work. It looks more or less like what I envisioned when I looked at the references you gave me. I will test it tomorrow when I am awake enough not to make stupid mistakes.
Quick question (probably requiring not so quick answer) Why are some method calls prefixed with "\" and others not yet all have "abort' specifications?
Second quick question, the texts in the abort specifications where do they get dumped ... to a P30/P31 to a serial terminal?
cheers ... BBR
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cheers ... brian riley, n1bq, underhill center, vermont
The Shoppe at Wulfden
www.wulfden.org/TheShoppe/
www.wulfden.org/TheShoppe/prop/ - Propeller Products
www.wulfden.org/TheShoppe/k107/ - Serial LCD Display Gear
2) I copied and modified the code in FemtoBasic. The ABORT STRING "... stuff ..." causes the address of the string to be passed back where it's used as part of an error message to the user. fsrwFemto also uses this for one or two of its errors.
I am going to start a new thread with the source code etc.
http://forums.parallax.com/showthread.php?p=905248
cheers BBR
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cheers ... brian riley, n1bq, underhill center, vermont
The Shoppe at Wulfden
www.wulfden.org/TheShoppe/
www.wulfden.org/TheShoppe/prop/ - Propeller Products
www.wulfden.org/TheShoppe/k107/ - Serial LCD Display Gear
Post Edited (Brian Riley) : 5/9/2010 7:58:18 PM GMT
I'm looking at the portion on writing to the eeprom:
check := i2c.putpagex($A0, addr, PG_SIZE, @buf)
if (check == i2c#NAK)
term.str(string(" -- EE write error", CR))
quit
If there is really a problem while writing half-way, will it cause the eeprom to be unuseable/unbootable?
Yes, it could, unless the write failure happens past the actual working portion of the code. Remember, this was a test program, not meant for actual deployment as-is. In my case I have a bi-color LED that keeps the user informed (flashing yellow = programming, solid green = success, red = failure). I've run that program many times now without problems and I don't expect to have them in field -- I just tend to be a conservative programming (well, mostly) and attempt to trap possible error conditions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA
Did you add the LED for the status, because that sounds really handy..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I always have someone watching my back.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA
Thank you. Yes, I'm thinking along that line as well. I've tried your code a number of times, no problem. For the current project I'm working on, I'll probably need to add in some tolerance as power failure could be a norm in the field where they are going to be deployed. I have battery added but just wanted to be extra safe. So, I'm thinking of adding a separate eeprom for running the active project (prone to changes) & the main eeprom for running the checkupdate plus other comm from senors & update back to server but I don't know how to launch code in another eeprom. Sorry if this had been answered before but if you could direct me where to look, it be appreciated.
Thanks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA