Why does hsersetup give me a free 0xff on hserout? (28X2)

[MartinM57]

#picaxe 28x2

setfreq m8

hsersetup B9600_8, %00000111

do
loop

...gives (EDIT: a single) 0xFF out of the hserout pin when it runs.

Removing the 'setfreq', changing the 'do loop' to 'end' etc makes no difference.

The only way not to get the 0xFF out is to delete the 'hsersetup' command

It's causing a problem as it's an unexpected transmission from the PICAXE to my controlling PC program, which makes it get confused.

 

[womai]

My guess - on the other Picaxe's the hserout pin's default function is an input. So the moment you define it as the hserout pin (by using the hsersetup) it will become an output and drive either high or low. Possibly your PCs serial input mistakes that transition (from high impedance to actively driving) as a start bit and then simply reads what it thinks are the 8 data bits following the start bit.

A workaround would be to preface all data sent to the Picaxe with a certain data byte (anything other than 0xff will work). Then have the PC program simply ignore all data sets that don't start with the correct byte.

The other option is to require the Picaxe to be powered on before you start the PC program.

Wolfgang

 

[boogiebehometh]

I've left my setup n datasheets at work n my mobile phone's browser won't open those from the link above, but, off-hand:

My thoughts r along the lines of what Womai said, for prolly only need a spike on the pin to get an ff...

Could u change the hsersetup mode not to reverse the output pins, n check with an LED or scope if u're still getting a spike? (or with an external invertor u could still check with your current reciever)

 

[MartinM57]

I'll check tomorrow with a scope, but it sounds like you may (both) be on the right lines.

I want to invert the hserout pin so that I don't have to use a MAX232 and can use the programming cable for control of the app - which is working great apart from the 0xFF.

I don't know enough about RS232 - would a single 0V to +V transition on hserout due to a hsersetup command with output inverted be picked up as 0xFF at any baud rate?

It's a bit of an unfortunate side effect as it stands...

 

[hippy]

A single pulse could potentially do it but it perhaps depends on the PC's UART receiver. It's a similar issue to using SEROUT with a Txxxx baud rate when the output pin initialises as low not high.

To get 0xFF it means there was a start bit (+V) followed by eight low data bits (0V) seen on the physicl comms line. If the pulse were longer than a one and a half bit time you would see different to 0xFF, for example a long pulse would be a start bit followed by eight high data bits which would read as 0x00 and/or a 'break signal'. This suggests the pulse was less than one and a half bit time.

A reasonably good UART should detect the rising edge of the start bit, sample in the middle and reject if it wasn't still present so this suggests a pulse of longer than a half bit time, so, between 52us and 156us.

I tested on my PC and I don't see any 0xFF. Neither on reset nor power-up, using physical COM2 or AXE027 - I added HSEROUT 0,("U")AUSE 1000 in the DO:LOOP to prove it was wired correctly and working.

It could be that your PC UART hardware is different. You could try adding a pull-down R on the TX line to the PC. That should keep it low while the TX pin is an input to the PICAXE. You could test if it is this issue by adding a PAUSE or any other command before the HSERSETUP without a pull-down; that should lengthen any pulse and the PC should receive different data.

Synchronising serial is always an issue; should the PC or PICAXE restart, there's always the possibility that the data received will be corrupt so it's best to design a protocol which can check for that rather than relying on data being as expected.

 

[MartinM57]

More info:

#picaxe 28x2

setfreq m8

pause 5000

hsersetup B9600_8, %00000111

do
loop

- hserout is low while the pause occurs
- hserout is low after hsersetup has occurred
- hserout outputs an 0->1->0 pulse (something less than 1ms as 'scoped) at a time consistent with hsersetup occuring
- and most weirdly I've now noticed it consistently happens on the run immediately initiated after a download
-...it doesn't happen at all when the repowering the picaxe from powered off

EDIT:
- programming cable is AXE027
- hserout cable is USB010 plus AXE026

 

[hippy]

Thanks for the further details; I can confirm the behaviour you are seeing, both on download via physical / HSEROUT to AXE027, and swapped - 0xFF on first run immediately after download.

I'll flag it as something to be investigated.

One workround may be to force a 'break' on C.6 before HSERSETUP which you should be able to catch PC-side, re-initialise comms, set a flag to skip the next byte if 0xFF - That would be handy as well should you ever download while the PICAXE is halfway through transmitting a packet or get an inadvertent reset etc.

Alternatively, check if first run after download ( EEPROM useful for that ) and only send break then or some dummy padding data.

 

[MartinM57]

Thanks Hippy - at least it's not just happening to me. One always feels that there is something silly and overlooked when posting unexpected behaviour.

It's not too bad now I know it won't happen in the field...even if the units are re-programmed there, the controlling program won't be running at the same time (since there's only one socket and jumpers selecting whether it goes to Serin/Serout for programming or hserin/hserout for program control)

Ta
Martin

 

[Technical]

A better description of your test analysis, which may help explain things, is

- hserout is FLOATING while the pause occurs
- hserout is low after hsersetup has occurred
- hserout outputs a FLOATING->FLOATING->0 pulse (something less than 1ms as 'scoped) at a time consistent with hsersetup occuring


After a reset the pin is not driven, it is floating (input status) until the hsersetup command occurs. Therefore the state of the 'txd' signal sent to the computer is completely unknown, it is a floating , non-driven, signal.

After a download the PICAXE is 'reset' (using the assembler code 'reset' command). This is similar, but not completely identical, to a power on reset - in either case the PICAXE chips runs exactly the same firmware code when the program restarts. the hsersetup command simply enables the hardware USART port - all high/lows themselves etc. are done by the internal PIC hardware, not the PICAXE firmware It might well be the USART hardware pulses itself in this situation, we can look into that, but the PICAXE firmware can't change that if it is the case.

You could try a 'low c.6' command at the start of the program, or a 10k tie-down resistor on the output to stop the floating. However the bottom line is that any serial system, as indicated by others above, should always be tolerant of some garbage data during initialisation.

 

[MartinM57]

...hserout outputs a FLOATING->FLOATING->0 pulse (something less than 1ms as 'scoped) at a time consistent with hsersetup occuring

I don't quite understand how a FLOATING->FLOATING->0 pulse looks like a strong 0v (it may well be floating) -> 5v (definitely not floating - at least the the 'scope probe and the download cable preventing it floating to 5V) ->0v (probably ground, not floating)...

 

[boogiebehometh]

WatchDog!

I tested on my PC and I don't see any 0xFF. Neither on reset nor power-up, using physical COM2 or AXE027 - I added HSEROUT 0,("U")AUSE 1000 in the DO:LOOP to prove it was wired correctly and working.

i got to look at the datasheets briefly - for both picaxe & pic18f2520 & guess what?

amongst the whole list of resets etc that cos a high in port c is the WDT

Could it be that hippy prolly left his watchdog off & Martin left it on?

=========================================================

Martin, maybe u could poke at bit 7 of F94H, which would do as Technical suggested - which might help, but i'm not sure where u should do it cos putting this at the wrong place could cos the hserin will fly high until u next address it.


But b4 u do, could u try to turn off the watchdog timer & see if it solves anything?