SERRXD problem

[greencardigan]

Hi,

I'm having a serial communications problems with a picaxe 28x2-5v and the serrxd command.

I have some code running in the http://processing.org/ environment which sends a serial command to my picaxe using a usb/serial programming cable and the programming pin. 9600 baud.

When this Processing code runs

comport.write( "RESET\n" );

the picaxe receives these values, 82 81 170 20 165 (5 bytes) instead of 82 69 83 69 84 10 (6 bytes).

However, when I run this code, the picaxe receives the correct values.

comport.write("R");
delay(1);
comport.write("E");
delay(1);  // 1 ms delay
comport.write("S");
delay(1);
comport.write("E");
delay(1);
comport.write("T"); 
delay(1);
comport.write(10);

Any ideas?

 

[hippy]

It would help to see your PICAXE receiving code. My guess is that the comport.write sends all bytes back-to-back, or with short gaps between them, and the PICAXE isn't being fast enough to receive them.

The easiest solution would seem to be to replace comport.write with comport.writepicaxe and then write that comport.writepicaxe routine to send the string as separate characters with delays after each character sent.

You may be able to replace the comport.write routine itself so none of the rest of the code has to change but I'm not familiar with processing so don't know if that is possible.

As to a PICAXE-side solution, there are limited options with SERRXD. You could move to using SERIN or even high-speed serial receive. High-speed serial receive is the best option IMO for receiving things from a PC.

You can connect the download Serial In and SERIN or HSERIN pin together, issue a DISCONNECT so you can still use the same cable without swapping it over.

 

[greencardigan]

The easiest solution would seem to be to replace comport.write with comport.writepicaxe and then write that comport.writepicaxe routine to send the string as separate characters with delays after each character sent.



As to a PICAXE-side solution, there are limited options with SERRXD. You could move to using SERIN or even high-speed serial receive. High-speed serial receive is the best option IMO for receiving things from a PC.

You can connect the download Serial In and SERIN or HSERIN pin together, issue a DISCONNECT so you can still use the same cable without swapping it over.

I'd rather not write a new library for processing. Besides, I'm having the same issue with another program.

Connecting the download pin and hserin pins sounds like a good idea. I might try the background receive option.

But what happens if serial data is being received as the picaxe is turned on and before the disconnect command is run?

 

[hippy]

But what happens if serial data is being received as the picaxe is turned on and before the disconnect command is run?

The PICAXE will go into download mode, wait for a download ( which won't arrive ), and then try to run the PICAXE program; if really unlucky it could get jammed up in this loop forever, and it could make for long starting times.

However, when not developing PICAXE code you can lock the Serial In pin to 0V so it will never see any download. Either have two 22K's in parallel, one to Serial In, one to HSERIN and a link to 0V on Serial In, or one 22K and a link which switches Serial In between serial data or 0V/pull-down.

Just linking the two pins is a quick-and-dirty fast-track to proving it works but will often be usable if data is received infrequently enough. You'll get at most one delayed start-up but then it runs as expected.

 

[greencardigan]

Weird!?

Just linking the two pins is a quick-and-dirty fast-track to proving it works but will often be usable if data is received infrequently enough. You'll get at most one delayed start-up but then it runs as expected.

I have tried this and it works well.

However I have tried connecting the hserout pin with the serial out pin to do the same thing for outgoing serial comms but it does not work??

It stops both sertxd and hserout from working. But if I disconnect the serial in pin, then hserout starts working. Disconnecting the hserin pin lets sertxd start working.

I suppose there's no way around this through the code?

 

[hippy]

However I have tried connecting the hserout pin with the serial out pin to do the same thing for outgoing serial comms but it does not work??

If that's actually what you have then you will be shorting two outputs together and one will be fighting the other to put the signal high while the other is fighting to keep it low at the same time - that can end with permanent failure of the PICAXE !

To join two outputs you need to use diode mixing or other techniques.

I'm not sure why the SERIN pin would affect things so maybe a block diagram to show what you have will help.

 

[greencardigan]

No smoke

It's still alive.

I'm not sure why the SERIN pin would affect things so maybe a block diagram to show what you have will help.

Whoops, that was meant to say serial out pin.

OK, I'll resort to manual switching between serin and hserin.

 

[hippy]

It seems to me this should work ...

 

[greencardigan]

getting there

The configuration in your pic lets me use hserialout and sertxd.

BUT downloads wont work.

 

[hippy]

Are you remembering to use the Hard Reset process, pressing Reset button for each download ?

I haven't tried it but I'd have expected it to have worked.

 

[greencardigan]

Are you remembering to use the Hard Reset process, pressing Reset button for each download ?

I haven't tried it but I'd have expected it to have worked.

Yes, I'm cycling the power off/on for downloads.

I assume your pic shows standard diodes? And I've tried a 4K7, 2K2 and 330R resistors on the output side tied to 0V.

 

[hippy]

Yes, I just used 1N4148 diodes and it works for me even without a pull-down resistor on the output. That can depend on what the serial interface is but it's just to keep the signal at 0V when both Serial Out and High-Speed Serial Out are at 0V. I'd suggest 10K possibly higher, but would have thought 4K7 would work and lower not really a problem.

Not sure why you cannot download as it works okay for me. Perhaps double-check your circuit wiring.

Attached test code which echoes what's sent via SERTXD and HSEROUT. Send a period or full-stop to put it back into download mode, press reset or power-cycle.

 

[greencardigan]

SERTXD ready
HSEROUT ready
<a>a<b>b<c>c<H>H<e>e<l>l<l>l<o>o< > <H>H<i>i<p>p<p>p<y>y<!>!<.>.
Ready for download

Download still not working after reconnect.

I'm having some other weird issues with my code which I'm starting to think might be related.

My code does calcs ever second and hserout's the results back to the pc but occasionally it seems to lock up (after maybe 5-10 minutes). Othertimes it start sending back semi rubbish data.

 

[hippy]

Not sure why download won't work after reconnect; it works for me. It seems like the serial in is not getting through so I'd suspect a wiring error though not sure what or how exactly.

The lock-up and gibberish could be reset related, which could also suggest some link between an output and serial in or a power rail.

It would be worth posting your circuit, program and any photos you have of your set-up.

 

[greencardigan]

OK, here's a pic of my setup and my current version of code.

It's essentially a temperature logger.

It reads 2 thermocouples on an MCP3424 ADC chip and the ambient temp from an MCP9800. Both I2C.

It then does a basic conversion to degrees C and does some filtering on the temps and calculated rate of rise for each channel.

Depending on what mode is active, it sends back all or some of the calculated values.

pBourbon mode will send serial data each second. Artisan mode sends data when requested.

For some reason it seems to lock up more often when in Artisan mode.

EDIT: I've also tried getting commenting out the serial receive loop but it still locks up. There's no other loops in the code that could behave like a lock up.

 

[greencardigan]

JUNK

Here's what happens occasionally.

.
.
.
.
.
770,21.62,20.86,0.03,20.37,-0.00,0
771,21.62,20.86,0.06,20.37,-0.00,0
772,21.62,20.71,0.01,20.37,-0.00,0
773,21.60
661621.65220.65,,0.09,,0.
0,-,.17,3
662,21.65,20.65,-0.12,20.40,50.1660
6.3,,1..5,,0..5,,0.15,20.
0,6,.0.60,
6.6,,1..5120..3,-0..4020
40,7021.,2
066221..1,,0..07,0..90,0
40,8,.1.,2,
6.6221.61,,0..1,,0..8,,0.41,9,20.60,
0677,1..1,,0..3,,0000,20.
2,0,20.62
0.672-..1,,00637,0..0020
42,1,20.62
0.792-..0520063,,0..5020.
3,2,20.62,
6.68,10.84,00837,00000,0
3,3,21062,
6.6421..8720..87,.0.,0004
,-4,21,62,60.,2,.0.12,27.37.-6.00,4
-05,21.
2,70.61,-0.13,70.07,5,.0040
-0.6,21.
2,40.62,60.05,70030,,2..010
0.07,21.62,,0.625,0..71,0.37,20.00,00
008,21.72,20.62,20.15,0..67,0..90,0
3,9,21762,10662,00.74,.0.,7,.0.0-,0
,00,27.62,.6.620.0.10,00.27.39.-0.01
0
1,21,62,60,77,60,0.,3,.3.,9,.0000
0
2,21.12,40283800000,,2..7,,-..000

63,22.624,0.705-0.09,20.37,-0.00,0
684,21.62,20.62,00.80,0.33,,0.00,,

835,2..6,,00663,.0.02,.09370.0.,0,06
4,6,26.62,.6.620-0002,.40370.0000
06
5,7,26.62,20577,.03010.0.3-,.0.,0,06
6,8,21.62,.8.67.-0.00.21.30,00.00
0
7,29,21,62,80,63,30203,1,.37,0,.
060
,210,21262,90..2,,0.04,,-.30,,0.
080
1.1,22.620,0.02,20.05,-0.07,0
.60002
.62,21.62,00062,0..0,,0..3,,
.0

.... and so on


Other times in Artisan mode it starts returning

10.11,10.11,10.11
10.11,10.11,10.11
10.11,10.11,10.11
10.11,10.11,10.11
10.11,10.11,10.11
.
.
.
.

 

[hippy]

It's very difficult to tell where each part of the information is coming from, whether it's sending correctly and the underlying calculations or data formatting is wrong or whether it's data corruption. One trick is to add a prefix {1} or similar with a different number for each HSEROUT, and add CR,LF so each is sent on a separate line. That at least narrows down to what bit of code is producing the actual output which will narrow things down.

Some of the data does look corrupted, shouldn't be as shown but is that the data being sent corrupted or wrongly displayed ? What are you using to capture and display the reported information ?

If diode-mixing serial outs, it's worth taking that out until you have the code working to ensure it's not that which is causing corruption. Unfortunately it's quite complicated code using hardware others won't have so difficult to try it for oneself. If you can cut the code down to something anyone can run which shows odd behaviour then others may be able to test for themselves to see if they get the same results.

 

[greencardigan]

Some of the data does look corrupted, shouldn't be as shown but is that the data being sent corrupted or wrongly displayed ? What are you using to capture and display the reported information ?

Programming Editor Terminal

If diode-mixing serial outs, it's worth taking that out until you have the code working to ensure it's not that which is causing corruption.

I haven't been using the diode-mixing serial outs.

Unfortunately it's quite complicated code using hardware others won't have so difficult to try it for oneself. If you can cut the code down to something anyone can run which shows odd behaviour then others may be able to test for themselves to see if they get the same results.

I'm currently removing parts of the code to see if I can stop the problem. I'll try to get something simple that still has the problem.

 

[greencardigan]

I give in (for tonight)

I commented out the calls to the filter calculation subroutines and it still locked up.

Then I commented out all the I2C subroutines and it ran for 40 minutes without locking up before I turned it off. Seems like the problem might lie in the I2C code or hardware.

Hope my hair regrows tonight so I have something to pull out tomorrow.

 

[greencardigan]

Getting closer

I commented out all the code except the hserout lines which I had looping approx once per second.

It ran for about an hour before I started getting gibberish in serial terminal. After cycling the power, terminal kept displaying more gibberish. Clicking Edit -> Clear input buffer in terminal caused the correct text to be displayed again.

I think there's 2 separate issues. The gibberish and the lock ups.

 

[greencardigan]

I have cut the code down to this and it still locks up. Sometimes after 3 or 4 minutes. Sometimes after an hour or so.

Is there some way the hi2cin or hi2csetup commands could be causing the lock ups?

#picaxe 28x2
#no_table

symbol amb = w25				' ambient temp
symbol amb_MSB = b51			'
symbol amb_LSB = b50			'

disconnect	'stops scanning serial in for new downloads

hsersetup B9600_8, %111	'hardware serial setup.  Continuous background mode


hi2csetup i2cmaster, %10010000, i2cfast, i2cbyte 'setup for MCP9800 ambient temp sensor
hi2cout (%00000001, %01000000) 'set pointer to config register, and change to 11bit conversion
hi2cout (%00000000) 'set pointer back to temperature register

settimer t1s_8 'set timer for 1 second increments at 8MHz

do

	gosub read_amb
	hserout 0, (#timer," ", #amb,13,10)
	toggle c.5
	pause 125

loop

read_amb:
	
	hi2csetup i2cmaster, %10010000, i2cfast, i2cbyte 'setup for MCP9800 ambient temp sensor
	hi2cin (amb_MSB,amb_LSB) 'read 2 data bytes xxxx xxxx xxx- ----
	amb = amb >> 5 * 100 / 8 'shift right 6 bits, x100 to preserve 2 decimal places, /8 to convert to degrees x100 
	return

 

[marks]

yes i believe there are conflicts i do this sort of thing on a 20x2 lol

#picaxe 28x2
#no_table

symbol amb = w25				' ambient temp
symbol amb_MSB = b51			'
symbol amb_LSB = b50			'

disconnect	'stops scanning serial in for new downloads

hsersetup B9600_8, %111	'hardware serial setup.  Continuous background mode

PAUSE 10
hi2csetup i2cmaster, %10010000, i2cfast, i2cbyte 'setup for MCP9800 ambient temp sensor
PAUSE 20
hi2cout (%00000001, %01000000) 'set pointer to config register, and change to 11bit conversion
hi2cout (%00000000) 'set pointer back to temperature register
HI2CSETUP OFF
PAUSE 20
settimer t1s_8 'set timer for 1 second increments at 8MHz

do

	gosub read_amb
             	hserout 0, (#timer," ", #amb,13,10)
	toggle c.5
	pause 125

loop

read_amb:
	PAUSE 10
	hi2csetup i2cmaster, %10010000, i2cfast, i2cbyte 'setup for MCP9800 ambient temp sensor
	PAUSE 20
	hi2cin (amb_MSB,amb_LSB) 'read 2 data bytes xxxx xxxx xxx- ----
	HI2CSETUP OFF
             PAUSE 20
	amb = amb >> 5 * 100 / 8 'shift right 6 bits, x100 to preserve 2 decimal places, /8 to convert to degrees x100 
	return

 

[greencardigan]

OK I'll give your suggestions a go.

I've found that I get a lock up much sooner when the PICAXE is powered up for the first time in a while. Trying to get it to lock up a second time takes a lot longer.

 

[hippy]

Can you describe exactly what you mean by "lock up", how that exhibits itself ?

 

[greencardigan]

The LED I have connected to c.5 stops flashing and nothing is received in serial terminal.

 

[inglewoodpete]

I don't know if this will help but change to i2cslow until you resolve the problem.

Also, why are you turning i2c on and off all the time? You can initialise i2c at the beginning of the program and read the MCP9800 whenever you need. No need to turn i2c off.

 

[hippy]

Maybe it's time to post a full circuit diagram and associated details. power supply etc. Did you ever figure out why the PICAXE would not accept downloads after a RECONNECT command ?

 

[greencardigan]

I don't know if this will help but change to i2cslow until you resolve the problem.

Also, why are you turning i2c on and off all the time? You can initialise i2c at the beginning of the program and read the MCP9800 whenever you need. No need to turn i2c off.

OK, back to i2cslow we go.

I'm not turning i2c off. That's what marks is suggesting I try.

A circuit diagram is coming.

 

[greencardigan]

Here's a quick sketch of my circuit. Nothing fancy here.

Also a photo of my breadboard layout.

I'm currently using an old mobile phone charger for the power. 5.1V 650mA.
But I was having the same problems when I was using 3 x AAA.

No, I haven't been able to solve the download issue with the diode mixing configuration for serial out and hserout.

The LED I have connected to c.5 stops flashing and nothing is received in serial terminal.

Sometimes the LED stops on. Sometimes off.

I have a new 28X2 and AXE027 cable in the mail heading my way. Maybe I have a dud chip?

 

[hippy]

The circuit looks reasonable enough, on the breadboard the 28X2 should really have leg 8 connected to 0V. Odd things can happen if not all 0V ( and +V ) are connected.

That not being able to download nags at me as that should be working regardless which suggests something is amiss. If the foundations are shaky then anything built on top is likely to be as well.

 

[inglewoodpete]

OK, back to i2cslow we go.

I'm not turning i2c off. That's what marks is suggesting I try.

A circuit diagram is coming.

Sorry, I only read the recent posts in detail. Turning i2c on and off rapidly is likely to confuse the slave devices. They don't like the i2c signal lines held low for long periods - it signifies a fault.

What happens when you comment out the hi2cin command? Lets isolate 1 thing at a time.

 

[marks]

My observations are based on use of a 20x2 ver C.0
had similiar issues too you as you have descibed!
it was a complicated process to get the code right
lowering pullups helps.
the manual mentions conflicts.
you can take a look at a working project here.
http://www.picaxeforum.co.uk/showthread.php?t=17993

 

[greencardigan]

I tried going back to battery power and tried i2cslow. Still locked up.

Commenting out the hi2cin line stops the lock ups.

Edit: I found that I can recover it from a lock up by touching the SCL pin on the TC4 shield. Does that suggest a wiring problem?

 

[marks]

i thought this too when on a breadboard but when moved to soldered board later had the same problem but touching pin scl i believe does bring it back into sync depends on condition of lockup sometimes i needed to power off to reset othertimes
i wanted to use settimer for my project so i was determined to get it worrking i believe there is the conflict

 

[greencardigan]

Are you talking about the conflicts mentioned in Manual 2 appendix 4?

 

[marks]

yes

I wanted to use settimer for my project so i was determined to get it working
I have should learnt how to use timer 3 but never tried lol.
I know how frustating this is. I did not think i had a problem it would run for 7 or 8 hours without problem.
With this current project i just let it run 24/7 without problem it updates time and temp every second(hi2cin)

I have seen some calculations for 400kbps everyone has a different view too usually between 1.5k to 3.5k pullups,
and calculation is affected by lowering supply voltage and increasing number of devices needing to select the lower end.
1k is the lowest one should go as it starts to effect rise time too much. for 100kbps 2.2k is usually recommended and slower 4.7k
pauses20 were required before and after HI2CSETUP this need to be increased when i went to 16mhz all varies buy selection of pullups.
doing both these things removed errors of ,out of sync,sda stuck low,scl stuck low(program freeze your flashing led being lit).

The last problem removed was buy the using hi2c off (program stuck between two lines of code)

Aso when using HI2CIN found I had to use HI2CSETUP a second time before it ,
to make it reliably work ,not just once at the beginning of program.

I did not want to post this because problems seem unique to myself .I do not remember everything exactly (should have recorded it lol) and rewrote my code sequence many times to try and rectify problems.
I also noted other activity on the sda pin( like it would talk to ds18b20 on other pins) this was one of the reason for a pause before Hi2CIN I believe it effected the start of i2c i found it only lasted for a few lines of code if your program was rearranged it wouldn't be needed.But I now leave them hoping code changes will still work)
I also note using the ds1307 is completely different I have discoverd a few things since using ds3231 I really need to go back
and check those projects but i only have one 20x2 so its one small step at one time lol.
hopefully people will report problems lol.
I think this is well known conflict using serial does alter the timer
but if using it once every second is not noticeable
If polling continously (1 sec retuned by timer can actualy be 3 or 4 seconds in real time).
yes there are many more things the 20x2 C.0 does but shouldnt, but can usually can be coded out and I expect they'rr already fixed in new revisions.(just hope my code still runs lol).

 

[greencardigan]

Still no good. I have tried the pauses around the hi2c commands and also turning hi2c off after each read.

My 28X2 5V has firmware B.0. Are there any known issues with this version?

 

[marks]

sorry it didnt work only trying to help and suggest what worked for me!

did it work at all
how long
any change
was led stuck on or off
what speed
what value pullups are you using
do you have any high brightness leds lol

 

[marks]

interestingly i ran you code like this ok on my 20x2 it was polling c.5 ok
of course i only have a ds3231 conected so it not talking to anything lol
only thing noted i had to power off to reprogram proberly because its using the
download pin.
if you are using just the 4.7k pullups on the external board
i would try added 4.7k from sda pin to v+
and 4.7k from scl pin to v+ at your 28x2

your can also monitor your activity on the sda and scl pins
by using a 2k res and high int led (blue of course lol) from scl to v+
and same for sda pin

if your led is lit when it fails this is likely where your program has hung(just before Hi2cin.

#picaxe 20x2
#no_table

symbol amb = w25				' ambient temp
symbol amb_MSB = b51			'
symbol amb_LSB = b50			'

disconnect	'stops scanning serial in for new downloads

hsersetup B9600_8, %111	'hardware serial setup.  Continuous background mode


hi2csetup i2cmaster, %10010000, i2cfast, i2cbyte 'setup for MCP9800 ambient temp sensor
hi2cout (%00000001, %01000000) 'set pointer to config register, and change to 11bit conversion
hi2cout (%00000000) 'set pointer back to temperature register

settimer t1s_8 'set timer for 1 second increments at 8MHz

do

	gosub read_amb
	hserout 0, (#timer," ", #amb,13,10)
	
	pause 125

loop

read_amb:
	high c.5
'	hi2csetup i2cmaster, %10010000, i2cfast, i2cbyte 'setup for MCP9800 ambient temp sensor
	hi2cin (amb_MSB,amb_LSB) 'read 2 data bytes xxxx xxxx xxx- ----
	low c.5
	amb = amb >> 5 * 100 / 8 'shift right 6 bits, x100 to preserve 2 decimal places, /8 to convert to degrees x100 
	return

 

[hippy]

interestingly i ran you code like this ok on my 20x2 it was polling c.5 ok
of course i only have a ds3231 conected so it not talking to anything lol

I ran a similar test using a 28X2 and reading an I2C Eeprom; I also did not get any lock-ups. I'm wondering if the issue is I2C related, but something to do with the module rather than the PICAXE.

It's always very difficult to determine what makes something completely stop and where it has stopped is hopefully useful to point to why. I would consider turning a LED on and a previous LED off for each of the lines so the LED indications may show where the program is / was when it stops. You don't necessarily need the LED's themselves, just the signal output whose levels can be read using a meter