EEPROM failure vs TABLE use ?

[manie]

Picaxe 28x1:

I store text that is used repetitively in the Menu of the LCD part of the chook-house project in EEPROM thus:

EEPROM 0,  ("1 SETPOINTS ")	'0-11
EEPROM 12, ("2 CURRENT   ")	'12-23
EEPROM 24, ("3 ALARMS    ")	'24-35
EEPROM 36, ("Enter 1/2/3:")	'36-47

After download and for about 5-10 runs (at first) then after about 3-5 runs after fresh download when accessing the above Menu items the display will play up as thisreplace #'s and *'s with different orientations of triangles). I use the firmware chip to drive the LCD (20x4 Blue LCD with standard HD driver)

#*##*TPOINTS
2 CURRENT
3 ..... etc

After a few more runs and after re-download the "ENTER 1/2/3:" part will display as "*##**#*/2/3:"

Moving the offending text to a higher EEPROM address( to above say address 20) stops this happening, as it seems to happen only with the text near the start address of EEPROM.
Also, after moving onto a brand NEW 28x1 chip, the same occured after about 6-10 runs....

I then moved the text to TABLE thus:

Table 0,  ("1 SETPOINTS ")	'0-11
Table 12, ("2 CURRENT   ")	'12-23
Table 24, ("3 ALARMS    ")	'24-35
Table 36, ("Enter 1/2/3:")	'36-47

The problem disappeared. Text is displayed correctly.

It is still running OK without problems after more than 100 cycles accessing the Menu....

Any ideas ?

 

[BeanieBots]

The apparent "working" when using a different EEPROM location might be a red-herring.
I've had similar issues caused by the LCD not initialising correctly at startup.
Make sure you have a pause to allow the power supply to settle.
Then send an LCD clear command.
Another pause to allow the LCD to do the clear and finally your display code.

Other than that, do you have any WRITE commands in your program?
Is there any consistancy to your observations?

I have an old 28X which sometimes forgets it's menu text in a similar manner to the way you describe. It switches on flourescent lights and sometimes crashes out completely. (maybe once in every 30~40 events).
My code includes WRITEs so I'm guessing my problem is a program crash (caused by EMI) which corrupts the EEPROM. I'm guessing that you might have a similar issue.

Does it ever get corrupt when the mains part is disconnected?

 

[Dippy]

Odd. Never seen that before.
I assume you'd see the same apparent corruption if doing a Sertxd as opposed to writing to LCD?
(I had an EEPROM corruption on a Stamp once but I didn't like to swear on the PICAXE Forum )

Do you think it ties up with any power switching? (esp reactive loads)
Does extra decoupling on PICAXE +v/oVground help?
Are any power nasties sneaking through PSU back to PICAXE?
Any hefty power cables near PICAXE circuit?

 

[Andrew Cowan]

Been nice to your PIC?

I plugged in an 18X backwards, it got hot and fried about 20 EEPROM locations.

A

 

[hippy]

You could download a known pattern to Eeprom and have a program which checks it is as it should be. With menu, serial, firmware and LCD added to the mix it could be any number of things. At least this would verify if Eeprom is becoming corrupted or is damaged.

 

[inglewoodpete]

Another possibility is ESD. I have had the EEPROM in a number of 28x1s go faulty. The environment was extremely low humidity (< 5%) and people were getting zaps of over the place. We never proved it, but assumed that the cause was ESD in either the handling of the circuit cards or the running environment.

The code and the remainder of the PICAXEs continued to chug away: just the EEPROM "Reads" would not deliver back the data that was supposed to have been written to it.

 

[Jeremy Leach]

Is there a possibility that some of your code is corrupting the lower EEPROM addresses by writing to them in error? It isn't clear from your description whether it always works fine as soon as you switch on. We haven't seen your code I've mixed up writes and pokes in the past, causing strange things to happen in EEPROM !

 

[manie]

BB, Hippy, Andrew, Hippy, Pete, Jeremy:

The only purpose of this chip is to interface the LCD/Keypad to the 40x1 Main Controller board. Function is to send Hserout data from the keypad to 40x1 and Hserin data from 40x1 to LCD. This happens with Hardware serial and "confirm data" interrupts.

BB, there are NO Write's in this program, ONLY reads, the Writes happens on the 40x1 chip, I have not seen any problems there even using the lower (0-50) register locations.

After fresh download, correct display. A few "read" characters later, it plays up. Reset key press then does NOT help, garbled display still. Power down, power up, display garbled. Do fresh download, display = OK for a few cycles.

Power supply is from 12V 7AH Battery. 4700uF + 100nF on battery power in. Then 7812 regulator with BD244 pnp pass tranny, output=+- 10.8V, decoupled with 100uF + 100nF. This 10V feeds the 7805 5V regulator (also with BD244 pass tranny), output = 5.04V, decoupled again with 100uF + 100nF. Next to the 28x1 supply (really 2mm away) another 100nF decouple. Next to the firmware driver chip (4mm away) another 100nF. I think decoupling should be OK.

Chip handling and treatment I think is OK. (is it ever ??) The circuit measures RH% also and that runs at 55 - 67 % (Rev-Ed RH% sensor) so ESD ? I don't think so. Also, BRAND NEW 28x1 as shipped, same thing happens.

BUT, running from Table it is OK, so I suspect some problem with EEPROM memory.

One for Manuka maybe ? The TWO 433MHz transceivers for the radio link part to PC is closeby both LCD board and Master board. But at 10mW ???

No heavy power cables close. Only 220V to desklamp (bulb) and PC (not really close). 28x1 fitted in a socket, no solder heat damage then.

The problem is resolved by moving text to TABLE, so it works OK, but only because the program length allows it. This might be a concern later if the program length increases.

Hope that is more clear.

 

[Dippy]

And obv you've tested it without the RF modules powered? (Clutching at straws).

A 12V reg on a 12V battery? That's 'unusual'.

I'm at a loss. I'll hand over to the experts.

 

[Jeremy Leach]

Well from the fact that after a download it always starts off ok - to me this says the EEPROM data is being corrupted and it's not anything to do with a dodgy display connection. As there are no Writes in your code at all, and no strange poke commands (?) then I'm stumped

I'll hand over to the experts too !

 

[manie]

Dippy, 12V reg on 12v battery is from early days learning, but IF YOU SHOULD connect to higher voltage (say 24V) like I could on a truck, then you're still OK ??

Jeremy, nothing fancy or "brave" in this program, just load the text at download time, then READ location to display menu text, no peek's, no poke's.

I remembered not so long ago a thread asking about a similar LCD problem, could not find it, but suspect it might have the same cause ??

Anyway, reading text from table, removed the sympton, the disease though has not been cured.......

Thanks for your input

 

[Jeremy Leach]

Is there ANY code between when you Read the byte and when you display it? i.e a possible source of corruption.

 

[hippy]

I agree it has some hallmarks of faulty Eeprom but the issue is whether that is actually the case, what is causing it and why, or what else is the problem. That you have a problem with a brand new 28X1 is intriguing because I have run long term tests on reading Eeprom repeatedly without problem ( downloaded and run at as low as 2.2V supply ). Thus, test the Eeprom, if that repeatedly reads the Eeprom correctly it suggests the problem is somewhere else.

I'm also intrigued by your PSU arrangement; why the BD244 bypass transistors, what sort of current are you drawing ? 7812's and 7805's should be good for 1 amp. It may not be a problem but when things unexpectedly misbehave anything out of the ordinary needs to be looked at.

I suggest running the following program and seeing if there are any errors in the timeframe you normally see such errors -

#Picaxe 28X1
#Terminal 4800

Eeprom 0,  ( "1 SETPOINTS " ) '0-11
Eeprom 12, ( "2 CURRENT   " ) '12-23
Eeprom 24, ( "3 ALARMS    " ) '24-35
Eeprom 36, ( "Enter 1/2/3:" ) '36-47

Table  0,  ( "1 SETPOINTS " ) '0-11
Table  12, ( "2 CURRENT   " ) '12-23
Table  24, ( "3 ALARMS    " ) '24-35
Table  36, ( "Enter 1/2/3:" ) '36-47

Do
  For b0 = 0 To 47
    Read      b0, b1
    ReadTable b0, b2
    If b1 <> b2 Then : SerTxd( " FAIL ", #b0, " " ) : End : End If
  Next
  SerTxd( "." )
Loop

If not, I'd then move on to updating your actual code to use Eeprom 0-47, and ReadTable 0-47. Whenever you read Eeprom, also read the Table and check the data is the same and report if not. If the data is the same yet you are still seeing corruption on your LCD then it's not Eeprom which is the problem.

If Eeprom is becoming corrupted then it will need further investigation.

 

[BeanieBots]

What about gosubs? Nesting depth? Possible missed return?
Does it happen when running or after a few power up & downs.

I'm very interested in this because I've seen it myself but have attributed it to noise as I know my circuit switches heavy inductive loads at high voltage.
It could well be your Tx modules.
Have you tried without them.

I know you've found a workaround but it would really benefit others (inc. myself) if you do some more tests and try to isolate the cause.
It must be quite a rare event because many others have used EEPROM for LCD menus and not reported any problems.

 

[Dippy]

Re RF: Thats what I asked in #9

It certainly would be nice to get to the bottom of this.
I know you have put a successful sticking plaster over the problem, but nailing it is handy.

Let me see if I have got(ten) the story-so-far.

1. You download programme and EEPROM data.
2. Your code only ever READs the EEPROM data.
3. After a few cycles of READing and displaying the data seems to get corrupted.
4. The fault is reproducible.
5. New downloads and the first few READs indicate the EEPROM appers to be OK.
6. But after a few more READs it goes bad again.
7. And it happens with another PICAXE too.

8. You do a similar thing at higher EEPROM addresses and all seems well.
- though you don't indicate whether this test lasted minutes or hours.

9. You do a similar thing with Table and everything is happy.

Circuit.
Plenty of decoupling.
Battery powered.
Have you 'scoped +v just in case of any funny oscillations?

But, RF modules close to processor board and, I assume, unscreened between antenna and PCB.
Testing any effects here should be quite easy - disconnect RF module power or comment-out the code if code does pwoer control.

Does this error occur after RF transmission?
Can you 'scope for any HF sparklies on the pins?

I've only ever had a similar problem with a BS2p when it was power cycled, but never with a PICAXE or PIC.

Getting a solution may be beneficial to others in the future and I'm sure would be appreciated.

 

[manie]

Dippy:
On your point 8... ran a few cycles (maybe 10-15x's) without problem. I then decided to move to Table. Since then, no proble.

Regarding RF and 'scoping, I have not checked at that depth yet (not with the 'scope now). I will check more detail as soon as I can and report...

The "other" RF module also sits right next to the 40x1, it depends on both EEPROM read and write, mostly read's, as the write's occur only if parameter change required in temperature settings etc. There appears to be no problem there as it performs fine. Does this maybe indicate 40x1=OK and 28x1 possible EEPROM problem ?

 

[hippy]

Does this maybe indicate 40x1=OK and 28x1 possible EEPROM problem ?

Without undertaking further tests and analysis it's not possible to say what the problems is. The two boards are not directly comparable no matter how superficially they may appear to be. If you can replace the 28X1 with a 40X1 that would be more comparable.

Before speculating any further it will be a good idea to to run the Eeprom tests suggested earlier.

 

[Dippy]

"Does this maybe indicate 40x1=OK and 28x1 possible EEPROM problem ?"
- bottom line: I don't know, but I'd be surprised.

I've never seen (on Forum) any issue like this before.
And I've only ever seen things like this happening associated with power-glitches and interference.
As I can't see, or fiddle with, your precise setup then we are in your hands as to testing.
We can suggest tests but basically you know the score.
Start simple and keep adding until the error happens.
You may suss it in 5 minutes or it could take hours.
You could have a Doh! or Eureka! moment.

My first step would be to 'scope it and disconnect RF module and see what happens.

But it would really be handy to nail it just so that, in future, you/we can keep it as info for others.

 

[Jeremy Leach]

I'd really like to see your code too - at least the bit that reads and displays

 

[inglewoodpete]

To determine if the probem is in the chip, I suggest you write a short add-on subroutine that sends the relevant part of the EEPROM to the PE terminal in ascii using SerTxds. With the code in a subroutine, you could put a few gosubs around the code to see if the EEPROM changes.

 

[manie]

As far as testing more, I'll do what I can, as said, I'm not with the scope now so thats a problem. As far as switching off RF goes, I'll try that. I'll also post the read and display code for your inspection. Thanks.
Edit:

Would the display go bonkers at precisely the same point/s(two places as shown) no matter when I interact with the menu (keypad action) ? That could happen anywhere within the 40x1 loop cycle where the data transmitting originates from. Data is transmitted in a regular loop/cycle as the 40x1 does its work (readtemp, readadc - RH%), send data to receiver/PC, start read again after xx Seconds pause. Interaction from keypad is to Hserout to 40x1 new parameter/s or request current data (via Hserin) for LCD display. Data sent/received (hardwire) is then verified as required with appropriate interrupts to/from both 28x1 and 40x1. During the period spent in the Interrupt Routine the 40x1 does NOT transmit via RF to the PC and the PC is also quiet then. Only the carrier (if present) could be there then.

 

[BeanieBots]

Manie,
It should be possible to do some of the more 'obvious' tests very easily.
Strong oppinion relates to the RF section being the culprit.
The 'test' is simple. Disconnect the RF module and see if the problem remains.
No need for a 'scope at this stage.

We don't have your code or circuit so it is impossible for any of us to comment on either. Hence, it is not possible to comment on any of your questions in your last post.

 

[Jeremy Leach]

And don't worry about code quality etc, it's obviously work in progress.

 

[Dippy]

Is there some kind of problem to test without RF?
If its all soldered into a high-density PCB can you comment-out the line which triggers the RF or powers the module?

(After all this heartache, you'll find it's the wife starting her washing machine that causes the error)

 

[BeanieBots]

(After all this heartache, you'll find it's the wife starting her washing machine that causes the error)

Or more likely, turning on the strip-light just before!

 

[Dippy]

Or those cheap CFLs bought from Ebay.

 

[hippy]

Just for information - I've been running the Eeprom/Table comparison test on a 28X1 for something like 12 hours or more, in an otherwise unused socket on an AXE091 board being powered on and off and even running a servo at times. No problems found.

Using the #No_Data directive it is possible to download a new program without altering what is held in Eeprom. So another test to try, run the program until corruption is seen, download a program which reports what's actually in the Eeprom. Just make sure that the #No_Data is specified !!!

#Picaxe28x1
#Terminal 4800
#No_Table
#No_Data

Pause 2000
Do
Read b0, b1
b0 = b0 + 1
SerTxd( b1 )
Loop until b1 = 0

 

[manie]

Or those cheap CFLs bought from Ebay.

Hahahaha ! Was waiting for something like that.... at least you're predictable Dippy !

BB,Hippy,Dippy, no problem to test without RF, just unplug the DB-9's and its powered off. Have been (very) busy a while so maybe test tomorrow morning, with the code as suggested by Hippy to read existing (old) data. I will test more as soon as I can and post my results, untill then at least the READTABLE has kept it clear and running.

Hippy, just one more thing, I'm running at 8MHz and 9600bd. But I'll test with the code both at 4MHz and 8MHz, maybe there is something ?? Will report back.
in the meantime here is the portion of code, from Init: down to Menu1: with the reads and serial outs to LCD driver firmware.

 

[Jeremy Leach]

Well I was more interested in the EEPROM code than the Table code , plus seeing your symbol declarations ... but I doubt it's code related anyway....

 

[manie]

Jeremy: The only diff. is that the word "EEPROM" was replaced by the word "TABLE". The rest of the code remained the same, the "TableText" sub routine had the same name as I started off by loading the table. Then wanting to save program space I switched to loading the EEPROM, nothing else changed except the behaviour of the offending characters in the display...

symbol Choice = b0		'b0 menu select var
symbol kbdin = b1			'b1-kboard char received
symbol Strokes = b2		'b2=key debounce counter
symbol temb1 = b3			'b3-general BYTE var
symbol temb2 = b4			'b4-general BYTE var
symbol ForNext = b5		'b5-general BYTE var
symbol Cntb1 = b6			'b6-gen counter
symbol dir1=b7
symbol dir2=b8
symbol dir3=b9
symbol DegC=b10
symbol DegAl=b11
symbol Rh=b12
symbol RhAl=b13
symbol charpos = b14		'b14-character position on line 1,2,3 or 4
symbol CharCnt = b15		'Character counter var
symbol MemVal= w8			'b16/b17-general WORD var
'b18
'b19
'b20
'b21
'b22
'b23
symbol temw1 = w12		'b24/b25-general WORD var
symbol temw2 = w13		'b26/b27-general WORD var

 

[Jeremy Leach]

Ok, thanks. Is Pause 5 enough after the serout at 8MHz, for your LCD?

 

[manie]

JL, yes, it seems to be quite happy with that, in fact, I thought of iether removing some pauses or reducing the time as it visually slows down the LCD.

 

[hippy]

If it is a program-caused corruption problem it would be desirable to see the full code. Though a change from Eeprom to Table seems to overcome the problem that may just be a chance correlation.

I'm particularly interested in the interrupt routine; whether that uses any temporary or other variables which are being used to communicate with the LCD. Also the LCD code is timing dependant ( eg, PAUSE 200 after clearing the screen ) and an interrupt may truncate that pause. If the interrupt is short you may return and continue writing to the display before it is actually ready for that.

At the moment it 'feels like Eeprom corruption' but there's no evidence to support that, so whether there is or isn't is to me the primary question to answer. If there is, then the next question is "why?", if not then it's a matter of finding what is causing the incorrect behaviour. Though a fault is not presently apparent using Table, it could be a problem which is still there but currently obscured or less frequently appearing, and could bite again at any time.

At least you have a repeatable fault condition using Eeprom which makes debugging far easier than an intermittent or random fault. Make sure you keep a copy of the source code which exhibits the problem in case a code change overcomes the bug and it cannot be reproduced in future. Otherwise we'll end up with nothing to compare against or study if we need to, and can only shrug our shoulders.

 

[manie]

Like you said, work in progress, could be made more elegant but works for now.

Edit:
When returning from "Sub2" is when the character corruption was first noticed.
I've included "SubSub1" where parameter changes are entered and the LCD cursor is moved around the screen for various entry choices. When "#"(enter) is pressed, you are returned to the "Menu1" where the corruption occured as described earlier.

'---------------------------------------------------

Sub2:		'request current data for display

kbdin=0
hserflag = 0
	gosub setlcd
	serout 7,T9600_8,(254,128,"Waiting for data")
	
	'then Hserout request for data code
	hserout 0,(68,1)		'the "0" means NO BREAK sent
	
	'interrupt Main here - put portc pin 5 low after +-50mS to prevent re-interrupt
	
	dir3=0
	do until dir3>0		'repeat until return interrupt received.
		high portc 4
		pause 50
		low portc 4
	loop
	
goto menu1
'return
'---------------------------------------------------------
SubSub1:		'get parameters etc., then send to master

	temb2=0
	memval=0		'use its bytes b20/b21
	temb1=0
	temw1=0
	do until temb1 =10					'until # pressed=enter
		do until temw1>490
			gosub readkey
		loop
		gosub idkey
		temw1=0
		temb1=255
		select case kbdin
			case 42			'bspace * pressed
				temb1 = 1
			case 0 to 9			'1 to 9 pressed
				temb1=2
			case 35			'#(enter) pressed
				temb1=10
		end select
		if temb1 =1 then
			if charpos>charcnt then
				dec charpos
				serout 7,T9600_8,(254,charpos," ")	'print space
			end if
			serout 7,T9600_8,(254,charpos)	'return to charpos
			temb1=0
			temb2=temb2-1 min 0
			serout 7,T9600_8,(254,13)	're-enter so flash cursor again
		end if
		if temb2<4 then			'allow 3char for batV: 122
			if temb1=2 then
				serout 7,T9600_8,(254,charpos,#kbdin)	'print character
				inc charpos					'now incr charpos	
				temb1=0
				inc temb2
				if temb2=1 then:b18=kbdin:end if
				if temb2=2 then:b19 = kbdin:end if
				if temb2=3 then:b20=kbdin:end if
			end if
		end if
	loop 'until temb1=10
	
	serout 7,T9600_8,(254,13)	'flash cursor again
	if temb2=1 then
		temb1=b18
	end if
	
	if temb2=2 then
		temb1=b18*10
		temb1=temb1+b19
	end if

	if temb2=3 then
		temb1=b18*100
		b18=b19*10
		temb1=temb1+b18+b20
	end if
	
dir2=temb1			'for resend in Interrupt Confirm Data	
dir3=0			'if dir3=1 then data received
'	sertxd("Value entered = ",#temb1,13,10)
'now Hserout to Main
if charcnt=199 then		'deg C setpoint
	temb2=12
	dir1=12
end if

if charcnt=208 then		'RH% setpoint
	temb2=14
	dir1=14
end if

if charcnt=154 then		'Period setpoint
	temb2=20
	dir1=20
end if

if charcnt=164 then		'BatV setpoint
	temb2=24
	dir1=24
end if

if charcnt=215 then		'Alarm Cancel
	temb2=88
	dir1=88
end if

	hserout 0,(temb2,temb1)		'send new settings,and interrupt if not Alarm Cancel
		do while dir3=0
			high portc 4			'a return interrupt will confirm 
						'when data received OK
			pause 50				'pause 25mS(8mhz)
			low portc 4
			sertxd("sending - ",#temb2," / ",#temb1)
		loop
'-----------------
'ON 40X1 MAIN
'int-out output pin 1
'int-in input pin 6
'hserin portC 7
'hserout portC 6
'-----------------
			
return

'-------------------------------------------------
Sub3:
'Not used yet

return


'---------------------------------------------------
'At BOTTOM of Program
'---------------------------------------------------

Interrupt:			'get latest data from Main

kbdin=0
charpos=0
pause 55		'wait 1/4 sec(8mhz) for pin to go low

'receive data into scratchpad address @ hserptr=100

'Below= what is sent.
'hserout 0,(Tsouth,Tnorth,Tout,Tset,RH,RHset,Period,BatV)	'current data received

'	do until hserptr=108		'wait untill 8 bytes received
'		pause 200
'		charpos=hserptr-100
'	loop


choice=100			'hserptr starting register
sertxd("ptr= ",#hserptr,"choice= ",#choice)
get choice,fornext	'code of what was sent, 1=view data/2=confirm data and/or resend..
inc choice			'increase to next ptr for actual data
select case fornext
	case 1		'view current data request		
		get choice,dir1	'Tsouth
		inc choice
		get choice,dir2	'Tnorth
		inc choice
		get choice,dir3	'Tout
		inc choice
		get choice,b18	'Tset
		inc choice
		get choice,b19	'Rh
		inc choice
		get choice,b20	'RHset
		inc choice
		get choice,b21	'Period - b24 from w12
		inc choice
		get choice,b22	'BatvSet
		
		gosub setlcd
	
		serout 7,T9600_8,(254,13)	'flash cursor ?
		gosub setlcd
		pause 1000
		
		serout 7,T9600_8,(254,128,"S: ",#dir1," N: ",#dir2," Out:",#dir3)
		'				   ---   --   ----   --   -----   --	18chars
		pause 30	
		serout 7,T9600_8,(254,192,"Tst:",#b18," RH: ",#b19)
		'				   ----   --   -----   --  			13chars
		pause 30	
		serout 7,T9600_8,(254,148,"RhSet: ",#b20," Per: ",#b21)
		'				   -------   --   ------   --  		17chars
		pause 30	
		serout 7,T9600_8,(254,212,"Bat V:",#b22,"  #= Menu")
		'				   ------   --   ---------		  	17chars
		pause 30
		
		pause 1000
		temw1=0
		dir3=1
		do until temw1>0 and temw1<510	'check for "#" pressed
			gosub readkey
			gosub idkey
			pause 20
		loop
		
		
	case 2		'confirm and/or resend new setpoints
		get choice,b18
		inc choice
		get choice,b19
		sertxd("rec: ",#b18,"  ",#b19)
		if b18=dir1 and b19=dir2 then
			dir3=1
		else
			dir3=0
		end if
		if b18=88 then
			setint %00100000 , %00100000	'interupt on input pin 5 high
			hserinflag = 0			'reset flag,shows data was read
			hserptr=100
			temw1=0		'set again for display purposes
			pause 20
			goto menu1
		end if
		
	case 13		'temp alarm
		gosub setlcd
		get choice,dir1
		serout 7,T9600_8,(254,128,"Temperature ALARM")
		serout 7,T9600_8,(254,192,#dir1," Deg.C !")
		serout 7,T9600_8,(254,212,"88 to CANCEL ")
		setint %00100000 , %00100000	'interupt on input pin 5 high
		hserinflag = 0			'reset flag,shows data was read
		hserptr=100
		temw1=0		'set again for display purposes
		serout 7,T9600_8,(254,215)
		pause 20
		charpos=215
		charcnt=charpos
		serout 7,T9600_8,(254,215)	'goto entry position
		gosub subsub1
		
	case 15		'RH alarm
		gosub setlcd
		get choice,dir1
		serout 7,T9600_8,(254,128,"Rel.Hum% ALARM")
		serout 7,T9600_8,(254,192,"RH%: ",#dir1)
		serout 7,T9600_8,(254,212,"88 to CANCEL ")
		setint %00100000 , %00100000	'interupt on input pin 5 high
		hserinflag = 0			'reset flag,shows data was read
		hserptr=100
		temw1=0		'set again for display purposes
		serout 7,T9600_8,(254,215)
		pause 20
		charpos=215
		charcnt=charpos
		serout 7,T9600_8,(254,215)	'goto entry position
		gosub subsub1
		
	case 25		'batv alarm
		gosub setlcd
		get choice,dir1
		serout 7,T9600_8,(254,128,"Bat Low ALARM")
		serout 7,T9600_8,(254,192,"Bat V: ",#dir1)
		serout 7,T9600_8,(254,212,"88 to CANCEL ")
		setint %00100000 , %00100000	'interupt on input pin 5 high
		hserinflag = 0			'reset flag,shows data was read
		hserptr=100
		temw1=0		'set again for display purposes
		serout 7,T9600_8,(254,215)
		pause 20
		charpos=215
		charcnt=charpos
		serout 7,T9600_8,(254,215)	'goto entry position
		gosub subsub1
	
		
end select
			
'if kbdin=35 then
	setint %00100000 , %00100000	'interupt on input pin 5 high
	hserinflag = 0			'reset flag,shows data was read
	hserptr=100
	temw1=0		'set again for display purposes
'end if
	
return

 

[hippy]

The interrupt alters 'charpos', 'fornext', 'charcnt', tempb1' and 'tempb2' ... all of which are critical to the LCD display section. So if there's an interrupt while that code is executing when you return from interrupt what happens next is largely unpredictable.

I have to admit that I can't really follow the code, and I doubt it would help if you posted all of it, though all of it would be better than just chunks at a time.

 

[manie]

No problem: the code is attached. General flow is:

Init-->menu1(main choices), which=clearscreen,read text data and display at positions
-- 1 -->Settings-->sub1,(which displays setting choices at positions)--->subsub1(gets actual values{at those specific screen positions} for Hserout)-->Hserout(code/value)-->Interrupt(to get 40x1 to react to codes/values) <<<---(from 40x1) Hserin(code/value confirm)<<---with interrupt(to get 28x1 to react).

This is the general way/method I use throughout. I do not envy you SHOULD you want to follow the code all the way. ((( you might not like what you find embedded in my mind....har,har)))

 

[manie]

EEPROM "failure" is back. This time in the 40x1, and only seen in data stored in register 0(zero).
I store temperature "preset" lookup values (an other values) starting at position 0 up to position 15. These get loaded/overwritten with each download which happens quite a few times (maybe 100 downloads so far). New setpoints can be transmitted (Hserin) to overwrite the preset loaded data whenever a change in setpoint is required. This happens infrequently (manual input) and during testing etc. was done maybe 50-100 times.
This morning I noticed that the data from EEPROM 0 was incorrect, even after a download. I changed the register position to 40 and now its fine ! Another problem ?

Incidentally, NO rf signal was present as transmitters were disconnected. Any ideas ?

EDIT:
Although only seen this morning, this might have been going on for a while already, as I had problems to get the program to respond correctly. Only when I started REALLY digging for the cause of the incorrect behaviour, did I notice that the register 0 data was incorrect. Example data:
Store something like 23(deg C), when it is read into ariable the value will show 243..... but as said, after moving it down to register 40, it is fine...

 

[hippy]

This morning I noticed that the data from EEPROM 0 was incorrect, even after a download.

Immediately after a download or some time later ?

If immediately it sounds like your PICAXE Data Eeprom has worn out, if later it could be the same corruption as before.

If there were a systemic problem I'd have thought we'd have heard more complaints about it and prolonged testing has not revealed any corruption occuring in Eeprom.

 

[Technical]

Your full program in post 36 is full of write commands, something I don't think you mentioned before!

e.g.

write b20, 4

This WILL corrupt the eeprom data memory - at whetever address happens to be in b20 at that time!

 

[manie]

Tech: Yes I do write to EEPROM registers, but these writes are deliberate and serves only to store setpoints and other parameters required. I do a "write" in order to maintain data in the event of power failure (unlikely, as the board runs off 12V 50AH battery). I have installed a new 40x1 chip today, I will move data back to original position (from 0 onwards) for tomorrow and test again, as I will not be downloading and overwriting as much as during development and testing.

This WILL corrupt the eeprom data memory - at whetever address happens to be in b20 at that time!

Why will a legal write command corrupt anything ? Possibly during extended testing but surely not with approx. 100-200 times written to ? In a previous thread somewhere it is mentioned that EEPROM data should last 1 million write cycles(or thereabouts..). Maybe this coincidence and if we ever find out what/why went wrong I'll be glad.

Anyway, lets see tommorow how the new chip fares with just a few writes on the clock.

The code running in the 40x1 contains more write commands than the code in the above attachment, but as I said, these writes are deliberate to store data for later retrieval and to be available even after power down.