Forum Index
HomeZBasic Home   Forum RulesForum Rules   Forum FAQForum FAQ   MemberlistMemberlist   UsergroupsUsergroups   RSS FeedRSS Feed
Site SearchSite Search   LinksLinks   DownloadDownload   Digests and SubscriptionsDigests and Subscriptions
ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in   RegisterRegister
Buglet: Can corrupt firmware with program download

 
Post new topic   Reply to topic    Forum Index -> ZX-40
Author Message
drapal



Joined: 24 Jan 2006
Posts: 25
Location: Denver
Posted: 04 April 2007, 0:13 AM    Post subject: Buglet: Can corrupt firmware with program download Reply with quote
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.
Back to top
mikep



Joined: 24 Sep 2005
Posts: 765
Location: Austin, TX
Posted: 04 April 2007, 3:53 AM    Post subject: Reply with quote
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.
Back to top
stevech



Joined: 23 Feb 2006
Posts: 656
Posted: 04 April 2007, 5:51 AM    Post subject: Reply with quote
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
Back to top
mikep



Joined: 24 Sep 2005
Posts: 765
Location: Austin, TX
Posted: 04 April 2007, 6:47 AM    Post subject: Reply with quote
stevech wrote:
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.
Back to top
dkinzer
Site Admin


Joined: 03 Sep 2005
Posts: 2493
Location: Portland, OR
Posted: 04 April 2007, 15:06 PM    Post subject: Reply with quote
mikep wrote:
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.
Back to top
drapal



Joined: 24 Jan 2006
Posts: 25
Location: Denver
Posted: 04 April 2007, 18:48 PM    Post subject: Reply with quote
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.
Back to top
mikep



Joined: 24 Sep 2005
Posts: 765
Location: Austin, TX
Posted: 05 April 2007, 1:50 AM    Post subject: Reply with quote
dkinzer wrote:
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().

Last edited by mikep on 05 April 2007, 7:06 AM; edited 1 time in total
Back to top
dkinzer
Site Admin


Joined: 03 Sep 2005
Posts: 2493
Location: Portland, OR
Posted: 05 April 2007, 2:40 AM    Post subject: Reply with quote
mikep wrote:
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".
Back to top
mikep



Joined: 24 Sep 2005
Posts: 765
Location: Austin, TX
Posted: 05 April 2007, 7:04 AM    Post subject: Reply with quote
dkinzer wrote:
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.
Back to top
drapal



Joined: 24 Jan 2006
Posts: 25
Location: Denver
Posted: 16 April 2007, 20:35 PM    Post subject: A followup: Persistent memory use is very flakey. Reply with quote
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?
Back to top
dkinzer
Site Admin


Joined: 03 Sep 2005
Posts: 2493
Location: Portland, OR
Posted: 16 April 2007, 20:52 PM    Post subject: Re: A followup: Persistent memory use is very flakey. Reply with quote
drapal wrote:
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.
Back to top
drapal



Joined: 24 Jan 2006
Posts: 25
Location: Denver
Posted: 16 April 2007, 21:03 PM    Post subject: Thanks. And some more infor on the problematic device... Reply with quote
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.
Back to top
Display posts from previous:   
Post new topic   Reply to topic    Forum Index -> ZX-40 Time synchro. with the server - Timezone/DST with your computer
Page 1 of 1

 


All content Copyright © 2005-2012 Elba Corp. All Rights Reserved.
Opinions expressed in posts are those of the author and not necessarily those of Elba Corp.
Powered by phpBB © 2001, 2005 phpBB Group