Issue with sending TXT file through serial communication (UART)

[gkim83]

Hi LabView community,

I have been working on making a test software for an embedded software in a circuit board. It's UART communication between my PC (LabView test software) and the board (embedded software). Here is one example showing how it works. If I send a char H to the board, it replies back to me with temperature and humidity reading from sensors on the board.

Couple weeks ago, I faced to an issue sending the whole TXT file to the board. What I have implemented is reading the TXT file line by line and it converted to an array of string. Each element of the array of string, which is each line of TXT file, goes into the VISA WRITE as inputs. 

The total number of lines in the TXT file is 6083, and the format is like:

@0000 (memory address)

(machine code in HEX)

@0040

(machine code in HEX)

@16xxx

(machine code in HEX)

@17xxx

(machine code in HEX)

q

The q is the termination character of the data receiving for the embedded software. As soon as the embedded software in the circuit board gets the termination character, q, it stops receiving and send an acknowledgement message saying the download was successful. 

My problem is not getting to the point. It seems like the embedded software does not get the q from my LabView software.  

One thing I have found is if I delete the code,

@16xxx

(machine code in HEX)

@17xxx

(machine code in HEX) 

and then extend the code of 

@0040

(machine code in HEX)

up to 6083 (same size as before), it works fine. 

Or if I shorten the length of the overall file like:

@0000 (memory address)

(SHORTEN machine code in HEX)

@0040

(SHORTEN machine code in HEX)

@16xxx

(SHORTEN machine code in HEX)

@17xxx

(SHORTEN machine code in HEX)

q

it works fine (it's about 500 lines).

I thought it might be the buffer size issue, so I made the transmit and receive buffer in LabView as 1MB for each. Still does not fix the problem. 

Any of you had a similar issue? Any recommendation is welcomed as well.

I would much appreciate your advice.

Thank you.

[RavensFan]

Can you attach a small section of the actual text file you are reading?  What exactly do you mean by "machine code in hex"?  Characters 0-9 and A-F?  Or raw bytes that could be any of the 256 possible values?

What does "SHORTEN machine code in hex" mean in this context?

Attach an actual VI so we can see what you are doing.

[gkim83]

RavensFan,

The original code and shorten code are attached. 

For your information, this is for MSP Bootloader from TI. 

[gkim83]

Here is the LabView file I am using

[RavensFan]

I'd be surprised if you could test the transmit and receive buffers to over 1 million.  It seems to be too big of a number for any ordinary serial ports.  See if you get an error on the error wire after you set them to that.

I think one problem could be where you read the file.  It has Convert EOL turned on (right click on the Read Text File to change the settings.)  I'm wondering if a carriage return/line feed combination is being misinterpreted by your device.

Are you sure there isn't some internal limit on how much you data you can send to the device?  It might have not have enough memory space to handle larger files.  Or it may not be able to handle as large of a chunk of data in one block.

Can you slow down your VI where it sends the large blocks of data out to give it a little more time for the embedded software to process the data you just sent it?

You mention embedded software and circuit board, but don't give any details as to what company provides that.  Have you talked to them to see if they have any limitations on what the board can handle?

[gkim83]

Hi RavensFan,

I really appreciate your feedback. Here are my responses:

I'd be surprised if you could test the transmit and receive buffers to over 1 million.  It seems to be too big of a number for any ordinary serial ports.  See if you get an error on the error wire after you set them to that.

I was thinking that the buffer size might cause the issue, so I increased to 1 MB. I tried several different buffer size, but nothing could fix the issue. For the buffer in LabView, is it a FIFO buffer? 

I think one problem could be where you read the file.  It has Convert EOL turned on (right click on the Read Text File to change the settings.)  I'm wondering if a carriage return/line feed combination is being misinterpreted by your device.

It worked with other files having the same format. When the termination char, "q" goes into the embedded software on the board, some messages including a checksum calculation should pop up. Even the shorten version of the original file worked fine. 

Are you sure there isn't some internal limit on how much you data you can send to the device?  It might have not have enough memory space to handle larger files.  Or it may not be able to handle as large of a chunk of data in one block.

I had the same concern, so sent the TXT file through Tera Term, a terminal program and it worked fine not only with the shorten version, but also the original one.

Can you slow down your VI where it sends the large blocks of data out to give it a little more time for the embedded software to process the data you just sent it?

It seems like the error comes from the third memory jump (@16xxx) so I put one second delay before and after the jump. Still did not work.. 

You mention embedded software and circuit board, but don't give any details as to what company provides that.  Have you talked to them to see if they have any limitations on what the board can handle?

The embedded software and board are developed in the same company I work at. I talked with them and they said they don't see any problem on their side. The embedded software engineer showed me that it works with Tera Term.

[BertMcMahan]

Try firing up NI IO Trace before you run your program. You should be able to watch the serial communication and may be able to find what specifically triggers your error.

[gkim83]

BertMcMahan,

Thanks for the reply. It is great to know that NI has the tool. 

I am using LabView 2016 and this is only resource I can use. Is the IO tool compatible with LabView 2016?

[BertMcMahan]

Yes, I'm using 2016 too and have it installed. It is a separate program, not a component of LabVIEW. Try this:

http://www.ni.com/download/ni-io-trace-14.0.1/4914/en/

[gkim83]

BertMcMahan,

I downloaded and saw what was happening in the LabView serial communication. 

First, I ran the original text file. It showed that the termination character, "q" was sent out through VISA Write function, but I could not get the "End of file received...." message which means the embedded software did not get the character I guess? Not really sure. 

I tried it again with a shorten version for the second trial, and everything works fine. The character, "q" sent out with VISA Write and my LabView program got the "End of file received..." message through VISA Read function. This is what it is supposed to behave like.

What would make it happen that the character, "q" was not sent to embedded device...? The two screenshots for the result are attached.