Peter Goldsbury
Member
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?
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?