Shop OBEX P1 Docs P2 Docs Learn Events
Remote programming — Parallax Forums

Remote programming

VonSzarvasVonSzarvas Posts: 3,522
edited 2010-03-13 23:59 in Propeller 1
I would like to ask a theoretical question....

Can the Propeller be remotely programmed, perhaps over a radio connection (that has no in-built error checking - bluetooth/bee/vhf - doesn't matter really).

My idea:

Prop has two 64KB EEPROM (SMT) - Parallax item code: 602-10001.

EEprom One is connected as that from which the Propeller downloads its program at startup. (Normal setup).

EEprom Two is connected to a spare IO pair. The program running in the Propeller will be able to receive a new program by radio connection and
store this long-by-long into the second EEprom. At the end of the "download", a checksum arrives. If this is OK, then the Propeller copies the new program from EEprom Two (long-by-long) to EEprom One (ie. the main program EEprom) and then resets itself to load the new program.

If the checksum is bad, then we discard the attempt and continue with the existing working program - perhaps signalling the mothership to try again.

--

So is this possible? What I don't yet understand is the format of the stored program in EEprom One, and whether the Propeller can write to that itself whilst it is running without causing it to hang (I hope this will work as the Propeller runs from a copy of the program in Hub RAM?).

If this is theoretically possible, then this will be my second experiment after flashing a few leds!

Thanks again,
Max.

Comments

  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2010-03-10 21:00
    There's no need to use two EEPROMs. The program can be loaded into RAM first and checked there, then stored in EEPROM if there are no errors. For full-length user programs, though, you will need a 64KB EEPROM, in order to accommodate a small bootloader.

    -Phil
  • MagIO2MagIO2 Posts: 2,243
    edited 2010-03-10 21:07
    He want's the current program to continue, so he can't load into RAM - if I got that right.

    I think the problem is that the propeller tool won't work for this approach. Because EEPROM writes cause delays but the propeller tool does not allow these delays. So, you have to write your own 'programmer'.
  • VonSzarvasVonSzarvas Posts: 3,522
    edited 2010-03-10 21:20
    Phil: ... Unless my RAM is full with the program it is running?

    MagIO2: Yes, I would like the current program to continue.

    More simply, after a trigger pin goes high to signal "update program", the Propeller should serin long-by-long the new program, storing it to EEprom Two. (Or the second half of EEprom One if the program is less than 32KB, I guess)

    After checksum, copy program to EEprom One, then reset.

    There might be a more efficient way of doing it - my aim is to find out if it is possible in theory (ie. NOT using the Propeller Tool can the Prop write to its own program EEprom?)
    And also to ensure if the program arrives corrupted (serin failure), then the currently running program keeps on going.
  • MagIO2MagIO2 Posts: 2,243
    edited 2010-03-10 21:31
    Any propeller program having the I2C driver can write to any location of the EEPROM. So, yes you can overwrite the program code in the EEPROM.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2010-03-10 21:32
    I guess I was thinking that, by "continue", you meant that you could reboot the original program from EEPROM if the upload had errors. So, as long as the bootloader were running from it's own cog memory, it wouldn't matter if hub RAM got clobbered.

    -Phil
  • VonSzarvasVonSzarvas Posts: 3,522
    edited 2010-03-10 21:45
    MagIO2, you have answered my question exactly as I meant to ask it. I am going to try it out!

    What Phil wrote wasn't quite what I had in mind, but it does make me step back and re-consider if I can just pause the program before an update (thus simply using RAM as the buffer), and save a second EEprom and all the extra time moving bytes about. In some situations that might be a perfectly acceptable solution - and simpler too.

    I remember why I liked the Parallax forum so much - you always get quality opinions coming in from all angles to keep you on your toes!

    smile.gif
  • dMajodMajo Posts: 855
    edited 2010-03-13 17:00
    Maxwin, you can do every thing, but what you have described is not fault tollerant. You have taken into account only the radio errors, what happens if you loose power during the copy from one eeprom to the other? (the source is not the boot one, and the destination (the boot) will be corrupted: device unusable)

    There are 2 solutions (fault tollerant):
    1) a eeprom up to 128 KB where in the 1st 32KB there is the bootloader that will boot from one of the upper three 32KB images
    2) several 32KB eeproms on the same I2C bus with different dynamic addresses controlled by a [url=http://www.nxp.com/#/pip/pip=[pip=PCA9561_3]|pp=[t=pip,i=PCA9561_3]]PCA9561[/url] (or similar) connected to the same I2C bus. With this configuration the bootloader is not needed and the PropTool is able to program all the eeproms through a serial connection. The radio download will be handled through software.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    · Propeller Object Exchange (last Publications / Updates);·· Vaati's custom search
  • VonSzarvasVonSzarvas Posts: 3,522
    edited 2010-03-13 20:38
    dMajo: Thank you- that is a VERY important point

    I like suggestion 1 - simple and elegant.

    If I understand correctly... after a valid upload of a new program, we simply set a persistent flag/value in the Prop (or else some external device with a few bytes persistent memory -- perhaps an RTC..) which indicates which main-program to load from the eeprom - or else on a load-failure the bootloader might move round-robin around any other stored program versions until it finds a valid image. A power failure at any stage before the flag setting will mean the old software safely boots.

    I have not learned enough yet to know if:

    a) The Propeller's built-in bootloader can be replaced by a user-custom bootloader (which might save reserving an external 32kb block for a user bootloader)

    or

    b) The Propeller can load an external image (bootloader) which then loads another image to run as the main program.


    I have some hope as your suggestion implies that the Propeller can do at least one of these - which is good news!

    Experimenting will begin as soon as I get hands on... frustrating wait for parts in progress.... mad.gif

    ..
  • Mike GreenMike Green Posts: 23,101
    edited 2010-03-13 20:55
    You can't replace the built-in bootloader, but you can download a "2nd level" bootloader that handles pretty much whatever protocol you want. Look at the documentation for the Propeller Backpack and the YBox2. The Backpack downloads from a Stamp or other similar microcontroller. The YBox2 is a Propeller-based Ethernet server that can download programs to EEPROM over the Internet.

    www.parallax.com/StoreSearchResults/tabid/768/txtSearch/backpack/List/0/SortField/4/ProductID/602/Default.aspx
    www.ladyada.net/make/ybox2/
    www.deepdarc.com/ybox2/
  • dMajodMajo Posts: 855
    edited 2010-03-13 23:59
    maxwin you guess correctly: b is the answer

    the prop always try boot 1st from serial (expecting propeller tool on the other side) and if it fail the first 32kb are copied from external eeprom to internal ram and then executed. In your case this will be a small prog that make again the same thing: copy the 2nd or 3rd 32kb to hub ram and then execute it. The eg. 2nd 32kb block must have the code to handle the firmware upgrade writing the received stream to eg 3rd 32KB and then update in the 1st 32KB the boot pointer: at next reset/powercycle the device will run with new firmware.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    · Propeller Object Exchange (last Publications / Updates);·· Vaati's custom search
Sign In or Register to comment.