EK-TM4C123GXL: Streaming UART data from IWR1642BOOST EVM to TM4C123GXL

HI,

  I'm not familiar with IWR1642. I have couple of comments. 

  - Do you have the same baudrate, stop bits, and parity bit setup the same between IWR and TM4C? If any of them is not matching then it will not work. 

  - The function UARTCharPut() takes unsigned char as the second parameter. You call UARTCharPut() by passing a 32-bit unsigned parameter. Can you cast it to unsigned char and see if that makes a difference?

  - What did you actually read on the variable "data"? Can you show what is read by TM4C?

  - Can you configure both IWR and TM4C to a slower baudrate (115200)? I wanted to know if the baudrate has any impact on the outcome. 

Hi,

 Is your problem resolved? I will change the status to close for now. If you still need help please answer my prior questions and the post will automatically reopen.   

Hi,

Sorry for the delayed response. We had some unrelated technical issues with our sensor that has now been resolved. 

As for my issue:

1. I do have the same baud rate, stop bits and parity bits. 

2. The code I am using now is not using the uint32_t variable. I am just using UARTCharPutNonBlocking(UART0_BASE,UARTCharGetNonBlocking(UART3_BASE));

3. The original issue I was experiencing is no longer occurring, what is happening now is when I am changing the system clock on the Tiva, I am getting a slight change in the stream of data output from the Tiva to the PC. Originally I was using the system clock at 100MHz, but after changing it to 50MHz, the stream was recognizable, yet still not in the format I was expecting. What is happening now is when I am altering the system clock, the data stream changes a bit. I believe it's an overrun error, however, I am unsure at what clock frequency I should be settling with in order to get all of the data I need.

If you have any insight on the system clock settings I should be using I would greatly appreciate your input. I am using the mmWave demo version 3.5 on the 1642, I do not know what the system frequency of the 1642 is, or if that should have an effect on the issue I am having. I believe the best results I am having are between ~8-10MHz.

The 8-10MHz range is what I am using on the Tiva

Hi,

Mitchell Bergman said:

3. The original issue I was experiencing is no longer occurring, what is happening now is when I am changing the system clock on the Tiva, I am getting a slight change in the stream of data output from the Tiva to the PC. Originally I was using the system clock at 100MHz, but after changing it to 50MHz, the stream was recognizable, yet still not in the format I was expecting. What is happening now is when I am altering the system clock, the data stream changes a bit. I believe it's an overrun error, however, I am unsure at what clock frequency I should be settling with in order to get all of the data I need.

If you have any in

Glad that your original issue is resolved. Please be aware that TM4C123 can only operate at maximum of 80Mhz. 100Mhz certainly will not work as it is out of spec.

Mitchell Bergman said:

I believe the best results I am having are between ~8-10MHz.

Also note that the baudrate clock is divided down from the system clock. Although the UART module supports fractional divide, a generated baud rate could be slightly different than another when compared to the intended baudrate (e.g. 921600) if the system clock is different (e.g. 50Mhz vs 8Mhz). I also asked you earlier why you choose 921600. Is this a requirement from IWR1642? I have no knowledge of IWR1642 and this is the reason I' asking the question. Why don't you try at a lower baudrate? I will suggest you try 115200 to see if it makes a difference. Of course, you will need to configure the IWR1642  side for the same baudrate unless IWR1642  has some built-in autobaud detection. 

I chose the baud rate 921600 because it is the default recommended rate for the sensors data port, though it is configurable and I have tried changing it, which didn't help.

I am getting an Overrun Error though, does this mean I am overflowing the buffer? If so, how do I get around this?

Should I be using UARTBusy instead of UARTCharsAvail, or both?

Also, could you explain the relationship between the system clock and baud rate further? I'm aware of the BRD equation, though I'm not sure if this means that if my clock rate isn't proportional within 6 decimal places, would that cause an issue with the generated baud rate?

Here is the code I'm using right now:

Thanks!

After a few experiments, I found that the error I get from using UARTRxErrorGet is returning 0x05. Which I don't believe is the Overrun Error, but if I'm not mistaken it's a Break and Framing error? Is this correct? 

Hi,

  I almost never see a break/frame error from any customers. Not really sure why you are getting it. Try to use UARTBusy , UARTCharGet and UARTCharPut instead of using UARTCharGetNonBlocking(). The non-blocking is mostly used with DMA. Also refer to the two examples in C:\ti\TivaWare_C_Series-2.2.0.295\examples\peripherals\uart.

Unfortunately, I believe those are the errors I'm receiving. 

I am using this code to see what my error is without debugging, which I've read is the reason I'm getting the overrun error. In this case, I'm not getting the overrun error, instead, I'm getting the break and framing error.

I really don't know why the frame/break error. You are receiving data from IWR. You really need to examine on a scope if the waveform is correct or not. As I suggested before, run at a slower baud rate. What is the result? Also can the logic analyzer show the waveform when IWR is sending to the MCU?

- Who is running the serial.Serial?

- Can you poll UARTBusy instead of UARTCharsAvail like shown in the examples

Charles Tsai said:

I really don't know why the frame/break error.

Some thoughts on what may cause those errors:

1. Signal integrity errors at the higher speeds, e.g. slow rise times / ringing. A scope would help to check for that as already suggested.
2. A mismatch in the baud rate at the sender and receiver, which may cause the receiver to not sample the bits correctly. To analyse this need to check what baud rate divisors are programmed at the sender and receiver, along with the frequency tolerance on the input clock to the baud rate generators.