Warm Reboot

mirror

Is it possible to do a "warm" reboot?

What I'd like is a reboot that doesn't re-read the EEPROM, but does do everything else associated with a reboot.

Paul Baker

It's possible but not trivial, you would have to kill all cogs except the first and start it up with the first routine of the top object. This wouldn't be a true warm start, for that you would have to re-zero all variables as well.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

hippy

@ mirror : I had a similar problem - needed to soft-reset whenever a button push was detected. This was easy enough to test for as the program is just a tight loop, but getting the soft-reset looked hard.

I ended up using 'abort' to drop out of the deepest level methods right back down to a simple first public method which restarts everything again. Variables have to be re-intialised and some Cogs may need killing off ( running or not flags are persistent across soft-resets ) but this may be a quick and dirty solution ...

PUB MainProgramEntryPoint

  repeat 
    \MainProgram  ' Uses abort trap

PRI MainProgram

  Initialise
  repeat
    Whatever

PRI Whatever

  if ina[noparse][[/noparse]pin]
    abort

  ' Rest of Whatever code

Ken Peterson

I'm working on a similar problem. However, I want to re-load the hub RAM with a different program and then reset. If I do a cold boot, it always copies from the PC or the first 32K of the EEPROM and that's not what I want. I want to copy a different area, such as the second half of a 64K EEPROM or external memory, to hub RAM and then cause the chip to do whatever it does after copying from EEPROM on a cold boot. Anybody know how this can be done?

[noparse][[/noparse]edit]
I have an idea for doing something similar in hardware by putting two EEPROMS on the bus and having them addressed with a D Flip-flop. Then the Propeller would change the state of the flip-flop and then reboot. I would prefer to do this without added hardware if I can, using the 64K address space on the demo board to hold two programs.
[noparse][[/noparse]/edit]

Thanks!
Ken

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


The more I know, the more I know I don't know.· Is this what they call Wisdom?

Post Edited (Ken Peterson) : 9/25/2007 4:37:34 PM GMT

Mike Green

Ken,
You could do what you described with two EEPROMs. The Hydra does something similar when you plug a memory expansion card in.
The only way you could handle two programs without using two EEPROMs and extra hardware would be to use an EEPROM loader like the one in FemtoBasic (sdspiFemto.spin). This object is designed to be incorporated into other programs as well as FemtoBasic. The loader also will stop any cogs still running before it loads and starts the new program. You just need to call BootEEPROM passing the address in EEPROM of the program to be loaded (see the comments). You can copy the 2nd program to the upper part of the EEPROM by loading it into the 1st 32K of the EEPROM with the Propeller Tool, then downloading FemtoBasic to RAM and using the COPY command (see the FemtoBasic documentation).

hippy

@ Ken : Once you have a assembler program running in Cog 1 it is able to stop Cog 0 ( the original Spin interpreter ) and overwrite the entire Hub Memory without affecting its own operation. An entirely new program from the top 32K could be loaded to hub which in the process would set all the stack pointers and variable initialisations as if it were a re-boot from the top 32K.

Getting Cog 0 running again using the newly uploaded program with its stack pointers initialised correctly is what I do not know how to do.

Mike Green

hippy,
Take a look at sdspiFemto.spin from FemtoBasic. Once it loads the HUB memory from EEPROM, it starts up a new Spin interpreter just as if the HUB were loaded by the boot loader. The routine is "nowBootSpin" near the end of the source file.

hippy

@ Mike : Many thanks. I'm starting to draw together all this somewhat esoteric information together and it's beginning to all make sense.

There are quite a few gems hidden inside project and example code, the trick seems to be in finding them.

Ken Peterson

@Mike: I have read quite a few posts about FemtoBasic and I guess I didn't look into it in more depth because I thought "why would I want to use BASIC if I have SPIN?". Am I interpreting the intent of FemtoBasic incorrectly?

I'll definitely look into sdspiFemto.spin to see if it solves my problem. Thanks!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


The more I know, the more I know I don't know.· Is this what they call Wisdom?

mirror

hippy said...
@ Ken : Once you have a assembler program running in Cog 1 it is able to stop Cog 0 ( the original Spin interpreter ) and overwrite the entire Hub Memory without affecting its own operation. An entirely new program from the top 32K could be loaded to hub which in the process would set all the stack pointers and variable initialisations as if it were a re-boot from the top 32K.

Getting Cog 0 running again using the newly uploaded program with its stack pointers initialised correctly is what I do not know how to do.

Getting Cog 0 running again·is the bit where I'm a bit stuck aswell.

Basically I don't want to start the same code again, but different code. I don't have the pins to do hardware switching, but have a 1GByte SD card (so that means 32000·code images could be stored in the SD card). Practically I only want to store a couple of images in the SD card. What this allows is a bootloader in EEPROM, which is able to program and then use·images stored in SD.

The bootloader could check the image in the SD before running it, as the SD image(s) may have been updated using a remote connection.

·

Paul Baker

http://forums.parallax.com/showthread.php?p=643397

I used the routines from femptoBasic to do precisely this, it would fetch DEMOX.BIN from the card where X was A,B,C,... and changed on the fly according to the particular demo selected by the used. As long as the card is inserted and loaded with the appropriate files it works beautifully.

I placed the bootloader in the EEPROM so pressing the reset got you back to the kiosk program. I did this so I wouldn't have to go and change every program and insert the bootloading code, but when you create all the programs it is a simple task to insert the bootloader. You will likely want to modify it so you deal with raw sectors, it makes it more difficult to load the SD card, but you wont need to include the FAT layer in every program.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Post Edited (Paul Baker (Parallax)) : 9/25/2007 10:20:11 PM GMT

Mike Green

The sdspiFemto.spin object was specifically designed to be incorporated into all sorts of programs for this kind of purpose. It allows you to read / write / boot files from any I2C EEPROM on any pair of I/O pins or from any SD card on any set of 4 I/O pins. For the EEPROM, it needs the starting address of the data. For the SD card, it needs the starting sector number. There's a separate object with Rokicki's FAT file system routines that can take a file name and return the starting sector number of the file. If the file is preallocated so its sectors are all contiguous, you can read / write / boot without further reference to the FAT file system. You could even write a utility program (on the Propeller or on a PC) that displays the starting sector numbers for all the files on an SD card and incorporate them as constants in your program. This is particularly useful for program images (32K), but could be used for data files as well as long as they're preallocated as contiguous files.· The advantage of doing things this way is that you maintain the FAT file system and the PC will mount the SD card so you can use the Propeller Tool to update the binary EEPROM images as you debug or otherwise modify your programs.

mirror

Thanks Paul, Mike,

This seems to be the info that I'm looking for.

I'm already doing raw access of sectors on SD card, so that bit is easy!