LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

XModem Transfer Problem

Hello,
 
My customer is using a Xmodem transfer protocol over Serial COM Port to program a chip. This procedure is done manually, but it must be performed automatically.
I have to send 2 different bin files with XModem on the chip. Using Windows HyperTerminal it works just fine.
 
Using the XModem methods from the RS232 library, I can successfully send the first file (which is only 11788 bytes). The card answers successfully some text on the COM port.
 
The problem occurs with the second file which is pretty large (708884 bytes). After a few moments, CVI tells me that it didn't receive an ACK from the receiver. I tried changing WaitPeriod, StartDelay, SetComTime with disabled timeout. I tried 128 or 1024 packet size. Nothing seems to work with that second big file.
 
Any clues on how to resolve this?
 
Here is my COM Port config :
 
BaudRate : 115200
DataBits : 8
StopBits : 1
Parity : None
Flow Control : None
 
One other note : the receiver sends "C" on the COM port all the time. I read somewhere on the internet that this is for CRC error correction. Is it supported by RS232 CVI library?
0 Kudos
Message 1 of 9
(8,259 Views)
Hello,
Unfortunately the Xmodem protocol is not supported in LabVIEW or LabWindows/CVI

However we can implement certain parts of the protocols. Please take a look at this KnowledgeBase article.

We can try a few things
1. Can you try sending the second file first? Lets see what happens.
2. Also can you take a NI Spy log of the transfer and post it here.

Let us know how this goes.

Christian A
National Instruments
Applications Engineer
0 Kudos
Message 2 of 9
(8,195 Views)


chris_amadasun a écrit:
Hello,
Unfortunately the Xmodem protocol is not supported in LabVIEW or LabWindows/CVI

However we can implement certain parts of the protocols. Please take a look at this KnowledgeBase article.

We can try a few things
1. Can you try sending the second file first? Lets see what happens.
2. Also can you take a NI Spy log of the transfer and post it here.

Let us know how this goes.



 
thank you for your reply!
1. I Can't. The first file is used to decode the second file. The first file is the "Programmer" and the second is the software load.
 
2. I don't know if I need any particular settings to log traffic through serial port, but I was not able to do it. If I open MAX, I can see the serial port with the good config. In NI Spy, no traffic is logged, even if I check everything in the log options.

 
I have found a solution using HyperAccess. I can send my files successfully. Maybe there are some differences in the XModem protocol of RS232 library for CVI 8.1 and the one used in HyperTerminal or HyperAccess.
 
 
0 Kudos
Message 3 of 9
(8,155 Views)
Hello,
When check the logging options in NI Spy are the VISA and LabVIEW boxes are check (see attached image)
Christian A
National Instruments
Applications Engineer
0 Kudos
Message 4 of 9
(8,127 Views)
LabWindows/CVI does support XModem, as you have found, in the form of the XModemConfig, XModemSend, and XModemReceive library functions. Unless you are operating on a real-time target (which I assume you are not), this library does not use VISA, so you won't have any luck with NI-Spy regardless of whether VISA or LabVIEW are checked.

Because there can be variations in XModem implementations, there may sometimes be issues when using these functions where the sender and receiver are not both using the CVI library functions. Though, it seems you can successfully send the first file, so I don't see why you shouldn't be able to send the next one. I would first recommend that you try a packet size of 128 and a wait period of 45.0, just to make sure there's not some large delay on the receiver side (e.g. while it processes a full buffer) that is causing the error. If that still doesn't work and you would like to debug further, I would recommend using Portmon to capture the port traffic into a log that we can examine. If you sent us the problematic file, we could try to reproduce the failure, but it's more likely that the receving device, which we don't have, plays an important role in the issue.

Mert A.
National Instruments
0 Kudos
Message 5 of 9
(8,087 Views)

I have a similar issue with LabWindows/CVI Xmodem where the receiving device sends 'CAN' and terminates the transfer (likely due to an overrun error). The issue is unrelated to baud rate as it occurs at 9600 and 115200 bps. The file can be uploaded sucessfully using Hyperterminal. Transfering a file to a different device using the same CVI function also works fine. I used Portmon to capture the port traffic as you recommended. What is interesting is that when Portmon is active, the CVI Xmodem transfer always works fine (but fails when Portmon is not running). It appears that the extra delay (introduced between each byte) allows for a sucessfull transfer.  How is this delay time (between bytes) set in the LabWindows/CVI Xmodem function?

0 Kudos
Message 6 of 9
(7,623 Views)

Hi Kotech,

wait_delay is what you're looking for.

Please look at the following link (search for delay)

http://ae.natinst.com/operations/ae/public.nsf/web/searchinternal/2ad81b9060162e708625678c006dfc62?O...

 

If you have any other CVI questions regarding this, please post them in LabWindows/CVI forum.

 

Regards,

Sammy Z.

0 Kudos
Message 7 of 9
(7,576 Views)

Hi Sammy Z,

 

Thanks for you response but the 'page cannot be displayed' for link you provided.

The parameter wait_delay is also described in the knowledge base article http://digital.ni.com/public.nsf/allkb/2AD81B9060162E708625678C006DFC62.

It states that "the receiver will call wait_delay and then send ack back to the sender" after reading the data packet.

What I am looking for is a parameter for the delay time after each byte when a packet is sent.

0 Kudos
Message 8 of 9
(7,504 Views)

Hi,

 

That was actually the link I was trying to send you.

 

In order to send the data bytes with delays in between, I suggest doing multiple writes with smaller chunks of data being written at a time. 

 

Regards,

Sammy Z.

0 Kudos
Message 9 of 9
(7,464 Views)