Stamp gets stuck
Archiver
Posts: 46,084
In my BS2 application the user is given some options - continue from
where they left off or record new data. If they choose record new
data it sets an EEPROM address and starts recording the data
everything works fine. If the user chooses to continue the program
reads a specific EEPROM address where the next free EEPROM address
is. It then goes on to record the data but after two keypresses the
program just sticks - nothing at all happens. The bit of code where
it sticks works fine if the user comes through from pressing the new
command. I have had other bugs in my programs before but then the
stamp reset. I have never had one freeze up like this. If anyone
could help it would be greatly appreciated.
Andy
where they left off or record new data. If they choose record new
data it sets an EEPROM address and starts recording the data
everything works fine. If the user chooses to continue the program
reads a specific EEPROM address where the next free EEPROM address
is. It then goes on to record the data but after two keypresses the
program just sticks - nothing at all happens. The bit of code where
it sticks works fine if the user comes through from pressing the new
command. I have had other bugs in my programs before but then the
stamp reset. I have never had one freeze up like this. If anyone
could help it would be greatly appreciated.
Andy
Comments
program data is at location 410 hex, then you cannot write data to or beyond
this byte. You may have to limit the amount of data being written to prevent
this occuring.
Chris
Original Message
From: Andy Schwarz <phyaks@p...>
To: <basicstamps@egroups.com>
Sent: Friday, November 10, 2000 12:51 AM
Subject: [noparse][[/noparse]basicstamps] Stamp gets stuck
> In my BS2 application the user is given some options - continue from
> where they left off or record new data. If they choose record new
> data it sets an EEPROM address and starts recording the data
> everything works fine. If the user chooses to continue the program
> reads a specific EEPROM address where the next free EEPROM address
> is. It then goes on to record the data but after two keypresses the
> program just sticks - nothing at all happens. The bit of code where
> it sticks works fine if the user comes through from pressing the new
> command. I have had other bugs in my programs before but then the
> stamp reset. I have never had one freeze up like this. If anyone
> could help it would be greatly appreciated.
>
> Andy
>
>
>
EEPROMS. The code that comes straight after the read EEPROM
subroutine works. It is later on in the program where it sticks.
Andy
--- In basicstamps@egroups.com, "Chris Anderson" <fes@g...> wrote:
> Is your data overwriting your program data ?, ie if your last byte
of
> program data is at location 410 hex, then you cannot write data to
or beyond
> this byte. You may have to limit the amount of data being written
to prevent
> this occuring.
> Chris
>
Original Message
> From: Andy Schwarz <phyaks@p...>
> To: <basicstamps@egroups.com>
> Sent: Friday, November 10, 2000 12:51 AM
> Subject: [noparse][[/noparse]basicstamps] Stamp gets stuck
>
>
> > In my BS2 application the user is given some options - continue
from
> > where they left off or record new data. If they choose record new
> > data it sets an EEPROM address and starts recording the data
> > everything works fine. If the user chooses to continue the program
> > reads a specific EEPROM address where the next free EEPROM address
> > is. It then goes on to record the data but after two keypresses
the
> > program just sticks - nothing at all happens. The bit of code
where
> > it sticks works fine if the user comes through from pressing the
new
> > command. I have had other bugs in my programs before but then the
> > stamp reset. I have never had one freeze up like this. If anyone
> > could help it would be greatly appreciated.
> >
> > Andy
> >
> >
> >
>In my BS2 application the user is given some options - continue from
>where they left off or record new data. If they choose record new
>data it sets an EEPROM address and starts recording the data
>everything works fine. If the user chooses to continue the program
>reads a specific EEPROM address where the next free EEPROM address
>is. It then goes on to record the data but after two keypresses the
>program just sticks - nothing at all happens. The bit of code where
>it sticks works fine if the user comes through from pressing the new
>command. I have had other bugs in my programs before but then the
>stamp reset. I have never had one freeze up like this. If anyone
>could help it would be greatly appreciated.
>
>Andy
Hi Andy -
What type of interface does the EEPROM use - serial or parallel, and if
serial I2C, Microwire or what ?
A code snippet of the offending code would be helpful too.
Regards,
Bruce Bates
and if
> serial I2C, Microwire or what ?
>
> A code snippet of the offending code would be helpful too.
>
> Regards,
>
> Bruce Bates
The EEPROMS are serial, not sure about the wiring because the
electronics workshop at my university built it for me from my circuit
diagrams. The program does not stick there though and it works if the
user has chosen to write new data. The bit of code is here:
CALSOIL:
GOSUB KEYIN
IF inA <> 6 THEN CALSOIL
EEaddr = 3
<---- here is where it sticks
GOSUB GETDATA
it never calls the GETDATA subroutine when the user has previously
pressed continue. If the user presses the continue button (much
earlier in the code) then this is the code that follows:
CONTINUE:
dirl = %01111111
char = clrLCD
GOSUB LCDcmd
char = $80
line = Line06
GOSUB DISPLAY
EEaddr = 0
GOSUB EEREAD
temp = EEdata
GOSUB EEREAD
temp = (temp * 256) + EEdata
PAUSE 1500
GOTO STARTLOG
If the user selects the write new data then this is the code:
NEW:
dirl = %01111111
char = clrLCD
GOSUB LCDcmd
char = $80
line = Line07
GOSUB DISPLAY
temp = 11
PAUSE 1500
GOTO STARTLOG
It is not the subroutines that are called that is causing the problem
as tey are used several other times in the program and they work
every time then.
Andy
> > What type of interface does the EEPROM use - serial or parallel,
>and if
> > serial I2C, Microwire or what ?
> >
> > A code snippet of the offending code would be helpful too.
> >
> > Regards,
> >
> > Bruce Bates
>
>The EEPROMS are serial, not sure about the wiring because the
>electronics workshop at my university built it for me from my circuit
>diagrams.
Please get the CHIP NUMBERS and that will be indicative of the access method.
> The program does not stick there though and it works if the
>user has chosen to write new data.
How can you be sure ?
> The bit of code is here:
>
>CALSOIL:
>GOSUB KEYIN
>IF inA <> 6 THEN CALSOIL
>EEaddr = 3
'<--decisions about read or write need
'<--to be made here, or before the
actual '<--access. So too CS if required.
> <---- here is where it sticks
>GOSUB GETDATA
>
>it never calls the GETDATA subroutine when the user has previously
>pressed continue.
Timing problems may exist if write cycle timings are NOT honored. With READ
it's either THERE or it's NOT.
>If the user presses the continue button (much
>earlier in the code) then this is the code that follows:
>
>CONTINUE:
>dirl = %01111111
>char = clrLCD
>GOSUB LCDcmd
>
>char = $80
>line = Line06
>GOSUB DISPLAY
>
>EEaddr = 0
>GOSUB EEREAD
>temp = EEdata
>GOSUB EEREAD
>temp = (temp * 256) + EEdata
>PAUSE 1500
>
>GOTO STARTLOG
>
>If the user selects the write new data then this is the code:
>
>NEW:
>dirl = %01111111
>char = clrLCD
>GOSUB LCDcmd
>
>char = $80
>line = Line07
>GOSUB DISPLAY
>
>temp = 11
>PAUSE 1500
>
>GOTO STARTLOG
>
>It is not the subroutines that are called that is causing the problem
>as tey are used several other times in the program and they work
>every time then.
As I mentioned the timing may be critical, and changing the program may
change the timing. I'd look to the accessing of the chip on outwards, or
from the chip lines back to the Stamp. Once the interface is deemed solid,
then go looking elsewhere. That's just MY methodology. YMMV, of course.
>Andy
Bruce