 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Laurent Chouinard
Joined: 12 Sep 2003
Posts: 43
|
| PIC 18F, HW EUSART, Interrupts, Full duplex = garbage data? |
 Posted: Mon Dec 07, 2009 11:25 am |
 |
|
I've search the forums and couldn't find anyone that had this particular problem, so I'm posting it.
I'm using a PIC18F6722 with the hardware serial port. I declare the serial port like this:
| Code: | | #use rs232(stream=COPIER_PORT, baud=19200, parity=N, xmit=PIN_COPIER_TX, rcv=PIN_COPIER_RX, BRGH1OK, bits=9, LONG_DATA, ERRORS) |
Later in the code, I re-initialize it as 38400, because I only know then about the baud rate required.
| Code: | | setup_uart(38400, COPIER_PORT); |
The communication requirements with the device are 38400 bauds, parity ODD, 8 bits data, 1 stop.
To support parity, I have to do it myself using the 9th bit function.
Furthermore, the port is fully interrupt driven, using #int_rda and #int_tbe to receive data into a buffer or send data from another buffer. I use separate buffers to make sure nothing gets tampered with. Additionally, the #int_rda routine sends new data into a circular buffer to prevent buffer fights with the main loop that manages that buffer.
So here's the problem. This works beautifully well with the exception that when serious full duplex happens, when RDA is receiving a lot of data and, at the same time, TBE is sending a lot of data, then *ONE* byte, on occasion, will not be received properly.
And by that, I mean that I can trigger a breakpoint directly in int_rda if it matches the erronous data (in my case it's 0x82, a byte that is impossible in the given communication with the host). When breakpoint tiggers, I have a computer that is spying on the serial lines and logs in a terminal. It shows I should have received 0x00, but instead the PIC receives 0x82. There are no errors of parity, no errors of framing or oveerrun (i check those flags all the time, and specifically when the problem happens and before. They're always good).
We've been debugging this issue for several days, pushing theories and proving everytime that it's not our code. Eventually we even discarded "fgetc" method and went on to read the PIC's registers ourselves, still getting that damn 0x82.
Eventually, we decided to stop using INT_TBE for transmission, and relayed that function back into the mail loop. It only moved our problem later in the communication. This time it's not 0x82, but it's still one single incorrect byte (out of several thousands).
Finally, we "fixed" our issue by preventing full duplex. As long as data is coming in, a timer is reset. At expiration (25ms), then transmission begins.
Cute fix, but we hate it. We hate the fact that, despite our best efforts, the PIC's internal EUSART appears to be unable to handle full duplexing with interrupt-driven (at least for RX) hardware port.
We can't use software ports because of the main loop doing too many tasks, which would lose data.
So my post in this forum is this. Has anyone had issues with dealing with that EUSART along with interrupt driven data reception at a higher baud rate?
Oh we're using a 20MHz clock.
Thanks for the comments you might have. |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Dec 07, 2009 1:53 pm |
|
|
Check the silicon revision of your PIC. The errata for the Rev A1
silicon of the 18F6722 has EUSART problems similar to what you
have described.
http://ww1.microchip.com/downloads/en/DeviceDoc/80221c.pdf
The B1 silicon errata sheet doesn't list that particular problem any more,
though it still retains one problem.
Here's the main page for the PIC. You can see all Errata documents
here:
http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en010316
If you have the A1 silicon, then upgrade to the B1 rev. See if the
problem goes away. I don't know where you buy your parts, but
Digikey has told me that they will supply the latest rev if you request it.
(ie., Tell them the specific silicon rev number that you want).
You can see the silicon revision when your ICD2 "connects" to the PIC.
Look in the Output window in MPLAB. |
|
|
Laurent Chouinard
Joined: 12 Sep 2003
Posts: 43
|
|
| Posted: Tue Dec 08, 2009 8:22 am |
|
|
Sir, I hope someone is paying you for your contributions here because you are, once again, a life saver.
In-very-deed, bug #14 in the errata A0 chip is the one I experience, and Microchip confirms me that the part in my PCM18XS0 processor module for my emulator is, just as well, an A0 chip.
Well this is quite horrible. I can build circuits that are working correctly, but I can't develop the firmware in the emulator. Microchip advises me to move my designs to ICD3 or REAL ICE emulators, which require me to sacrifice two pins for the debugging, pins already widely in use for this current board design, of which I have thousands in the field.
I guess we're going to have to use good old programmer-fix to avoid the situation that leads to the bug (preventing full duplex), but it certainly leaves a bad taste in the mouth after spending thousands on development equipment and board designs.
Once again, thank you for your contribution, PCM Programmer. |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
