- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I'm using a UDB UART, and it's sometimes producing errors, despite the input signal looking well within spec. Am I doing something wrong?
I have two PSoC4s: one is transmitting "BlahblahHello!", and one is receiving. The receiving one has two outputs for debugging:
- A copy of the input digital signal, so I can check that it's getting a good waveform.
- Re-transmitted bytes, so I can check that the UART us correctly interpreting the incoming signal.
The baud rate is 2Mbaud, using a 16MHz input clock on the UART component. Most of the time the UART works fine, but sometimes it seems to generate an error, and then loose synchronisation for the rest of the string.
The obvious cause would be that the transmitter and receiver have very slightly different clock frequencies. But I have checked their clocks using a 1MHz output from each using a PWM component. Their clocks differ by less than 0.1%. Am I doing something wrong? Is there anything I can do to reduce the error rate?
Hugo
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Does it work if you drop the Baud rate? Please post your code.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If I halve the clock from 16MHz to 8MHz (2Mbaud to 1Mbaud) the error rate doesn't seem to change. (about 100 per second) If I go down to a 1MHz clock (125kbaud), then I see only a few errors (about 10 per second)
If I keep the 16MHz clock, but use 16x oversampling, then the errors seem to disappear completely.
I would be sad if this is the only solution, as I really need at least 2Mbaud.
Hugo
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Change buffer size in settings to 22 and see what happens. Also post your code so we can check it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You could try upping the HFCLK to 48 MHz, and setting the UART clock to 24 MHz, then using the 8x oversampling will give you 3 MBaud, but I suspect there is an issue going on that is causing the errors to increase with the frequency.
I would try different clock frequencies, and see if they aggravate the problem.
Also, you could try changing the interrupt priorities to handle the internal UART interrupts with higher priority than the software interrupts.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Changing the clock frequencies seems to make no difference. I've tried a few in the range 1MHz - 16MHz, with lots of errors all the time.
I haven't tried changing the interrupt priorities, but I don't think it would help. One experiment I tried was to output a pulse on a debugging pin inside the RX interrupt handler. On the logic analyser, I could see that the RX interrupt was being called in good time, and therefore the RX buffer was never filling up.
One thing I haven't tried it getting the UART to talk to itself. In that case, the clocks should match perfectly. But that will have to wait until I'm back at work on Tuesday.
Hugo
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Looking at your project, there is no flow control enabled either in software or hardware, so at higher speeds this might be the cause of the increasing error rates.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think this is unlikely to be the problem, for 2 reasons:
- On the logic analyser, I can see the interrupts being serviced. They are serviced in good time, and the RX buffer never gets more than half full.
- Lowering the baud rate does not get rid of the errors, but switching to 16x oversampling does gets rid of the errors.
Therefore I think it's much more likely something to do with the generated receive clock. When I get into work in the morning, I'm going to make a clone of the UART component, and modify it to get access to the RX sample clock, so I can see when the samples are being taken, and if the clock is somehow drifting out of sync.
Hugo
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Since you ran a logic analyzer on the data, I'm assuming it showed all of the data as being correct (as far as the analyzer sees).
In that case, I would agree that the clocking, baud rate, and the data being sent shouldn't be the problem.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yep, all of the serial data that the UART is seeing looks perfect. And the clocks of the transmitter and receiver are within a fraction of a percent.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Bob,
Did you manage to get a chance to look at my code?
Hugo
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Have you considered EMI could be effecting the data errors?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think this is also unlikely, because it's only a couple of inches between the master and slave, with a close ground return.
Furthermore, I can see the actual signal that the UART is using, because I'm copying it to another pin, and looking at that on the analyser. And that signal looks perfect. There are no spikes or glitches, and the timings are spot on.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Update:
I can make the UART work simply by switching on the CRC outputs AND the 2/3 voting! Turning either of these off literally stops the UART working properly.
Working set up:
- 3Mbaud
- CRC outputs
- 2/3 voting
- 8 bits, 1 stop bit
Non Working set up:
- 3Mbaud
- 2/3 voting
- 8 bits, 1 stop bit
Non Working set up:
- 3Mbaud
- CRC outputs
- 8 bits, 1 stop bit
Is this a bug in the UART component?
Should I file a case?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I would file a case and see what they say. 🙂