Odd PE6 issue

[Rampz]

I have several sets of code open on my laptop, i'm trying to get the 20X2 working with the altered code from an 08M2, i notice while doing this that my fault counters are reading 65535 the highest they could read, i have several issues anyway i had a circuit set up on the AXE091, the editor is set to 20X2, getting rather hot under the collar, so decide best to go back and get the 08M2 working.

So change editor to 08M2 on the left, build a board up on the second AXE091, put a 08M2 in and power up, load the 08M2 code into the PICaxe, i notice when i check my fault counters that are set to read the last value that was saved, one counter is normal and in line with the number of faults i had created, but the other was still at 65535, as if the editor had written these values to the picaxe, the chip was a new chip, so thought faulty chip maybe so tried another one and it did the same, i altered my code to not retreive previous settings, and then reversed it after a download to try and clear the counters which worked, and after several more downloads everything is working as expected.

My circuit has a recall button to recall the counters after which it deletes the count, but that didn't work on the 65535 one, i have never had this before seems really strange as if the editor wrote eeprom data from the 20X2 to the 08M2 which are both using the same counters in different code set ups

Any one had similar issues, with multiple sets of code open at the same time and working with different sets of code etc?

 

[Rampz]

I have played further by putting the previous 08M2 back into the AXE091 and done a download, the counter was at 65535 again, the counter uses W10.

I alter the code slightly to not read from the eeprom at power up, all is good, alter the code back and download again and the 65535 is back again, so i give it one more fault and it increments to zero, and works fine from there onwards.

Or maybe the eeprom has some suprious number in W10 from the start and i am having trouble clearing it, maybe its not clearing at a new download, should it clear at this point, i'm set as #no_data at the top of my code

 

[Rampz]

Changed to a 3rd 08M2 and programmed it and both counters are at 65535, seems maybe not an editor issue more how the PICaxe's are coming from new? Really strange

 

[AllyCat]

Hi,

Really strange

Not really. The value 65535 is $FFFF or 16 x binary 1's (i.e. two bytes), which is the way that EEPROM memory contents are often supplied from the factory. AFAIK, an EEPROM "Erase" cycle always forces all bits to Logical "1". It's only the Registers/RAM (i.e. including W10) which are specifically cleared to zero by the Operating System Software, when the PICaxe boots up at a Reset or Power-up.

However, it's difficult to generalise, particularly for the 08M2, because the PICs have separate areas of Program EEPROM and Data
EEPROM, with somewhat different characteristics.

Cheers, Alan.

 

[Rampz]

I didn't know that they are often supplied like that, that would account for it, i was wrong to say it was W10, that was the normal memory location, it is position 0 and 1 of the eeprom that the 2 fault counters are written to, with W10 being where the data is coming from to be written, So should i do something before programming with my final code, like run a few lines of code to set the eeprom positions i will be using to zero?

 

[PhilHornby]

So should I do something before programming with my final code, like run a few lines of code to set the eeprom positions I will be using to zero?

That's what the EEPROM statement does. You can temporarily disable its effects, through use of the #no_data directive (which is effectively the same as commenting out all the EEPROM lines.)

 

[Rampz]

That's what the EEPROM statement does. You can temporarily disable its effects, through use of the #no_data directive (which is effectively the same as commenting out all the EEPROM lines.)

Ok Phil, like most people I use the #no_data to speed up downloading code, but for a new from factory chip I would on first download be best to remove that directive to clear eeprom data? Then in future downloads put it back in, if not using eeprom then no issue either way

 

[hippy]

Normally a download will set Eeprom to all zeroes or whatever is specified in EEPROM or DATA statements.

With #NO_DATA a download will not affect Eeprom, will leave it as it was.

I have never tried a #NO_DATA download on a PICAXE fresh off the production line but it seems likely it could be all $FF, 255, 65535 or random values.

One way to check if the Eeprom has ever been used is to read it and see if it holds the values which would be expected after it has been used at least once. A simple version of doing that could be -

#No_Data

Symbol EEPROM_CHECK = $A3C5

Read 0, Word w0
Read 2, Word w1
w1 = -w1
If w0 = EEPROM_CHECK and w0 = w1 Then
  SerTxd("Eeprom already initialised", CR, LF)
Else
  SerTxd("Initialising Eeprom", CR, LF)
  w0 = EEPROM_CHECK
  w1 = -w0
  Write 0, Word w0
  Write 2, Word w1
End If

There is a small chance that an Eeprom may appear initialised when it isn't. Adding additional words in Eeprom will reduce that risk.

 

[Aries]

Normally a download will set Eeprom to all zeroes or whatever is specified in EEPROM or DATA statements.

My impression from what I have done in the past (and I may be wrong, but I do exploit it) is that EEPROM data at any address is left intact unless that address is specified in a DATA or EEPROM statement and, of course, there is no #NO_DATA

 

[Goeytex]

So should i do something before programming with my final code, like run a few lines of code to set the eeprom positions i will be using to zero?

Microchip defines the erase state of any bit of EEPROM as a "1" and any byte as $FF (%11111111). The same applies to program flash memory. From the factory, these unprogrammed bytes of EEPROM memory will all be 255.

It depends upon how Microchip programs a chip with the Picaxe Bootloader/Firmware as to whether or not a new Picaxe has erased EEPROM ($FF) or cleared EEPROM ($00). If you are seeing 255 as the initial value of all EEPROM locations, then it has been "erased".

According to manual 2, when a Picaxe is programmed via PE6, if there is no EEPROM statement (and no #NO_DATA directive), then all EEPROM locations are cleared to "0".

The #NO_DATA directive tells the bootloader not to mess with the EEPROM. So the EEPROM remains in the same state it was in prior to programming. In other words it is neither erased nor cleared.

Whether or not you write "0's" to EEPROM memory locations prior to main code execution is up to you. It is not necessary. If you want to pre-load EEPROM locations with specific values you can use the EEPROM Statement.

Goey

 

[hippy]

My impression from what I have done in the past (and I may be wrong, but I do exploit it) is that EEPROM data at any address is left intact unless that address is specified in a DATA or EEPROM statement and, of course, there is no #NO_DATA

That is odd because the compiler / downloader should be sending 'all or nothing'.

It depends upon how Microchip programs a chip with the Picaxe Bootloader/Firmware as to whether or not a new Picaxe has erased EEPROM ($FF) or cleared EEPROM ($00). If you are seeing 255 as the initial value of all EEPROM locations, then it has been "erased".

I believe we still program the blank chips we get from Microchip ourselves because that's a cheaper option, keeps PICAXE prices down. We purchased the equipment to do that long before Microchip offered a bulk programming service so it makes sense to keep doing that. I recall the machine takes a tube of blank chips in, programs them and spits them out into an empty tube, or tosses them out the side if they fail programming or testing.

I would guess we simply don't program Eeprom.