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:
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?
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.
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.
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.
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.
I think this is unlikely to be the problem, for 2 reasons:
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.
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.
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.
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.
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:
Non Working set up:
Non Working set up:
Is this a bug in the UART component?
Should I file a case?