EEPROM write/read a modified program for next reset from asm/spin

Jeffrey Kane

Hello,

I think the answer to this is yes, but just checking, is it possible to create a program in asm/spin and then use i2c to transfer the changed program to the eeprom, so the next boot will be the modified program, which should be sent to theHUB and then the specific COG. if another program is created/then modified, the process repeats. modifiying the HUB and COG memory and instructions seem straight forward.

Thanks in advance.

Jeff

Wuerfel_21

Yes, that is possible. The EEPROM doesn't do anything special after the chip boots. If you just want to load another program, you don't need to write it to EEPROM at all, you just load it into memory and start it (in actuality this is slightly tricky, but certainly doable)

Jeffrey Kane

I wanted the changes to be permanent, so over time the program changes permanently. (unless you load the original program from the ide)
Jeff

Phil Pilgrim (PhiPi)

Can I assume you just want to change the values of certain variables in DAT and not the code itself? If that's the case, it should be easy.

-Phil

Jeffrey Kane

code also, I looked at the HUB in hex, mapped them back to the instructions, then I saved the eeprom, and looked at in hex, it matches the HUB instructions, except for the first 10 bytes (ish) eventually i probably would need to know how to set those bytes if they related to the program that is loaded.

msrobots

exacly, basically the HUB has the same adresses then the EEPROM so if you have a DAT Variable named mySetting you can overwrite in the EEPROM the Hub Address @mySetting the addresses are the same.

Next boot you have the new value in your DAT section in mySetting.

So you do not need to write the whole program into the EEPROM again, just change the existing one.

The first 10 Bytes are different, they get set after load with clock frequence and clockmode and some other stuff i not remember.

The EEPROM FILE has a checksum getting checked on programming, but not while booting, so you can change the content of the EEPROM and ignore the checksum

Enjoy!

Mike

Phil Pilgrim (PhiPi)

What kinds of instructions are you replacing? Spin bytecodes or PASM? Are you sure you can't do it parametrically, using a variable to select a path through various branches of your code? Actually replacing the code itself seems rather brutish to me.

-Phil

Jeffrey Kane

I'll probably stick with asm, not positive, this is a picture of the memories (and the source code), I guess I use I2c on pins 28 and 29 to address the eeprom memory, I see there are opcodes for read/write from the HUB, RDLONG, WRLONG and in the cog uses movi, movs and movd, makes sense, and I noticed that the initialization is in both the HUB and the EEPROM, so I don't have to worry about creating additional code.

I'm make a test soon to validate what should work, does work. Thanks for answering my questions, I included an example with the memories, I'm just using dither1 as a test file for now.
if you happen to have the layout for the initialization string, that would be handy. but if it only has to do with frequency and I stick with the same, hopefully it does not change.

regards

Jeff

Wuerfel_21

The Spin header is 16 bytes and should stay as loaded from EEPROM, unless you've changed the clock or otherwise overwritten it (which is fine, since only the clock related fields are ever used after boot)

Layout looks like this:

long[$0000] is CLKFREQ
byte[$0004] is CLKMODE
byte[$0005] is checksum (doesn't actually do anything)
word[$0006] is initial PBASE (pointer to top object code)
word[$0008] is initial VBASE (pointer to top object VARiables)
word[$000A] is initial DBASE (points to the dummy stackframe at end of program)
word[$000C] is initial PCURR (pointer to main function)
word[$000E] is initial DCURR (stack on startup, basically DBASE + whatever space is needed for the stackframe and the main function's locals)