UDB UART errors

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
HuEl_264296
Level 5
Level 5
First like given 25 sign-ins First solution authored

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: 

   
        
  1. A copy of the input digital signal, so I can check that it's getting a good waveform.
  2.     
  3. Re-transmitted bytes, so I can check that the UART us correctly interpreting the incoming signal.
  4.    
   

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

0 Likes
15 Replies
rola_264706
Level 8
Level 8
50 likes received 25 likes received 10 likes received

Does it work if you drop the Baud rate? Please post your code.

0 Likes

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

0 Likes
rola_264706
Level 8
Level 8
50 likes received 25 likes received 10 likes received

Change buffer size in settings to 22 and see what happens.  Also post your code so we can check it.

0 Likes
lock attach
Attachments are accessible only for community members.

Hi,

   

I tried increasing both buffers to 22, but it made no difference.

   

Please find attached the workspace bundle.

   

Hugo

0 Likes
Anonymous
Not applicable

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.

0 Likes

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

0 Likes
Anonymous
Not applicable

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.

0 Likes

I think this is unlikely to be the problem, for 2 reasons:

   
        
  1. 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.
  2.     
  3. Lowering the baud rate does not get rid of the errors, but switching to 16x oversampling does gets rid of the errors.
  4.    
   

 

   

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

0 Likes
Anonymous
Not applicable

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.

0 Likes

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.

0 Likes

Hi Bob,

   

Did you manage to get a chance to look at my code?

   

Hugo

0 Likes
Anonymous
Not applicable

Have you considered EMI could be effecting the data errors?

0 Likes

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.

0 Likes
HuEl_264296
Level 5
Level 5
First like given 25 sign-ins First solution authored

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?

0 Likes
Anonymous
Not applicable

I would file a case and see what they say. 🙂

0 Likes