Buglet: Can corrupt firmware with program download

[drapal]

I recovered from this, so it's not necessarily urgent. What happened is that I compiled a program that used more persistent memory than the device was capable of (zx40a, avail=2016, compiled to use 2568). No error/warning in the IDE. Down loaded and verified correctly (the first time). Made a change and tried to download - verify failed at record 2. Had to reprogram the firmware in the device to recover.

[mikep]

I have tried to recreate it but could not after trying several times.

The ZVM is stored in flash and really doesn't have much to do with persistent memory. It is possible there was some other glitch and VM had an error. Again it is unlikely you would need to redownload the VM to correct the problem so I don't quite understand what happened.

If you are feeling brave (actually it should be all ok), why don't you try it again and see if you can recreate the problem.

[stevech]

I think the VM relies on a few persistent variables that it stores in the on-chip EEPROM. I think they're at the first 100 or so bytes. The bug may have wrapped the address bit modulo and clobbered these bytes.

ZBasic built-in constants
Register.PersistentStart, Register.PersistentSize and Register.PersistentUsed

[mikep]

I think the VM relies on a few persistent variables that it stores in the on-chip EEPROM. I think they're at the first 100 or so bytes. The bug may have wrapped the address bit modulo and clobbered these bytes.

ZBasic built-in constants
Register.PersistentStart, Register.PersistentSize and Register.PersistentUsed

You are correct Steve - the first 32 bytes of EEPROM is reserved for the VM. Downloading a program should not overwrite this first 32 bytes unless there was some kind of wrap defect. I tried and failed to duplicate the problem by writing this time to high persistent memory addresses (2000-2080 on a ZX-24ae).

Even if the EEPROM values were overwritten with bogus values, I still don't see how that would cause the VM problem as described. Don will need a reproducible scenario to fix this problem.

[dkinzer]

You are correct Steve - the first 32 bytes of EEPROM is reserved for the VM. Downloading a program should not overwrite this first 32 bytes unless there was some kind of wrap defect.

The address will wrap around to zero and the system area will be overwritten. It is most likely that the overwriting of the EEPROM configuration bytes caused the subsequent download failure.

The compiler should be modified to detect "overflow" of Persistent Memory.

[drapal]

I think this wrap-around is exactly what I had happen. Note that from my example I overflowed by more than 500 bytes.

I've since moved on (by fixing my code), so I don't have a handy way of generating this again.

[mikep]

The address will wrap around to zero and the system area will be overwritten. It is most likely that the overwriting of the EEPROM configuration bytes caused the subsequent download failure.

The compiler should be modified to detect "overflow" of Persistent Memory.

There is still a latent problem here even with the compiler fix. Deliberately or through a defect it is still possible with PutPersistent() to write to the first 32 bytes of presistent memory and cause the VM to bomb. Probably the best fix is to ensure that the VM can cope with invalid values in the persistent memory.

Edited on 4/5/07 to replace PutProgMem() with PutPersistent().

[dkinzer]

Deliberately or through a defect it is still possible with PutProgMem() to write to the first 32 bytes of program memory and cause the VM to bomb.

I suspect that you meant to refer to PutPersistent() and Persistent Memory but I understand what you're saying. The VM does perform some sanity checks on the EEPROM configuration values and resorts to using the default if a problem is detected. However, that isn't helpful if you have an EEPROM attached that is "non-standard".

[mikep]

I suspect that you meant to refer to PutPersistent() and Persistent Memory but I understand what you're saying.

Yes you are right - I meant PutPersistent(). I have edited the faulty text as well.

[drapal]

I now have a device (zx40a) that will not respond to ACK. This part was good, but I can't even recover it using the firmware download method that I used before. Is there any other way in? I know that the device is OK.

BTW, computation of the address using DataAddress is very unpredictable. If you use it on an array reference (var(i).DataAddress), regardless of type, if you debug.print the address, it looks reasonable (from the .map file entries), but if you use this with PutPersistent you may well get a wild write - no real prediction. This problem also exists if an array reference is included in a singleton structure - you can correctly write the piece-parts of the structure, but writing to the array doesn't work. The only way that I've been able to get array accesses to work is to include the "base element" in a structure and declare the structure as an array:

Structure A
Dim B As Byte
End Structure
Dim C(1 To 10) As Persistent A

THis declaration seems to work. The obvious declaration:

Dim C(1 to 10) as Persistent Byte

Fails miserably, and usually corrupts the device. The line of code that I've been using in the above cases looks like:

Call PutPersistent(C(i).B.DataAddress, byte_val, 1)

or:

Call PutPersistent(C(i).DataAddress, byte_val, 1)

respectively.

But I digress (slightly). My more immediate need is to get my device working again. Is there anything I can do to re-initialize the device?

[dkinzer]

My more immediate need is to get my device working again. Is there anything I can do to re-initialize the device?

If you've already performed a firmware download, there is probably nothing more to try.

I'll have a replacement sent out to you today. I'd like to get the problematic device back to see if we can learn anything from it.

With regard to the other issue, we'll look at it to see where the problem might lie.

[drapal]

I paired it with an eeprom that I programmed from another device, and it functions fine. Including running the code in the eeprom. But it still won't download.

I'll also try to re-create the situations that I described before. I know how helpful a test program can be when re-creating a problem.