18m2 - linternal lockup on write /read commands and more - any advice please.

[Peter Goldsbury]

I have implemented a 65 k byte Fifo using two external i2c EEproms for a 18M2 (2B version) data logger that uses that F9 datalink function to dump data it has collected via its datastore routine. The pointers for this are held in 18m2 program memory.

It seems that there may be an internal lockup state the PICAXE can get into where some commands do not work normally even after a program reload. I have replaced the chip with the same result. It seems to clear after a full powerdown. It happens similarly on three different physical items of hardware with the same basic configuration. I suspect it may be triggered by the act of removing the programming cable.

1. the Data store routine is generally

read xx, pointer (b26-b27)
debug placed here ; this returns a pointer value of 0 when in the lock up state, so it only fills the first record.

; store data into ext EEPROM indirectly via the pointer (incrementing for 80 bytes ) using 12c code

if debug placed here ; this returns a pointer value of 80 as expected
write xx, pointer

2. the Datalink code is generally

Detect the F9 datalink "G" character by it setting the latch input in parallel with programing in line ( as the PICaxe is mostly asleep using ther NAP commenad to save power)
let pointer = 0
;loop the following routine until the pointer reaches the end of memory

read xx, pointer (b26-b27)

; read data indirectly via the pointer (incrementing for 80 bytes ) using 12c code
; sertxd to the F9 datalink

write xx, pointer

When not locked up this routine works perfectly, but when is locks up after removing the programing cable it transmits indefinately , I assume because the pointer never gets to beyond the end of external EEROM memory limit value.


I am doing this with a direct serial out cable from my desctop PC, but also found the same symptoms when using the PICAXE AXE027 serial USB cable from a laptop.


3 I also got a similar lockup happening with a single bit flag at one point


let actionflag (=bit8) = 1
debug placed here ; this returns a pointer value of 1 as expected

; a couple of in line commands

if actionflag =0 then goto noaction

action:
debug here is never reached - indicating flag is read as zero.

noaction;


I have not tried putting a another plug in the programming lead so all lines can be disconnectd in parallel in case the acton of pushing in the 3.5mm strereo plug is causing a transient flashover on the data lines as it is inserted.

ANY SUGGESTIONS PLEASE?

 

[nick12ab]

I've recently written an explanation of what is happening regarding the download connector itself here however experiences regarding it that I've personally experienced are just a temporary freeze-up then reset.

 

[Technical]

Are you sure it is not the i2c bus locking up (i2c slave device getting locked) and so the program not working as expected?

Your post is hard to understand - your BASIC code would be helpful. However if you interrupt an i2c transaction (read or write) mid-way this can sometimes cause the i2c device (eeprom chip) to lockup, which then requires a power reset to resolve.

http://www.picaxeforum.co.uk/showthread.php?18654-Curing-a-locked-up-i2c-bus-after-hardware-reset-of-the-picaxe&p=172863#post172863

You appear to be able to recognise when the program is in this state, so you could modify your program to issue a 'reset' command if identified. This will reset the PICAXE. If this doesn't solve the problem then it indicates there is another issue on the circuit - probably with the i2c bus.

 

[marks]

Hi Pete,
more or less just reinforcing whats written above
when plugging in or removing our programming cable with power on
causes the serial out pin to short momentarily (causing the piacaxe to reset and more often lock i2c up)
we should power off before doing this however we're all guiltly of doing this tho.
because of this I now include a 200 ohm resistor in series with the serial out pin to prevent reset.

 

[MPep]

Could also be a lack of RETURN somewhere.

My 2c worth anyway.

 

[Peter Goldsbury]

Thanks folks I will try a few more things as suggested to resolve this as this is a 24/7 research project application where we must plug into the programing port live every month to dump its data via cdatalink. (iproject info at http://www.whirinakirainforest.info/ecosystem_services_value/Rainforest research/forest sensor/Forest Environment Monitoring Station.doc)

We have not used any subroutines (and returns) in this code MPep.

I did find that the EEPROM data storage was a bit erattic and temperature dependant until I relised that the 10 msec delay after a n I2C write needed to be a pause 80 with the 32 Mhz clockrate. Waiting to see if that effects the above problem, but suspect not as the pointers are in the PICAXE EEPROM, not external.