RFH (Request for Help) PIC serial code..

[LabRat]

Good evening (afternoon etc),

I'm into my first foray of using the EUART on a PIC, and can't quite seem to get the moons to align properly (might have something to do with the Solar eclipse earlier in the day).

Setup: 16F688 - running off of internal oscillator.

A version of the JEC pixel code, stripped down to Serial IO only.
Rx,Tx connected (through an ugly mess of wires) to Windows PC.
Trying to run at 57.k kbits

I Have verified serial Tx/Rx from the PC all the way up to the PIC itself. (Shorting the Tx/Rx with no PIC present, results in a perfect loopback scenario)

The sample code is setup to send a stream of 'Z' characters (no particular reason why.. perhaps I was sleepy at the time).

Can those with more familiarity with PIC code take a peak, and see if they can identify anything that I missed?

Various tests show that I can send characters TO the pic, though they are scrambled on arrival, and data sent FROM the PIC is similarly corrupt.

Thanks for any pointers.

Andrew

[scorpia]

ok,

without looking at the code my first question is how exactly are you connected from the pc to the pic. i hope there is some sort of convertor chip in the middle. for testing i would suggest a usb - ttl serial board. but a 232-ttl (max232 etc) or even the correct rs485 chips (see renard designs etc) .

this should allow you to convert the serial comms from the pc to a ttl level signal that the pic can understand.

once that is working hopefully you should be able to receive something.

Also without looking at the code have you adjusted the uart speed settings for any speed differences between your board and jec's code.

regards

Peter

[LabRat]

Well.. (I was hoping to avoid this embarrassing setup.. )

PC -> Usb Serial->Custom Dongle ->RJ12 Cable->MAX232 Transceiver->Ribbon Cable->Proto-Board-> PIC

I took the two ends @ the proto-board and shorted them, and the signal loops back to the PC all "hunky dory". Every character typed, is echoed back to be displayed.

The PC is running Windows Terminal @ 57600, 8, N, 1 in TTY emulation. Key presses here, are noted by the PIC (and I get my flashy "I saw something" on my status LED). The PIC was to send back a 'Z', but I get garbage characters.

Putting code on the PIC to flash differently when certain keys are pressed, resulted in my determining, that the serial data is corrupt on arrival. So I altered the PIC FW to only transmit 'Z' characters... and I see a stream of data, which is consistently the "wrong" characters.

I'm actually seeing 2 "non-printable" (graphic ascii stuff) characters displayed for each 'Z' transmitted. Which has me wondering if the PIC is somehow running too slow, and the PC therefore is "oversampling" and thus getting the wrong information? (it's a theory anyhow)

Re: Uart adjustments.. Yes. I *believe* I have set this up to go at the slower speed (though without a properly matched crystal, there could be some error)

Math says: (8000000/(4*57600)) -1= 34
(Based on using 16 bit counters)


Thx for the input and assistance.

[djulien]

I'm not an expert, but here are some comments that might help (hopefully) from stuff I've run into when playing with the EUSART.

A few general comments ...

1. It's safer to use the symbolic constants provided by Microchip for individual bits, in case you ever decide to move your code to another chip.

2. Also, if you will start using interrupts at some point, you'll need to slide the start code down so it doesn't interfere with address 4, which is where interrupts will jump to.

3. I've read that an external clock is required for stable timing at higher baud rates. I've seen unstable timing in some of my experiments as low as 19200 without an external clock. Maybe try it first with a lower baud rate to see if it works with that, then speed it up to your target baud rate.

4. Also, if you are using a MAX232, I've read that it takes a little while for the charge pump to get to full voltage, so you might want to put a little delay near the start.

5. There are several notes related to the EUSART in the Microchip Erratta document, that might or might not be applicable.

Some specific comments ...



; setup internal oscillator
bsf OSCCON,6 ; Set these three
bsf OSCCON,5 ; bits to enable the
bsf OSCCON,4 ; 8 MHz internal oscillator


6. I've not seen sample code that sets osc speed bits separately like this. Each time you set a bit will destabilize the clock, and there is some Microchip documentation that recommends putting in a delay loop to wait until the clock stabilizes - something like:



clock_unstable:
if (HTS bit of OSCCON is off) then goto clock_unstable


7. If you comment out the call to PutByte, does the status LED go on and off at the frequency that you expect it you? If not, there may be bugs in your timing logic.



movlw 34 ; for baud rate generator


8. You might want to write that as d'34', in case you are using a hex radix rather than decimal.



movlw 0x24 ; Initialize the TXSTA
movwf TXSTA ;


9. Also, the datasheet I have lists a value of 34 for 57600 baud only for SYNC = 1 and BRG16 = 1. I see you are using BRG16 = 1, but it looks like you have SYNC set to 0, so that combination might not be correct for the baud rate you intended.

10. I've also read Microchip documentation that says you need to allow a little time for the baud rate clock to settle after it's been set.

Hope this helps. That's all I can spot from just looking at the code.

don

[LabRat]

Don,

Thanks for the reply.


I'm not an expert, but here are some comments that might help (hopefully) from stuff I've run into when playing with the EUSART.

A few general comments ...

1. It's safer to use the symbolic constants provided by Microchip for individual bits, in case you ever decide to move your code to another chip.


Understood. Will keep that in mind. At this point I was just trying to get it *working*... and then cleaned up. ;)



2. Also, if you will start using interrupts at some point, you'll need to slide the start code down so it doesn't interfere with address 4, which is where interrupts will jump to.


Understood. This was meant to be "as simple as possible to prove the Serial Tx/Rx is working".



3. I've read that an external clock is required for stable timing at higher baud rates. I've seen unstable timing in some of my experiments as low as 19200 without an external clock. Maybe try it first with a lower baud rate to see if it works with that, then speed it up to your target baud rate.

I had tried all the way down to 300 baud and was still seeing errors/artifacts. (I should have mentioned this.. sorry)


4. Also, if you are using a MAX232, I've read that it takes a little while for the charge pump to get to full voltage, so you might want to put a little delay near the start.


You have raised a VERY good point. This MAX232 board actually has a second "driver" chip on it as well, and I didn't check the specs on it's output vs the PIC's expected input. There could very well be an incompatibility there. (why didn't *I* think of that)




5. There are several notes related to the EUSART in the Microchip Erratta document, that might or might not be applicable.

Some specific comments ...


6. I've not seen sample code that sets osc speed bits separately like this. Each time you set a bit will destabilize the clock, and there is some Microchip documentation that recommends putting in a delay loop to wait until the clock stabilizes - something like:


Pulled straight from the PIXEL code. I was a bit surprised as well.




7. If you comment out the call to PutByte, does the status LED go on and off at the frequency that you expect it you? If not, there may be bugs in your timing logic.


I believe so, but haven't captured a trace for anything more quantitative than counting flashes in "about a second". But the point is well taken, that I should be able to use the flash rate of my status LED to confirm that oscillator settings.




8. You might want to write that as d'34', in case you are using a hex radix rather than decimal.



9. Also, the datasheet I have lists a value of 34 for 57600 baud only for SYNC = 1 and BRG16 = 1. I see you are using BRG16 = 1, but it looks like you have SYNC set to 0, so that combination might not be correct for the baud rate you intended.


Wondering if we have different copies. My document says that if I run SYNC=0, BRG16=1, and BRGH=1, then I get a 16bit asynchronous counter. And thus 34 can be used. I have not chased down Errata... another good point.



10. I've also read Microchip documentation that says you need to allow a little time for the baud rate clock to settle after it's been set.

Hope this helps. That's all I can spot from just looking at the code.

don

Given me some good starting points. Thanks

[P. Short]

Nothing really stands out as a problem. I've looked at the processor initialization, usart initialization and serial I/O routines, and they all seem OK at first glance (except that the first instruction in the waitNms routine should be movwf rather than movfw). I'm not sure what the impact of that firmware should be, since it simply changes the timeout from 250 ms up to 256 ms. Also, the 1MS delay routine only delays around 760 uS, rather than 1ms.

The only thing that I noticed is that you are resetting the RCIF flag in the GetByte routine, which i don't think is necessary. Also, I tend to use the instruction 'movf REG,w' rather than the movfw directive, even though they should be equivalent. Note that it will be hard to distinguish movfw from movwf when scanning the code, because they are so similar.

It may also be useful to check the error flags in the RCSTA register, but I doubt that should be a problem.

None of these seem likely to be related to the problem that you are encountering...

[P. Short]

I take back the comment about 760 uS, it should be 384 uS instead. The inner loop is 3 instructions long, so 256 iterations comes to 768 instructions, which takes about 384 uS with an 8MHz processor clock.

[djulien]

Wondering if we have different copies. My document says that if I run SYNC=0, BRG16=1, and BRGH=1, then I get a 16bit asynchronous counter. And thus 34 can be used.

Attached is the chart I was looking at. Yes, 34 is a valid value, but it only applies for the 2 cases: SYNC=0 & BRGH=BRG16=1, or SYNC=1 & BRG16=1.

You are using SYNC=0 (bit 0x10 of TXSTA) and you have BRG16 =0, so I took that to mean that you're not really in that chart.

Also, the Microchip Erratta says not to use bpth BRG16=1 and BRGH=1.

don

[LabRat]

Attached is the chart I was looking at. Yes, 34 is a valid value, but it only applies for the 2 cases: SYNC=0 & BRGH=BRG16=1, or SYNC=1 & BRG16=1.

You are using SYNC=0 (bit 0x10 of TXSTA) and you have BRG16 =0, so I took that to mean that you're not really in that chart.

Also, the Microchip Erratta says not to use bpth BRG16=1 and BRGH=1.

don

I have BRG16=0?? Isn't BRGH bit 2 of TXSTA and thus set as part of assigning 0x24 ?

(ok.. now you can point out that using the microchip mnemonic names would have helped here)

All that being said.. if the errata says we can't have both set to one, then then columns in the tables that I wanted to rely on... aren't available.
(just to the left of the red circles in your image.. SYNC=0, BRGH=1, BRG16=1... but sounds like this is no longer an option)

[P. Short]

Just a thought...try setting the PC baudrate to 28800 (leave the PIC firmware as-is), and see what happens.

The firmware copy that I downloaded has BRG16=1. I don't know if this is causing a problem, but the Renard firmware all runs with that bit clear.

[djulien]

I have BRG16=0?? Isn't BRGH bit 2 of TXSTA and thus set as part of assigning 0x24 ?

(ok.. now you can point out that using the microchip mnemonic names would have helped here)

All that being said.. if the errata says we can't have both set to one, then then columns in the tables that I wanted to rely on... aren't available.
(just to the left of the red circles in your image.. SYNC=0, BRGH=1, BRG16=1... but sounds like this is no longer an option)

Sorry, you're right - you have BRG16=1. So it looks like both BRG16 abd BRGH are on, which might get back to that Erratta note about using both.

You can get 57600 with BRG16=0, though, by using an alternate value in the charts.

don

[LabRat]

Sorry, you're right - you have BRG16=1. So it looks like both BRG16 abd BRGH are on, which might get back to that Erratta note about using both.

You can get 57600 with BRG16=0, though, by using an alternate value in the charts.

don

Just went and got the errata.. (You would think they could update the manual when releasing the errata .. (sigh))

So my 300 baud tests was with both BRG16 and BRGH on.. so it may have been prone to failure as well. I will re-try selecting a baud rate from one of the other "modes".

[djulien]

Just went and got the errata.. (You would think they could update the manual when releasing the errata .. (sigh))

So my 300 baud tests was with both BRG16 and BRGH on.. so it may have been prone to failure as well. I will re-try selecting a baud rate from one of the other "modes".

Yes, that would be nice. But the Errata says that they intend to fix it some day, so I guess that saves them the effort of updating the doc.

Back when I was experimenting with the '688 EUSART, I was not able to get above 19200 reliably when using the int osc at 8 MHz, but you may have better luck with it.
[EDIT] I went back to check my notes; actually, I did get it running at 57600 on the int osc, but sometimes had some junk characters at the start at rates faster than 19200. This could be because I did not wait long enough for the baud rate generator to stabilize.

don

[LabRat]

Yes, that would be nice. But the Errata says that they intend to fix it some day, so I guess that saves them the effort of updating the doc.

Back when I was experimenting with the '688 EUSART, I was not able to get above 19200 reliably when using the int osc at 8 MHz, but you may have better luck with it.

don

Well it just keeps getting stranger. According to the PIC setups, I'm running at 19200. According to my PC.. its running at 9600... "and the data is flowing" (well.. I can easily flood the PIC and I don't have error handling in there yet... but data *is* going back and forth.)

Very bizarre... perhaps I do have a clock setup issue afterall.

I would hope that I can do better than the 19200, given that the DMX users have this running significantly faster (albeit with a better sync/harmonic to the FOSC).

[djulien]

Well it just keeps getting stranger. According to the PIC setups, I'm running at 19200. According to my PC.. its running at 9600... "and the data is flowing" (well.. I can easily flood the PIC and I don't have error handling in there yet... but data *is* going back and forth.)

Perhaps the PIC is still running at the default 4 MHz clock rather than 8 MHz? That would make the effective baud rate 9600 even though the registers are set to run at 19200. The status LED timing could be used to verify that.


I would hope that I can do better than the 19200, given that the DMX users have this running significantly faster (albeit with a better sync/harmonic to the FOSC).

Do they use an ext osc?

I've read of a way to "tune" the int osc to make it more accurate (osctune reg), but it would still be subject to drift due to temp or voltage.

don

[LabRat]

Perhaps the PIC is still running at the default 4 MHz clock rather than 8 MHz? That would make the effective baud rate 9600 even though the registers are set to run at 19200. The status LED timing could be used to verify that.



Do they use an ext osc?

I've read of a way to "tune" the int osc to make it more accurate (osctune reg), but it would still be subject to drift due to temp or voltage.

don

I was thinking the same thing (running at 4Mhz). So my new init code looks like:


BANK1
movlw 0x71 ; 8 MHz internal oscillator
movwf OSCCON

Wait4Clock2Settle
btfss OSCCON,HTS
goto Wait4Clock2Settle
clrf OSCTUNE


But that hasn't changed the behaviour.

The PIXELS are running at 250kbits with no sign (that I saw) of a crystal. I'm pretty sure they're clocking to the internal oscillator. (though I'm too tired tonight to go and track down the actual documents)

Will have to pick this up tomorrow. Thanks for all the usefull comments everyone.

A.

[LabRat]

Well I'm not there yet, but there was certainly some more progress. I did some more experiments assuming a FOSC of 4 MHz, and was able to get predictable communications. So clearly I'm not getting the clocks setup correctly.

Took a look at all the registers being "tweaked" and noted that the ANSEL is at the same offset within the BAUDCTL (but in a different bank). So I reviewed the use of the BANK0/BANK1 macro's and replaced them with BANKSEL .

I believe I'm now running at the correct frequency, and I'm getting data at the correct baud rate. That being said, it's not a clean signal, and I'm getting a significant failure rate, but that could be due to the wild way in which I have the serial all cobbled together. This evening I will try pushing the PicKit into Serial mode, and see if I can jumper across from there.

Thanks again everyone. It's been a learning experience!! :rolleyes:

[P. Short]

You should be able to get the thing to run at much higher baud rates than 19200. The biggest issue may be baud rate error, although the UARTs should run fine with a baud rate that is as much as 1% off from the nominal value. With the PIC's internal oscillator set for 8 MHz the baud rate should be very close to the right values for 19200, 38400 and 76800 baud, and will be a bit off for 57600 and 115200 baud.

Also, some people have run into problems with some of the inexpensive Ebay USB-RS485 (or was it USB-RS232) dongles, apparently their baud rates are a bit off when configured for the higher rates.

[LabRat]

I'm seeing way more errors that I should, so the USB dongle is suspect. (You get what you pay for when you scrounge parts ;) )

[LabRat]

Some more notes and observations.

Connected to the PICKIT at upto 19200 without incident. Everything was clean. So it could well be that the USB serial is just trashy.

Also had me wondering though. I've got his entire mess hanging off of the USB port (and using the USB to power the PIC, LED, MAX232 etc). Perhaps the whole mess is just drawing too much power from the USB?

But then again.. maybe not as it was all hanging there together when the PicKit serial tool was talking to the PIC.

(For good measure I populated a 10uf between +5 and GND to try and smooth out any fluctuations that might have been occurring)

Thinking that I was onto something, I grabbed a 7805 and a 9v "Wall Wart". 20 Minutes later I had an independent 5v supply... and it didn't make one bit of difference.

It's really looking like that USB to serial adapter may be a bit "wonky". I will go and see if I have another one down there somewhere...

[scorpia]

hi,

if your looking doing a bit more of this type of playing with pics. it might be worth getting one of these or similar.

http://www.sparkfun.com/commerce/product_info.php?products_id=718

the fdti chips seem to be very reliable and this sort of board can make it very easy.

Peter

[LabRat]

Thx... as it turns out the 2 usb to serial boards I have seem to be fine.

(It was my PIC code that was awful ;) )

I've never been a fan of the ftdi.. but that could be because I was playing with the 18F series with the built in USB. It just didn't seem to make sense to stick and FTDI into the equation. (Oh.. and that was my OTHER option... to turn my "bit whacker" into a USB to serial adapter, in order to talk to my device. Either way it would have choked, as the problem was with my setup of the PIC).

After 2 days of losing hope, I'm feeling quite optimistic again. (Perhaps it was the arrival of my package from SUREELECTRONICS today. Mini-LED floods, and a whole bunch of Screw down terminals).

[scorpia]

yeap NP.

i just meant that with that fdti board there is no need to use a rs232 convertor chip as well. just wire the pic direct to the fdti board.

the board i linlked is a usb- ttl not a usb - rs232 adaptor.

so for future projects it might make it easier.
but as you said your working now.