MSP-EXP432P401R UART Delay Question

[durnek60 0]

Hello,

 

I am in trouble with MSP-EXP432P401R Launchpad UART module when evaluating the board uart capabilities with the CCS -  DriverLib example:uart_pc_echo_12mhz_brclk.

To keep everything simple, on MSP side I have not made any modification on the example code. In LabVIEW using Example finder with keywords "Serial" the vi named: "Basic Serial Write and Read.vi" you can find the host VI for test.

My problem is: The elapsed time between sending a byte to the MSP UART and receiving a byte takes too long. In the above example, it takes 150 ms to get a reply from MSP432. 

I have tried the following:

• Changing the USB ports (type 2.0 | type 3.0) 
• MCLK speed, UART speed
• Changed the MSP432 launchpad and the Host PC too 

without any success.

The problem: It takes 150ms to get a first character from the MSP since I write into it. After the first byte arrived to host, all the remaining data can transfer fast and smooth it there are.

Later on, I have repeated the test with .NET based Serial Host application but nothing changed.

Here is my original thread from TI Forum: https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/417262

Unfortunately, I have not received any useful reply for almost a week. Could you help me to handle this issue? Thank you so much!

 

UPDATE:

 

I scoped the MSP432 UART pins (RXD, TXD) with Logic analyzer and attached the image of the result. You can see the MSP works very well, so the problem should be somewhere else. Have you every met similar situation? I suppose the PC side buffer issue... 

 

 

 

 

 

[bluehash 1,581]

The problem: It takes 150ms to get a first character from the MSP since I write into it. After the first byte arrived to host, all the remaining data can transfer fast and smooth it there are.

Later on, I have repeated the test with .NET based Serial Host application but nothing changed.

 

 

Here is my original thread from TI Forum: https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/417262

Unfortunately, I have not received any useful reply for almost a week. Could you help me to handle this issue? Thank you so much!

 

Rick is a member here too. @@Rickta59

UPDATE:

 

I scoped the MSP432 UART pins (RXD, TXD) with Logic analyzer and attached the image of the result. You can see the MSP works very well, so the problem should be somewhere else. Have you every met similar situation? I suppose the PC side buffer issue... 

 

 

According to the scope shot, you are seeing the MSP respond immediately right?

Are you using a USB FTDI cable between the MSP432 and the PC? Maybe try changing USB latency times in the USB driver settings.

Welcome to 43oh!

[spirilis 1,265]

Fwiw, I have seen similar type of behavior not with the MSP432 LP, but with the F5529LP in one of my experiments.  I suspect there's a common bug among all the FET firmwares (and/or the same folks are developing it), that or there is indeed a USB setting that could be changed here (doubtful, I think the onus is on TI to get this right, as FTDIs work fine here).

[bluehash 1,581]

Maybe he could disconnect the RX/TX lines from the FET and run them separately to the PC. That would tell us if it was the FET.

[oPossum 1,083]

In Windows there are several timing parameters for async serial (COM) ports that are configured with the SetCommTimeouts() API call.

 

https://msdn.microsoft.com/en-us/library/windows/desktop/aa363437

https://msdn.microsoft.com/en-us/library/windows/desktop/aa363190

 

These settings in combination with the buffer sizes use for tx/rx can have a significant impact on latency. This latency is in addition to that of the USB to serial hardware.

 

I suspect that it is not possible to modify this stuff when using LabView. Not sure about C#. It is, of course, possible to adjust all this when using C or C++.

 

As a practical matter you should probably be using a windowing protocol to limit the impact of latency.

 

http://en.wikipedia.org/wiki/Sliding_window_protocol

 

If you really need a low latency async serial connection, you could try a USB to MIDI cable. There is a 14 bit limit on most messages. See Firmata for an example of repurposing the MIDI protocol.

 

https://github.com/firmata/protocol

[dubnet 238]

@@oPossum Like your new pic