Reprogram via memory stick

I am using the cobra board…I’d like to be able to email the latest software file and have the user put it on a memory stick. Then just plug it into the cobra & have it automatically update the program. Is this possible? Are there any examples of doing this? Not sure what I am looking for, exactly.
They only have the board, no Visual studio.

See in field update in library references. A good example is pyxis OS from skewworks.

This looks pretty interesting…it appears the examples just need modified to use a file from an memory stick, rather than from an SD card.
Is there any built-in error checking, such that if the fille is corrupt, it will not update (with an invalid file).?

It is up to you to do security and checking.

There’s lots you could do. Like an XML file w checksum. Put it a version check, etc. if you want to email me about it feel free. Thom @ my username .com

I assume that this does not affect (too much) still being able to also download programs normally using visual studio.
Would you have to do anyhting special when using visual studio?

Nope you can still deploy w F5 and debug except now you’ll have 2 project areas. Bootloader and app.

Is it required to push a switch to do the software upgrade (since there is no access to any switches)? I was thinking, just put in the memstick & look for a particular filename. If it is present, then program it in via bootloader… Could this be done when the normal app is already running, or should it be done only at powerup?

Are there any other “gotchas” using the stick for this approach?

Having 2 regions maybe dropped in 4 2 with some rework planned for IFU. Just to keep you in the loop

@ Gus I was wondering of youd use the ms version or not since truer docs say it will be optional in the PK.

@ Hoyt no buttons required. Everything is done in software. Take a look at the examples.

Are there any complete examples that use a memory stick rather than an SD card? I only want to update the application…so far the steps seem just a bit confusing, I’m rereading the GHI API for the xth time.

Pyxis 2 has complete code to update from either media.

@ skewworks

I downloaded the Pyix 2 updater, got it compiled with no errors & downloaded in to my board…it immeduately gave an error at :

 if (SystemUpdate.GetMode() != SystemUpdate.SystemUpdateMode.Bootloader) throw new Exception("Invalid mode!");

I’m now assuming perhaps I need my own (prior) program to first set the bootloader mode before downloading & executing this program? Perhaps a brief expalnation of the steps would go a long way. I don’t want to “brick” my board right off the bat.

also, what is “Boot Loader Mode DEMANDED” & “Application Mode DEMANDED”…it appears it is triggered by a file presence, perhaps to override an install mode.

I made a single line program:

 SystemUpdate.EnableBootloader();

downloaded it, then tried loading ths program, but still got the exception mentioned

later I added SystemUpdate.AccessBootloader(); & reran the program & it went in & read my memory stick & put my new program in place! Then it went & ran my new program & this loader was toast (gone).

I need to find a way so all of this happens within my own app & I’m not manually loading various programs & modes to accomplished the download…but this is some progress.

You’re not going to brick your board so don’t worry about that. The DEMANDED lines were set up by me as a way to manually force modes without recompiling the program. If a certain file exists it forces to program into one mode or the other and sends a debug line to let you know.

The error you got was because you were running the boot loader program in the application space. If you call enable bootloader and then ran it you would not get the error. Same goes for running the regular application in bootloader mode. It’s just a failsafe to make sure you don’t accidentally upload into the wrong area as one has much more space available than the other.

[quote]Same goes for running the regular application in bootloader mode. It’s just a failsafe to make sure you don’t accidentally upload into the wrong area as one has much more space available than the other.
[/quote]

So if my app is rather large & running, can it monitor for the hex file & download it? Is the boot loader still present in its own space & then activated by the main app ?The procedure is still not 100% clear in my mind. Right now I’m just manually loading & running them & the main app does not do any monitoring or loading.

Here’s the structure for Pyxis 2, hopefully it will clear things up a bit.

  1. The EEPROM is separated into 2 regions Application & Bootloader, this is done automatically when you enable bootloader for the first time.

  2. Pyxis 2 is loaded into application space. When it starts the first thing it does is check the status of SystemUpdates. If it’s not enabled, Pyxis 2 enables it (thus splitting the space into 2 regions). If it is enabled I then check what mode the device is running in. If it’s running in bootloader mode Pyxis 2 throws an exception so you know you’re running in the wrong space, otherwise it proceeds as normal.

  3. Calls are made at regulars (once at startup and then every x minutes if set) to the Skewworks website to check the latest build date of Pyxis 2. If the site has a newer version it is downloaded to the primary drive. Which in Pyxis 2’s case can be either SD or USB. It also check what files need updating. For example Pyxis 2 could update just itself or it could update the Application, Bootloader AND Firmware.

  4. Once all required files are downloaded Pyxis 2 makes a call to switch to bootloader mode.

  5. The bootloader now scans available drives and seeks out the update files. It check which files are present to know which update is needed Application or Complete.

  6. The necessary updates are made and bootloader returns to application space.

Return to step 1.

Thanks for the detailed information - very interesting!

@ mhectorgato - No problem, hope it helps! If you or Hoyt have any more questions just let me know.

[quote]1) The EEPROM is separated into 2 regions Application & Bootloader, this is done automatically when you enable bootloader for the first time.

[/quote]

So lets say you have a FRESH board & want only auto app updates (NOTthe core netmf/GHIsoftware )–I added a few more details/questions

  1. Deploy & run a bootloader program (via Visual studio) that splits the space into 2 regions…does the bootloader automatically then reside in the split (bootloader) space, or does it need reloaded later?
  2. Manually load the app that also monitors for a stick & app file. Upon power up the app runs (in app space) normally, but on the alert for an update file.
  3. If the app sees the stick/update file it switches to bootloader mode & (somehow??? not sure how) initiates the bootloader program(which was previouslymanually installed in step 1 & waiting to run.
  4. Bootloader program (initiated by app) takes over & transfers the new app from stick into app space
  5. Bootloader gives up system & returns to app space , thereby running the new app.
  6. Like the old app, the new app monitors for new stick software update files, if found go to step 3

is this a sensible sequence?

Is this the proper sequence? Should the bootloader be doing the download?..in your description it says the app (pyxis does the download…but that appears to be getting the files from a remorte location (not needed here).