Serin erroneous behavior in 08/08M

[bbas]

Hi all,
I just wrote a program for a serial stepper controller. The software worked fine as it was receiving commands from the terminal and executing the steps.
the serin command used was:

serin 5,N2400,("stp1"),b7,b8,b9

As I developed the C# software the controller started losing some commands and I ended up with the following situation having erroneous behavior in a simple program with just one serin command:
If I just wait for the "s" the code works fine which means that the serial subsystem works ok as it parses all bytes send to the serial from the PC and recognises the "s".

serin 5,N2400,("s")

When I give the following command I get garbage received back to the PC even though serin is the only code line in the program:

serin 5,N2400,("s"),b1

garbage in Hyperterminal is :
"œœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœœ<"
and it is similar in all com softwares.

This happens in 2 axe-08 and 1 axe-08M I have here and in 2 different motor driver boards.

The usb to rs-232 is the Prolific but I doubt it may cause the problem but I also do not have a clue about the problem.

Actually when serin has to put a value in the register PIC is outputing at port 5. I am wondering if this is kind of a debug function but I really cannot understand how this happens in 3 different micros with a new 1 codeline program.

Has anyone seen this before?
Thanks in advance.

 

[BeanieBots]

Did you mean
serin 5,N2400,("s"),b1

or
serout 5,N2400,("s"),b1

try
serout 5,N2400,("s"),#b1
and all the obvious checks for baud rates etc.

 

[bbas]

I appreciate for your reply.
No, not serout, serin is doing it (!!!) and it is doing it when it has to get a value in a register:

serin 5,N2400,b1         ' it is doing it
serin 5,N2400,("s"),b1  ' it is doing it
serin 5,N2400,("s")      ' is OK

the following is OK

start:
serin 5,N2400,("s") 
serout 0,N2400,("OK") 'returns OK after "s" is sent
goto start

the following is just sending garbage and not the OK.

start:
serin 5,N2400,("s") , b1
serout 0,N2400,("OK") 'returns only garbage after "s" is sent
goto start

Also another strange behavior was that in the "transition" phase, just after everything worked OK (or seemed to), while the picaxe was controlling the stepper (a continuous nested for ... next loop with pins) any character send to the serial was interrupting the loops. I cannot figure out what happened becouse programmatically it should just continue the loop and then go back to start for the next serin. No setint was used.

I have checked out voltages just in case serial traffic or 232 levels are low or causing some kind of reset but I cannot explain the garbage.

 

[bbas]

It seems that it has to do with the in chip program downloader as the serin port is also the download port. This was propably causing the for.. next loops interupts.
The garbage probably is the acknowledge sent back to the system.
But I cannot figure out why the part of the serin code that parses for the expected chars works and it crashes and responds with an acknoledgement when it has to pass the chars into the variable.
Does anyone know the program loading hadshaking and negotiation sequence?

 

[inglewoodpete]

bbas, something does seem right to me.

The thread heading says you are using a PICAXE 08 (or 08M) Which one?

You are using the command (or a variant of it):

serin 5,N2400,("s") , b1

Pin 5? There is no pin 5 on an 08/08M

 

[manuka]

Well spotted- another victory for Frustra fit per plura quod potest fieri per pauciora [It is futile to do with more things that which can be done with fewer]. (Occam's Razor)

 

[BeanieBots]

Not just a non-existent pin assignment but also sending "data" to the "serin" (the download input) and not a serial in pin.
That would cause all sorts of erratic behaviour.

 

[SilentScreamer]

Just to add, you have to look in "Manual 1" (look at the PICAXE manual's at the top of this page) and look at the pinout diagram. By pin 5 i expect you actually mean Input 2 so use:

serin 2,N2400,("s")

 

[bbas]

Hi All thanks for your replies.
I don't know how I got into this but something very good finally got out .

Let's see:

• It is supposed that you cannot use the download port for serin.
• On Picaxe 08 serin 5,N2400... reads the download pin
• Obviously if you send something to the port the downloader replies on port 0
• BUT !! If you wait for a specific string the downloader is set aside (you cannot download a program while serin 5,N2400,("something") )
• This is very suitable if you want to send a command to start a process
• BUT ALSO ! If you want to pass variables after the command string you get bootloader replies and reset IF the expected string is less than 4 chars !!!!!
• Which means serin 5,N2400,("1234"),b1 works fineover the download cable (replace "1234" with any string with a length over 4 chars...
• Drawbacks: You cannot download a program while in serin ( you have to reset). If you send commands while not in serin you enable the bootloader and reset the pic.

I 'll do some more experimentation and get back after extended testing.

 

[BeanieBots]

Well 10/10 for "knowing" something wouldn't work but trying it anyway.
I guess you just didn't believe the manual.

Anyway, you have made an interesting discovery.
They will not reveal the download protocol but hopefully they might give some insights based on your discovery on how to utilise serin as an actual input for serial use.

 

[bbas]

I really do not know why I used port 5. I was searching for the pins on the net and used it very naturally ( I didn't even think about bootloader conflict. I thought that method was supported)
Anyway everything was moving fine while the command word was "stepper1".
Until I changed it to "stp" !!!
The first suspect was c#, then the pc, the cable, the specific picaxe, the specific board ......
It seems that in order to do the parsing for the string the bootloader is disabled.
There may be also problems if the expected string gets to long.

Anyway there are always two basic questions to ask "Why and Why Not!" ?&&!?

 

[hippy]

Pin 5 is the download serial in so that is the cause of the problems - the only supported mechanism for reading serial in via the download port is by using the SERRXD command ( not available for the 08/08M ).

While SERIN on pin 5 appears to work in some circumstances it is not recommended as it is still possible to inadvertently cause a download reset if data is sent while not executing the SERIN and behaviour could be power supply and temperature sensitive. As the internal oscillator changes frequency the chip's behaviour may differ and it may work one day and not the next, it may work with some PC's but not others. Operation is not guaranteed for future firmware versions.

I don't understand why behaviour should differ depending on number of qualifier bytes but this may point to other issues not identified such as operation being position dependent, put the same SERIN 5 somewhere else in the code and it may not work there.

Non-existent and invalid pin numbers should not be used in any command as behaviour in such cases is not defined.

 

[bbas]

Hi Hippy I agree it is not a supported method and cannot depend on it for anyhting more than hobby and education.

inadvertently cause a download reset if data is sent while not executing the SERIN and behaviour could be power supply and temperature sensitive

I agree that you will enable the bootloader if you send data while not in serin but what do you mean by power and temperature sensitive? I don't think that it is more sensitive than a serin command on another port.

As the internal oscillator changes frequency the chip's behaviour may differ and it may work one day and not the next

Again I thing that there is no more sensitivity than a serin in another port. It seems that pin 2 (GP5 in 12F629) could be treated as the rest of the ports 0-4 (GP0-GP4 in 12F629).
Obviously there is the bootloader process polling port GP5 for input.
It seems that the parser of serin that is polling the port for data is either faster or has a higher priority than the bootloader routine or works one layer below it.
I have a script "torturing" the port for more than 3 hours and it seems stable.
Again it seems highly unlikely that it won't work another day.
If anyone has more info or expertise on downloaders he might be of help here.

Operation is not guaranteed for future firmware versions.

I suggest that in future versions this feature should be supported and enhanced and not shut off.
All the Best

 

[bbas]

Back again after testing.
The trick works for sure on picaxe08 firmware version 4.3.
08M behaves erratically and needs further investigation.

 

[hippy]

It may be power supply or temperature sensitive as those affect the internal oscillator speed, the oscillator speed affects how the PICAXE 'perceives time'. It is relativity so a signal of 1000us duration may be seen as being 999us or 1001us when the PICAXE is running slow or fast respectively.

It may be that SERIN 5 behaviour is timing sensitive which would explain why different sized qualifiers give a different result. While such timing issues will not adversely affect the PICAXE using other SERIN commands, because pin 5 is used for download it may be that some timings cause a download reset while others do not.

Likewise different PC's may have slightly different timings for transmission and each may also vary over time.