serout to PuTTY causes reset

S

srnet

Senior Member
The PE syntax check should detect problems such as this;

serout TX, baud, ("Runmins,",runmins,CR,LF)

In this case the intention was to print out on the terminal from an 28X2 the value of the word variable runmins, and I missed out the #.

No big deal, and my error, but the omission of the # caused the PICAXE to crash, in that it reset itself and started the main program again. Not every time mind, maybe once in every 2 - 5 runs of that bit of code.

Or is that behavior a known 'feature' ?
 
Buzby

Buzby

Senior Member
PE could not detect a missing #, because # is optional.

But your problem is interesting, which firmware version has your 28X2 got ?
 
hippy

hippy

Ex-Staff (retired)
srnet said:
the omission of the # caused the PICAXE to crash, in that it reset itself and started the main program again. Not every time mind, maybe once in every 2 - 5 runs of that bit of code.?
Click to expand...
There's no way that should be resetting the PICAXE; all it should do is send a byte value out the pin and then continue, Any reset and program restart would seem to be coincidental, due to some other cause.

The command is entirely valid, the right command for the job in the right circumstances, so there's no error as such for the compiler to catch.
 
Buzby

Buzby

Senior Member
Just tried it on my 28X2 ( Ver B.2 )

Code: 
#picaxe 28X2


symbol runmins = b0


do

 serout c.4, T9600_8, ("Runmins,",runmins,CR,LF)

inc runmins

loop until runmins = 0

sertxd ( "Happy Bunny ", cr, lf )
Works fine !
 
Buzby

Buzby

Senior Member
It prints the text 'Runmins," repeatedly, but I've not left it long enough to see what happens at 65535 !.
 
S

srnet

Senior Member
Guys, this aint coincidental. I write my programs with considerable logging, both to see what is happening and to identify problems.

I have attached two logs, the first (170658) is with a section of code like this;

serout TX, baud, ("Runmins,",runmins,CR,LF) 'does this crash PICAXE ?
'serout TX, baud, ("Runmins,",#runmins,CR,LF)

And the second log (185409) is with the same section of code looking like this (NO other changes at all apart form the placing of the ' )

'serout TX, baud, ("Runmins,",runmins,CR,LF) 'does this crash PICAXE ?
serout TX, baud, ("Runmins,",#runmins,CR,LF)


And 'runmins' is a word variable that is a results of a sum from the GPS current time and the time saved when the GPS homefix was aquired,.

When the PICAXE resets it prints this line;

'PICAXE Pongsat - Stuart Robinson - V1 141012'

Notice that in the first log this line appears every few minutes, at exactly the point when the serout command executes. This is the PICAXE resetting.

The second log is with the # in place, it ran as expected for around 3 hours.
 

Attachments

Buzby

Buzby

Senior Member
nick12ab said:
It's not going to get there because you used a byte variable.
Click to expand...

Code: 
#picaxe 28X2
#no_table
#no_data

symbol runmins = w0


pause 4000 ' Give time for PE terminal to open

sertxd ( "Starting ", cr, lf )
do

  serout c.4, T9600_8, ("Runmins,",runmins,CR,LF)

inc runmins


w1 = runmins // 1000

if w1 = 0 then
  sertxd ( "Count = ",#Runmins, cr, lf )
endif


loop until runmins = 0

sertxd ( "Happy Bunny ", cr, lf )
Running now, up to 10,000 as we count !
 
Buzby

Buzby

Senior Member
35,000 !

Stuart, are you using a byte or a word for runmins ?

EDIT : Re-read first post, you are using a word.

Can you give us a bit more code to work on ?

49,000 !

2nd EDIT : What sort of value has runmins got ?.
I can limit my loop to try to pin the problem down.

54,000 !
 
Buzby

Buzby

Senior Member
65,000
Happy Bunny.

If this is a bug in the firmware we will need a lot more than just one line of symbolic code to find the cause.

What firmware version are you using ?
 
S

srnet

Senior Member
That bit of code is the one that causes the problem, however I wonder if the terminal program (Putty) is seeing a non-ascii character and pulling the serin line high and initiating the reset ?

The code incidentally is over 3 slots .........
 
Technical

Technical

Technical Support
Staff member
srnet said:
Notice that in the first log this line appears every few minutes, at exactly the point when the serout command executes. This is the PICAXE resetting.
Click to expand...
Without the # you will be sending ascii codes 0-31, which contains some weird and wonderful control codes.

Our guess is you are sending an ascii 5, ENQ - enquiry control code, that probably results in a reply from the terminal application you are using. This sends serial data to the PICAXE serin pin, which causes it to enter download mode, it then realises it is not a valid download, and then resets.

The byte/word argument doesn't really matter - serial is only a byte protocol so only the lower byte of the word is sent anyway.

Edit - posts crossed - but here is your PuTTY answer:

4.3.7 ‘Answerback to ^E’

This option controls what PuTTY will send back to the server if the server sends it the ^E enquiry character. Normally it just sends the string ‘PuTTY’.
If you accidentally write the contents of a binary file to your terminal, you will probably find that it contains more than one ^E character, and as a result your next command line will probably read ‘PuTTYPuTTYPuTTY...’ as if you had typed the answerback string multiple times at the keyboard. If you set the answerback string to be empty, this problem should go away, but doing so might cause other problems.
Note that this is not the feature of PuTTY which the server will typically use to determine your terminal type. That feature is the ‘Terminal-type string’ in the Connection panel; see section 4.14.3 for details.
You can include control characters in the answerback string using ^C notation. (Use ^~ to get a literal ^.)
Click to expand...
 
Buzby

Buzby

Senior Member
Looking at your logs, the only time the crash occurs is when 'runmins,' is followed by chr 05

From the web somewhere :
ENQ
- Hex 05
- ENQuiry
- A communication control (CC) character used to request a response
from another station. In Stop-and-Wait ARQ, the station receiving
the ENQ would respond with a retransmission of the previous data
block.
Click to expand...
 
Buzby

Buzby

Senior Member
But wait - PICAXE will only reset if it sees stuff on serin, not any other pin.

What pin are you using ?

I told you, we need more details.
 
Buzby

Buzby

Senior Member
I did read post #302, it was written while I was writing post #303.

But srnet has not said which pin he is using.

PICAXE will only suffer if it sees stuff on serin, not any other pin.

So which pin is Stuart using ?
 
S

srnet

Senior Member
Whilst I am using serout commands, it is to the standard programming port (a.4 on a 28x2)

Yes, I could use sertxd commands, but using serout commands makes it a lot easier to change the processor running frequency and keep the serial output at a standard 9600baud. One slot runs at 8mhz, one at 16mhz and the third at 64mhz.
 
Buzby

Buzby

Senior Member
Hi Stuart,

Did you get to the bottom of this ?

I'm fairly certain it's the 'too clever by half' puTTY that's giving you the problem.

What happens if you use a 'dumb' terminal, like PE's or Hyperterm ?

Cheers,

Buzby
 
S

srnet

Senior Member
For now I have assumed its the problem, it does not seem to occur when using the PE terminal.

Glad I posted I suspected Putty, just before Technical suggested the same thing.
 
hippy

hippy

Ex-Staff (retired)
If it is Putty ( which sounds likely), putting a DISCONNECT at the start of the code will stop anything sent to the PICAXE causing any reset. You'll have to Hard Reset ( power-cycle or press the reset button ) on the 28X2 to download a new program.
 
You must log in or register to reply here.
Top