ZBasic Application Self-Update

[dkinzer]

1) Does the VM do a CRC check on the firmware after ResetProcessor() [...].

The VM does nothing with either the CRC or code size values other than storing them in Persistent Memory. They were added as an aid to identifying the code that exists in the device. In the IDE, when you perform a device identification, the size and CRC values are also displayed. These values are also listed in the .map file (if enabled) so you can compare them with the reported values.

2) what might a motivation be for making sure this value is accurate after a remote update?

Only for full emulation of a download cycle. If you don't intend to use the code size/CRC values you can ignore them.

[mikep]

In summary, a VM remote updater is desirable, even though it has an established track record -- considering our special requirements. However, considering the complexity of developing or contracting the development of a VM remote updater, we have decided to place less importance on this as a calculated risk.

Given that you have seem to have a lot of control over the final hardware then there are all kinds of solutions that could be applied. For example how about a second dedicated update processor? The VM update or application update can be downloaded to flash memory connected to the update processor. Then it could connect to the primary processor via the serial port and emulate a PC doing a VM or application download to the main processor. Most of the code is already written for you - see ZLOAD source code. The advantage here is that the update is completely outside of the processor. If the software update is good then the main processor can apply it to the update processor.

Even more advanced would be to have two processors that look the same. One is the backup for the other and always has software version n-1. The backup processor updates the main processor with a new VM or new application. If there is a problem, it takes over, updates the "bad" processor with a copy of known working code which now becomes the "backup" processor.

I'm not expert in redundant systems but I could see how this might work using two processors and some additional logic. I'm off to Google on "microcontroller redundant systems"

[abarnes]

I'm off to Google on "microcontroller redundant systems"

lol..

Yes in future iterations of the hardware such functionality will be built in. Unfortunately, new iterations and runs are very expensive so we have to work with what we've got until the next official version (at which point we can explicitly bill out the greater hardware redundancy).

Another concern is size [and battery consumption, though this can be mitigated in various solutions]:

We've built alot of redundancy into our hardware for this reason, though size is a very relevant concern also, so we must balance these requirements.

As I noted before, the hardware design is inherited, otherwise we might have just gone with the SetBoot() function and a simple second EEPROM for this release. With the additional size and complexity of a second processor, we could have an onboard hardware implementation of a VM updater. Apparently it didn't meet the size spec for the last iteration.

Either way, we now have a method which gives us software-only, fine-grained control at the expense of some redundancy. Additionally, the method may be scaled up to more redundant systems. We can literally hot-swap code remotely (think remote Lisp terminal or Erlang node) if we so desired. Not that we'll be doing that for this system, but that gets the geek in me going.

Kudos!



Also, I must say that the rapid prototyping provided by ZBasic is really wonderful considering the design time that would be required in other AVR alternatives. The built-in multitasking, queuing and semaphore support are particularly robust for such a small form factor. I liked the "error handling goto" feature provided as well. It also allows for a more stable final product with features like runtime stack-overflow checking and integrated watchdog support. But you guys already knew that.

- Austin

p.s.

Now for a crazier question that I was holding off on until we covered some of the bases:

1) Is it possible to instruct the VM to read program instructions directly from another device such as an nvram flash or even from the chip's own persistent memory locations? Perhaps through use of the SetBoot() function? This could present an interesting on-chip bootloader solution if we could fit one in that small on-chip space (and of course eliminates the issue of collision during bootloader-update).

This functionality is not required but if possible it'd be nice to know.

[dkinzer]

Is it possible to instruct the VM to read program instructions directly from another device such as an nvram flash or even from the chip's own persistent memory locations?

Currently, there is no such capability. Implementing an alternate instruction source could be done but it would necessarily slow down the main interpreter loop, something we are reluctant to do.