40x2 Serial data corruption

klauze

New Member
Hello,
I am designing a circuit based around the Picaxe 40X2 and am running into a bit of trouble processing the serial data.
My application will require a lot of back and forth serial communication. For now, I'm using the programming serial interface, but planning to switch to the hardware port for background receive in the future.
The board is powered from a computer ATX PS which has a nice, smooth 5.02 V output. There is a 100uF capacitor ,followed by a 100nf closer to picaxe (decoupling) to help things along. The reset pin is tied high via a 4k7 resistor (though , in my experience, leaving it floating was never an issue). There is a 16Mhz crystal linked on the resonator pins and grounded by means of two 22pf capacitors. Apparently, resonators have gone extinct where I live :)
I'm using the AXE027 cable without any alterations and the 22k , 10k download circuit as described in the manual.
Basically, the software is a serial loop-back with only a handful of code lines. It a nutshell it looks something like this:
Setfreq em64
pause 500
disconnect

main:
serrxd b1,b2,b3
if b1=97 then gosub ssave
sertxd (b1,b2,b3)
goto main

ssave:
reconnect
goto save

On the computer side of things, I've written a short program in VB.NET that generates 3 random bytes, making sure the first one is not 97, then sends them over the serial port at 76800 bps. byte 97 is my escape byte, so I don't have to hardware reset the picaxe for downloading a new program. It then loops until the receive buffer has received 3 bytes and compares them to what has been sent. If they are the same it increments HIT , otherwise it increments MISS.
The hit and miss counters basically act as loop-back success or error counters.
My problem: Sometimes I count hundreds of hits without any miss and other I barely get to 100.
So far, I've tried the following:
-replace crystal with 8Mhz crystal + readjust serials speeds = NOK
-Used internal resonator (setfreq m8)+ readjust serials speeds = NOK
-Use fresh 3 x AA batteries as power supply = NOK
-Tried Calibreq ...over the whole range = NOK
-Tried putting a pause in between receive and send. Pause 5 -> 50 . Except for getting slower = NOK

By Not OK, I mean same erratic behavior. At times, one serial error in hundreds, while other bundles of errors.
The cable itself is fine, I believe. I'm using the same one to program my scrolling LED display, which also sends tons of data and works fine.
The finished prototype should work something of the sorts: get some serial data, CRC Check, PINSX = serial data , read some ADCs and send them back to the host + acknowledge CRC OK - or CRC Fail and resent from gcode line number(hint, wink,wink). Should any schematics, source code ,etc be required, I will gladly upload as soon as I get home.
If this type of behavior considered normal over fast serial communication or am I missing something here ? I was planning on going full throttle on the baudrate, but meanwhile I'm hung on this
Any help from the community is much appreciated.


Cheers,
Claudiu
 

hippy

Technical Support
Staff member
Welcome to the PICAXE forum.

What you have should be working okay but there are few things to watch for which might be causing the NOK results -

1) Sending data back to back to the PICAXE too fast can lead to corrupt data being received by the PICAXE. It may be necessary for the VB code to add some sort of delay between sending bytes rather than simply sending them all at a time. Another trick can be to use two stop bits instead of one which should not adversely affect received data from the PICAXE.

2) similar to the above, you need to ensure time for the PICAXE to have got back to SERRXD after its SERTXD to be ready for what the VB sends next.

3) Synchronisation. If the PICAXE gets out of kilter with the packets being sent it may take one or two from the first packet and one or two from the next and the three bytes returned may not match either. It is also possible that a 97 other than as a first byte in the data causes a reconnect and subsequent issues. As described though it would seem your VB would hang if it hadn't got three bytes back so it would appear that isn't happening.

It might be worth analysing what the packets are which come back but don't match as that may give some additional clues as to what is going wrong. It might also be worth using increment values rather than purely random values to help in that.
 

klauze

New Member
Thanks, Hippy.
I did the debug bit on the VB side of things. It looks completely random, except that each time a receive error occurs, the first byte is right, but the next two aren't . Also, about 99% of the time the last byte is 255, but not always.Untitled.png
In the image, the multiline texboxes are , left to right : send , received . Please ignore the rest - it's gibberish. I'm not doing any GUI until I have some serious progress :)
I have tried running the AXE at 16Mhz using the internal PLL and it still fails. Admittedly, after a higher hit rate, but fails nonetheless. So I'm not looking into the resonator as a fault cause anymore.
Worth saying, on PICAXE the code now is a simple echo machine:
setfreq m8
pause 500
main:
serrxd b3,b4,b5
pause 10
sertxd (b3,b4,b5)
goto main

However, running at 8Mhz = 9600bps renders good results. I left it running for about 10 minute, it got thousands of hits and zero misses . Intriguing ...
My aim is to run on the hardware serial port at 250000 baud as I'm trying to develope a 3D Printer. Yes, most of the g-code processing will be made by the PC
whereas picaxe will be more of a serial to parallel interface driving L293D H-bridge drivers for stepper motor control. I remember reading on the forum that Picaxe makes a slow stepper driver. I beg to differ .
It can actually run faster than the motor can step. At 64 MHz it can easily do half stepping as well. My only remaining issue is with the high speed serial data transfer. I don't want the printer to wait too long until the serial data is received - it will result in blobs of plastic being deposited. I wish picaxe to background receive data whilst carrying on with the motors steps, effectively running from a buffer. The speed will be intrinsic adjusted to prevent buffer under-run - analog to old DVD-RW .
Due to a lack in planing, my board needs redoing and currently can only accept data via the programming serial port. I am ,however, reluctant in investing further due to the unreliable results I am getting with the serial port. Are there any known issues with picaxe running fast serial data on the programming port ? Should I expect things to change if I should use the hardware port ?
In response to the points you've raised. VB waits for 3 bytes to be received from picaxe before sending a new package. I have even added a 100ms delay before sending data in VB to no avail. (just to make sure PICAXE is not napping a lot between sending and receiving)
Picaxe can't get bytes from different packs as VB won't send another pack until 3 bytes are received. If it only catches 2 bytes, let's say, it will hang forever in SERRXD as you've already noted.
As a precaution I've removed the check if b1=97 routing all-together. I can't configure the stopbits for the default programming serial port, can't I ?
All evidence thus far, point to hardware failure at high speed. I sincerely wish to be proven wrong :) as I got my hopes up for this project.
CAM02486.jpg
 

hippy

Technical Support
Staff member
It could be hardware related. The 22K/10K is not a MAX232 interface and while more than good enough in most cases capacitance and/or noise may be interfering at such high baud rates.
 

klauze

New Member
Hello again,

I seem to have it figured out and thought to take the time to point a few things I've learned while struggling with this problem.
-The SerialIn / SerialOut pins are good for programming and debugging, but that's about it
-High speed serial communication can easily be achieved by using the HSERIN HSEROUT pins
-AXE027 Cable driver uses FTDI which has a pre-programmed latency of 16ms. Contrary to what's stated on the picaxe site, it works just fine set to 1ms.
-Having this 1ms constraint, there's not much use to select ridiculously high baud rates (ie 921600 bps) , though the mighty 40X2 seems to cope just fine as ~112KBps (Hooray !)
-Never twist your serial data wires and don't run them parallel to high power lines , speakers or any other major interference generators
-For electrically noisy environments use MAX232 or equivalent as it has a high noise immunity threshold (3v) due to the use of higher voltages (don't use MAX232 on AXE027 ) - AXE027 uses TTL voltages (5v)
-Shielding, shielding, shielding. Oh, never ground your shields, it's just silly . Seriously, even Faraday would agree.
-Jack connector = jack s*** . Poor contacts , prone to shorting while inserting , subjected to interference ,etc,etc. Not adequate for data transmissions. I wasn't shy using the scissor, if you get my drift :)

During the time it took to write the above, I left my VB app running . This was the result:
gnews.png
P.S. It's running at 921600 bps and has sent a million and a half packages without missing a beat. :eek:
Thanks for your support and keep up the good work,
Claudiu
 
Top