Dual Programs, Virtual EEPROM

[mdown]

We want to be able to switch running code on the fly or after a reset, I have mentioned this to Don before, but we never came up with a solution. While reading the docs on the FRAM 512k module a came across this schematic. So Don, MikeP, stevech, spamiam any ideas? Or can I use a 512k module and set the inital jump point, basically partitioning the device into 2 256k virtual devices? The goal is to be able to do firmware updates over a gprs connection write the new firmware to the inactive side of the eeprom, set the jump point and the reset the cpu.

-Mike

[stevech]

You may have problems doing firmware updates via GPRS due to latency. It is typically 100-200mSec, and often 1 second in the cellular busy hours.

If you are in the US, Verizon EV-DO is much better, but still has high latency and busy hour problems. It is 800Kbps + off-peak, downstream, and about 50Kbps off-peak upstream. EV-DO's coverage is excellent throughout the US. Sprint, the other CDMA carrier in the US, claims they will/are deploying EV-DO. But they're also planning WiMAX and this erodes their own EV-DO plans. So Verizon is your best bet.

GPRS is 50Kbps downstream and 10Kbps or so upstream. The GPRS successor is EDGE, now too usurped by UMTS, as AT&T and Cingular keep dumping their upgrade plans due to the constant mergers and acquisitions.

The ATN scheme may well not to work on such circuits.

I've done firmware loading across a WiFi LAN, but this is low latency. I could try in across the Internet with long delays. Better would be for Don to comment on the protocol limitations for the ATN handshake and for the character or packet response aspects of the downloader.

There is an IETF RFC for serial port control via IP (control packets for RTS/CTS/DTR, etc.).

[dkinzer]

We want to be able to switch running code on the fly or after a reset[...]

Switching on the fly is fraught with possible problems. Switching during reset time is certainly feasible.

[Can I partition] the device into 2 256k virtual devices?

This is probably impractical to do. The address values are sent to the device in a serial bit stream. You'd have to intercept the bit stream and modify the high order address bit.

[spamiam]

This is an interesting question!

Since timing is a major issue, would it be possible to download the program files to one ZX processor, just as a plain old serial communication, and have it stored somewhere non volatile. EEPROM, FRAM, Flash, MMC card. Additionally, this program is able to decide which program to send to a second ZX. This second ZX gets its program downloaded whenever necessary, and runs the functional code.

This avoids the timing issues to a large degree. To the second ZX, it is just a regular download and run transaction. To the first ZX, it is all just serial communication.

-Tony

[mdown]

Ok then how about using 2 eeproms as depicted in the image in my first post?

-Mike

[spamiam]

Ok then how about using 2 eeproms as depicted in the image in my first post?

-Mike

I thought about that at first. I thought that it might be possible to D/L one program to one, and another to the other. Then one might be able to select which EEPROM to use via extra logic (XOR gates?) and an extra CPU pin combined with the standard SPI CS signal.

But I think that the issue is also the DOWNLOADING of the program to the EEPROM. It seemed like they were saying that the timing of the wireless connection may not work for remote downloading.

This is why I thought it might be useful to download data over the cellular network to one CPU, then use that CPU to do the actual programming of the second CPU. This way timing issues can be precisely controlled.

-Tony

[stevech]

so the protocol you'd run on cellular EV-DO or GPRS or ... would be some protocol of your choice, rather than the ZBasic downloader per se. That makes sense, given some appropriately sized temporary storage media.

[dkinzer]

how about using 2 eeproms as depicted in the image in my first post?

The ZX firmware is written to use a specific chip select line and it is hard-coded. It could be changed to be determined at run-time but that would slow down the instruction fetch cycle and require more code - neither effect very palatable.

Another option for utilizing a second EEPROM is to add code to the VM so that at startup, it can be directed to copy data from the auxiliary storage to the main Program Memory. That would allow you to write a new program to the auxiliary storage, set a value in the system portion of on-board EEPROM and then reset. Upon booting up, the VM would see the "load" indicator, copy the program, reset the load indicator and then continue startup as normal.

[mdown]

Another option for utilizing a second EEPROM is to add code to the VM so that at startup, it can be directed to copy data from the auxiliary storage to the main Program Memory. That would allow you to write a new program to the auxiliary storage, set a value in the system portion of on-board EEPROM and then reset. Upon booting up, the VM would see the "load" indicator, copy the program, reset the load indicator and then continue startup as normal.

So your saying that the firmware would be written to the secondary eeprom while running from the primary eeprom. Then we set a flag, reboot, and the VM copies the firmware from the secondary eeprom to the primary eeprom then begins execution?

This seems like a viable option. Stevech, we have our own protocol running on GSM EDGE. We would not update in realtime, it's too risky

-Mike

[dkinzer]

So your saying that the firmware would be written to the secondary eeprom while running from the primary eeprom. Then we set a flag, reboot, and the VM copies the firmware from the secondary eeprom to the primary eeprom then begins execution?

Just so. Of course, this is just a hand-waving description of the concept. The idea needs more thought and research but I believe that it is workable. Depending on how much code it takes to implement, it may have to be restricted to the mega644-based ZX models.

[mdown]

This is a feature that would really set the ZX processors apart from the others even more than they do now. We have migrated to the atmega644 series processors anyhow, as they have more user ram. We keep pushing the limits when it come to user ram. Its quite a puzzle.

-Mike

[stevech]

I've seen this in place in many embedded and consumer devices, though only ones with a RAM large enough for the new image. Usually for flash memory, since executing code out of EEPROM is unusual.

A great example are the PC BIOSes these days - where several prior downloaded versions are kept for fall-back purposes. Also done for some ARMs, modems, etc.

[mikep]

Another option for utilizing a second EEPROM is to add code to the VM so that at startup, it can be directed to copy data from the auxiliary storage to the main Program Memory. That would allow you to write a new program to the auxiliary storage, set a value in the system portion of on-board EEPROM and then reset. Upon booting up, the VM would see the "load" indicator, copy the program, reset the load indicator and then continue startup as normal.

I think we need to go back to some first principles here.

1. First of all what is the requirement to have multiple programs that can be swapped around? Why can't this all be done in one program? Are you trying to upgrade the existing program to the device.

2. We know that the communications in and out is slow and unreliable so any program download has to be into some kind of auxiliary storage but necessarily an SPI EEPROM.

3. The program downloader could be a different, special purpose device as suggested by stevech or could be the same device using a background thread. CRC checks, retrys and restarts are probably required for the downloader.

4. We need a way once the program is downloaded to swap it into the existing EEPROM. There are a number of hardware and software solutions to this problem. So far the discussion has concentrated on a hardware solution and "swapping EEPROMs".

I believe there is also a software solution to this problem although further prototyping is needed. The first part of your program is a "boot loader" or "overlay manager" that can copy code from the auxiliary storage into the main program memory EEPROM and overwrite the existing program. You may decide that you want to overwrite only part of the existing program or the whole memory (which is much harder). This solution requires a certain amount of rigor about how you write your program and ensuring that the "overlay manager" is always in the low memory addresses before the rest of the program logic.

I have prototyped a debugger for BasicX before where specific instructions were replaced by a jump to a debug routine, the instructions then re-executed and then a jump back to the rest of the code. This implementation was generic but required intimate knowledge of the BasicX firmware language. The idea of a software-based "overlay manager" is actually simpler than the debugger idea and can be simplified I believe to the point where you only need to obey some simple coding conventions in each of the overlay programs.

[mdown]

1. First of all what is the requirement to have multiple programs that can be swapped around? Why can't this all be done in one program? Are you trying to upgrade the existing program to the device.

1. We are using the ZBasic cpus's in a sealed enclosure. These units have various sensors attached. They communicate back to us via GPRS/EDGE over the GSM network. They are all over the world. The ability to upgrade the firmware over the air is a feature that would save our customers time and money. And set us ahead of our competitors.

We know that the communications in and out is slow and unreliable so any program download has to be into some kind of auxiliary storage but necessarily an SPI EEPROM.

2. The average size of our zxb is 27-30 KB, it does a lot. This would be nothing to transfer in blocks to the aux eeprom using gprs as a communications medium.

The program downloader could be a different, special purpose device as suggested by stevech or could be the same device using a background thread. CRC checks, retrys and restarts are probably required for the downloader.

3. This is not practical. How do you update the updater? (in the field)

4. We need a way once the program is downloaded to swap it into the existing EEPROM. There are a number of hardware and software solutions to this problem. So far the discussion has concentrated on a hardware solution and "swapping EEPROMs".

Actually we were talking about a combination of hardware and VM code. We would write to the aux eeprom while we are downloading the new firmware then when done perform a crc check on it, then set the loader flag, reboot the cpu, then the VM overwrites the primary eeprom with the code in the aux eeprom, then the VM begins normal operations.

-MikeD

[mikep]

Actually we were talking about a combination of hardware and VM code. We would write to the aux eeprom while we are downloading the new firmware then when done perform a crc check on it, then set the loader flag, reboot the cpu, then the VM overwrites the primary eeprom with the code in the aux eeprom, then the VM begins normal operations.

As an alternative I'm suggesting that there is also a possible software solution that might be more flexible in terms of the auxilary storage (could be RAM, Flash, I2C EEPROM, SPI EEPROM etc) and the supported devices. I believe because the ATmega devices are tight on flash that the hardware solution proposed by Don could only be done for the ATmega644 based devices.