Is 5.2.3 available somewhere?

ArnieW

Senior Member
A question for technical - is it possible to download PE 5.2.3 to test a possible bug in 5.2.4?

I just upgraded my main machine and primary laptop to 5.2.4. I downloaded some new code on my 28X1 chip and it seems to go into a reset loop. I downloaded some known good code and the reset still happens. (It shows my startup screen, goes into a temperature monitoring screen and then resets with the startup screen showing again).

I have an ancient laptop that I use for emergencies and it has 5.2.0 on it. I downloaded some known good code (not the same code as above unfortunately) and all is good.

I'd like to go back to my last known working point to repeat the test, and that means using 5.2.3.

thanks.
 

Technical

Technical Support
Staff member
The only known 5.2.4 bug is with the owin/owout commands - have you used them in your program?

If so download the attached file, rename from .txt back to .exe and the copy over the file with the same name in the /Programming editor/compiler folder.
 

Attachments

ArnieW

Senior Member
The only known 5.2.4 bug is with the owin/owout commands - have you used them in your program?

If so download the attached file, rename from .txt back to .exe and the copy over the file with the same name in the /Programming editor/compiler folder.
Hi Technical,

the program does use owin/owout so I installed the patch as described. The picaxe no longer seems to reset, but rather now seems to freeze up. For the moment all I can tell you is that the code goes into a regular timed loop using one wire to read temperature probes. I don't get any temperatures written to the LCD, but instead I get the clock time from the LCD module (there is no DS1307 so it shows zeros for both time and date) and then the module is unresponsive.

I am using one wire for DS18B20s so that during the read time the code does other things like check for button inputs. I have no response from buttons with this bug.

This is code that was known to be working under 5.2.3.

The only other variable I can think of is that the last code download under 5.2.3 was from a different laptop that is no longer working. All seems to download ok on the new machine.

thanks, Arnie
 
Last edited:

papaof2

Senior Member
I have a copy of the 5.2.3 installer (30MB). I can put it on one of my servers for a limited time and give you access to it.

John
 

hippy

Ex-Staff (retired)
I don't get any temperatures written to the LCD, but instead I get the clock time from the LCD module (there is no DS1307 so it shows zeros for both time and date) and then the module is unresponsive.
Without the DS1307, I2C reads timeout and cause a reset, then a program restart. Add a SERTXD at the start of your program to see if that is happening ...

#Picaxe 28X1
SerTxd("RESET")
I2cSlave $A0,i2cslow,i2cbyte
I2cRead 0,(b0)
Do:Loop
 

Technical

Technical Support
Staff member
I'm using PE 5.2.4 with 28X2 B.0
I've NOT (knowingly) experienced any issues using owin/owout.
BB - the issue was with the 28X1 not the 28X2. X2 will always work fine with owin/owout, X1 will need the file from the earlier post.

Any i2c read/write command that attempts to communicate with a missing chip will cause the PICAXE chip to reset after 2.1 seconds of no i2c response.
 

ArnieW

Senior Member
Without the DS1307, I2C reads timeout and cause a reset, then a program restart. Add a SERTXD at the start of your program to see if that is happening ...

#Picaxe 28X1
SerTxd("RESET")
I2cSlave $A0,i2cslow,i2cbyte
I2cRead 0,(b0)
Do:Loop
Hippy and Technical,

I am not using any I2C commands. The comment about the DS1307 was simply to say I'm not using it. The 'zero' time and date that appears on the screen is a symptom of the fault. It should not be there! I am using the LCD using serout commands only.

My old laptop is running 5.2.0 and I have downloaded code that works fine. If I download the same code using 5.2.4 it goes through a reset cycle as initially described. When I add technical's patch it no longer resets but displays the 'zero' time and date and from that point is not cycling through the main loop as I no longer have responses from my buttons.
 

BeanieBots

Moderator
If the data from the owin command is 'faulty', it is possible that you are sending 'strange' command codes (as apposed to data) to the LCD.

Try replacing the results of the owin commands with hard-coded valid values and see if it cures the LCD problems. (maybe also rem out the owin/out commands)
 

ArnieW

Senior Member
I've finally found a little more time to try and work through this issue.

The previous known working point was on my now dead laptop using 5.2.2 with a workaround suggested by hippy here: http://www.picaxeforum.co.uk/showthread.php?p=90028#post90028

On my current (replacement) laptop, I have been able to get 'back' to this point by reinstalling 5.2.2 and the workaround mentioned.

I installed 5.2.3 and I had similar problems as mentioned at the start of this post. Is it possibly an issue of early 28x1 firmware and the one wire command?

I'll now try the current version and try to narrow down the source of the problem.
 

hippy

Ex-Staff (retired)
Does the 5.2.2 configuration now work ?

It is possible that this issue is related to firmware A.0 and the version on the compiler used. I'm not sure off-hand what the OWIN/OWOUT issue was with 5.2.4, but it could be that it requires an upgraded picaxe28X1_0.exe compiler.
 

ArnieW

Senior Member
Does the 5.2.2 configuration now work ?

It is possible that this issue is related to firmware A.0 and the version on the compiler used. I'm not sure off-hand what the OWIN/OWOUT issue was with 5.2.4, but it could be that it requires an upgraded picaxe28X1_0.exe compiler.
Yes, it works with 5.2.2 with the added workaround that you suggested hippy.
 

kewakl

Senior Member
@hippy, arniew
thank you for the (.txt) file. it seems to have solved my owout resetting 28x1 problem

kewakl
 

ArnieW

Senior Member
I'm not really any closer to resolving this one. I haven't had the time recently to do systematic tests but it would appear to be more than simply the one wire command. I will attempt to provide something meaningful that others can test soon.
 

BeanieBots

Moderator
As mentioned earlier, it shouldn't be hard to eliminate the one wire commands from the equation. Simply REM them out and replace with a LET statement.
 

ArnieW

Senior Member
As mentioned earlier, it shouldn't be hard to eliminate the one wire commands from the equation. Simply REM them out and replace with a LET statement.
I've done that BeanieBots - the result did not make much sense and I ran out of time. The picaxe in question is also in a fixed location deep in my garage which is icy at this time of year.

To test it, I ended up with a most basic main loop doing a readadc. If the adc was lower than 250 it would trigger a decoding subroutine (it is a resistive ladder with push buttons - ie. sea of keys). This most simple of things failed. I wondered if it was a problem with the gosub so I eliminated this and then I had an output connected to an SSR that appeared to trigger randomly - there was no code correlation that I could make out.

This is with the system working as expected on 5.2.2. It is also with one of the first batch of 28X1s. All my other picaxes work ok on 5.2.4.

I will start with a clean slate and try to figure out a pattern. From there I will post something more useful.
 

BeanieBots

Moderator
It would also be worthwhile eliminating the environment.
You mention SSR. I guess switching mains?
Eliminate that as a potential source of corrupting noise.
Also, "icy". Condensation may have built up causing 'erratic' behaviour.

I had one of the very early 28X1s.
The one wire commands worked fine for me but it's always possible that a combination of commands may behave differently.
Keep us posted of any findings you make.
 
Top