UART constantly receivein bytes even when nothing is sent...

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

cross mob
minoc_301866
Level 1
Level 1

Hi all,

   

I know it should be simple and straight forward to use the UART and I have not had any issues using it on PSOC 5 architecture.

   

However, now I'm using the PSOC 4 and it's slightly different.
I use PSOC creator version 4.1 Update 1 (4.1.0.3210). UART is version 3.20.
Target device is CY8C4024-LQI-S401 (4000S family).

   

It's a very simple implementation, I placed an UART block using the BASIC config.
In the advanced tab I changed the buffer size for rx and tx to 80 bytes each. Interrupts set to internal - so I'm assuming these are handled by the cypress software for the UART - and that I don't need to confirm/clear any interrupt flags in my app.

   

I use the UART_Start() to initialize UART.
I then use the UART_SpiUartGetRxBufferSize() and the UART_UartGetByte() functions to poll data from UART buffer.
As I understood all posts I have been reading about the UART this should be the way to do it.

   

Now, my question to this forum.
When setting breakpoint below the if-statement in the example code below, the UART_SpiUartGetRxBufferSize() always returns 1 and the UART_UartGetByte() always returns 0x000000FF.

   

What is it I don't understand here? If nothing has been received the buffer size should be zero?
The hardware RX line is pulled up and at 3.3V.

   

I also did some experimenting activating a handler, intercepting the RX_FIFO_NOT_EMPTY interrupt and it kept firing all the time.

   

Example code from my project:

   

First UART_Start() is called (which internally callse UART_Init() and UART_Enable().

   


void uartRxFrameHandler( void )
{
    uint16_t stat;
    uint8_t RxByte;
    uint32_t rxDword;
    
    if( 0 != UART_SpiUartGetRxBufferSize() )    // Any data in rx buffer?
    {
        rxDword = UART_UartGetByte();           // Rx status is embedded with received dword
        stat =   (uint16_t)(rxDword >> 8);            // Get status
        RxByte = (uint8_t)(rxDword & 0xff);      // Get the received byte

   

        ...
        /* Received data processed here - not relevant for this example */
        ...

   

    }

   

 

   

Looking forward to some input on this since the problem totally eludes me.

   

BR

   

Michel

0 Likes
1 Solution
minoc_301866
Level 1
Level 1

It's a hardware isse in my custom board. The FET switch slew rate has to be configured with resistor and capacitor. Every time I switch on the FET I get a 50 ns glitch on the UART RX line, probably it's coupled from the RS485 transceiver I have on this board. No software issue. Case closed 🙂

View solution in original post

0 Likes
4 Replies
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

As from your explanation all seems to be correct. Can you please post your complete project so that we all can have a look at all of your settings. To do so, use
Creator->File->Create Workspace Bundle (minimal)
and attach the resulting file.

   

 

   

Bob

0 Likes
minoc_301866
Level 1
Level 1

While digging into this I set up a new project on the CY8CKIT-042 where I added only a UART component with same settings and basic code as explained earlier. It worked fine. The I started a new project again, now on my custom hardware (where the problem was seen), implementing same fundamental UART and code. It also worked fine. So no issues with the UART firmware then.

   

Now comes the interesting part.

   

I have an IR-sensor that is driven with short bursts from a GPIO (P3.0). This output is conneted to a FET driver that drives the IR led, bursting 10 pulses (100us) with 100 ms intervals. The current through the LED is 60 mA. On the scope I can see these bursts when measuring on the RX input (P0.4), voltage level dropping from 3.3V to 2.3V, enough to inject a false RX message on the PSOC. What puzzles me is that the traces on the PCB are not close at all so coupling via traces on PCB is ruled out. And no ripple on the VDD is seen. The regulator is capable to supply 250mA and there are plenty of capacitors to handle short 60mA bursts. My theory right now is that his signal is coupled internally in the PSOC. This worries me a bit since I can't really turn UART of when scanning the IR LED. I feel the agony of trying to tweak the hardware, maybe using different ports to try to find a working hardware configuration. Painful, painful... Maybe it's time to discuss this issue with Cypress since it could very well be an internal routing issue...

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

I don't think its possible that the signals are coupled internally so that you can measure it at the _input_ port.

   

When you look closely at the PCB layout images, you can see that the trace from P3.0 runs straight over to J4 and then down to J12, crossing P0_3 on the way (on the primary side).

   

Also P3_0 is connected to the PSoC5 on this board (for the I2C bridge). This might have interesting side-effects.

0 Likes
minoc_301866
Level 1
Level 1

It's a hardware isse in my custom board. The FET switch slew rate has to be configured with resistor and capacitor. Every time I switch on the FET I get a 50 ns glitch on the UART RX line, probably it's coupled from the RS485 transceiver I have on this board. No software issue. Case closed 🙂

0 Likes