Stellaris Virtual Serial Port driver error in Labview

My apologies, wrong picture. See the one below.

Hi jan2809,

It sounds like LabView doesn't like something about the serial port definition. It might be trying to set an OS port attribute that isn't supported/etc.

I do see a similar discussion on the NI community forums. If this is not your post, you might find the discussion useful for debugging. Particularly the suggestion at the end of the thread to remove VISA Configure Serial Port attributes to test if one of them is causing the problem.

http://forums.ni.com/t5/LabVIEW/VISA-Hex-0xBFFF001E-The-specified-state-of-the-attribute-is-not/td-p/2712151

Hi Mitch,

Thanks for the link to NI community forum. I will follow it and let you know if I have any luck.

It is importany for me to solve it as we have a number of Tiva boards to be used in students lab with labVIEW.

Jan

Hi Mitch,

It is still unresolved, although there is some interest from NI.

Would it be possible to send a Tiva Launchpad to NI or should I do it myself?

http://forums.ni.com/t5/LabVIEW/VISA-Hex-0xBFFF001E-The-specified-state-of-the-attribute-is-not/m-p/2749190/highlight/false#M811642

Jan

Hi Jan,

Monitor the LabView activity on the COM port, and find the exact "attribute" on which LabView fails to take from the COM port.

Unfortunately, PortMon, a popular serial port monitor, doesn’t work on 64-bit Windows.
Instead, apply API monitor

API monitor
http://www.rohitab.com/apimonitor

1) First, run LabView up to the point just before you see the error dialog.
2) Run API monitor, and check "Data Access and Storage" and "Devices" filter, to capture activity on COM port.
3) Go on LabView and see the error dialog.
4) Switch to API monitor, find error on the monitor log.

API monitor will show you communication API on which an error occurs.

Windows Communications Functions
http://msdn.microsoft.com/en-us/library/aa363194.aspx

What is the Comm API?
When we know the Comm API, we can specify the "attribute" LabView requires.
And then, back to the Stellaris firmware, we can modify the source to support the "attribute".

Tsuneo

Hi Tsuneo,

 Thank you for your help.

I have tried to follow your instructions, but had no luck.

The error occurs immediately after starting labVIEW (or it doesn't even start at all I think) and I am not able to see any related processes captured.

I contacted the labVIEW support and will see in they can do anything about it.

Thanks again.

Jan

Hi Jan,

I had asked our field reps to try and get some assistance from NI on this issue. Unfortunately, it appears the best means of getting assistance from NI will be through their support channels which from your last post I assume you have started.

I went ahead and pulled the LV evaluation down and believe I got enough installed to replicate what you are seeing. I think this is the result of the Tiva Launchpad's use of Microsoft's USBSER.SYS driver to provide the virtual serial port through a basic implementation of the Communication Device Class' Abstract Control Model (CDC ACM).

Based on NI's documentation here, it looks like LabView uses SetCommState() and then verifies the baud rate with GetCommState(). From a small amount of research into these APIs, it looks like GetCommState() will always return the default baud rate in this case as this is a "virtual" COM port. This likely explains why 9600 baud works as LV is able to verify it with this API Set/Get exchange.

Launchpads that use FTDI chips for this feature are able to make use of the FTDI driver stack which includes a more full featured 'faked' COM port and don't use the in-box USBSER.SYS driver. I believe this is why they don't exhibit this problem.

I'm not savvy enough with LV to determine if one can wire things up to ignore the error from the baud rate change. There might also be a way to force LV to always use the driver port settings (as setup in the device manager's "port settings").  One of those two options might get you past the issue.

Hi Mitch,

Thanks, but I have no luck so far.

The second option - setting default baud rate to 115200 doesn't work (see attached picture).

Don't know how to try the first option, can you be more specific.

Jan

Stellaris Mitch said:

Based on NI's documentation here, it looks like LabView uses SetCommState() and then verifies the baud rate with GetCommState().

You assume that SetCommState() puts just single USB Request (Set_Line_Coding), but it’s wrong.
usbser.sys (Windows in-box CDC-ACM driver) puts this Request sequence for single SetCommState() call.
- GET_LINE_CODING
- GET_LINE_CODING
- SET_LINE_CODING
- GET_LINE_CODING
- SET_CONTROL_LINE_STATE(0x02) - RTS:1, DTR:0
- SET_LINE_CODING
- GET_LINE_CODING

And then, SetCommState() could always fail, if the device wouldn’t return the new line coding (ie. baudrate, data bits, parity, stop bits), set by SET_LINE_CODING.

The solution of this problem is found in \qs-logger\usbserial.c
- GetLineCoding() returns the same parameter set by SetLineCoding
Here is the code snippet, taken off from this file,

TivaWare_C_Series-2.0.1.11577\examples\boards\dk-tm4c123g\qs-logger\usbserial.c

//*****************************************************************************
//
// The line coding parameters for the virtual serial port.  Since there is
// no physical port this does not have any real effect, but we have a default
// set of values to report if asked, and will remember whatever the host
// configures.
//
//*****************************************************************************
static tLineCoding g_sLineCoding =
{
    115200, USB_CDC_STOP_BITS_1, USB_CDC_PARITY_NONE, 8
};

//*****************************************************************************
//
// Set the communication parameters for the virtual serial port.
//
//*****************************************************************************
static bool
SetLineCoding(tLineCoding *psLineCoding)
{
    //
    // Copy whatever the host passes into our copy of line parameters.
    //
    memcpy(&g_sLineCoding, psLineCoding, sizeof(tLineCoding));

    //
    // ALways return success
    //
    return(true);
}

//*****************************************************************************
//
// Get the communication parameters in use on the UART.
//
//*****************************************************************************
static void
GetLineCoding(tLineCoding *psLineCoding)
{
    //
    // Copy whatever we have stored as the line parameter to the host.
    //
    memcpy(psLineCoding, &g_sLineCoding, sizeof(tLineCoding));
}

Tsuneo

Hi Jan,

Does it give you the same message if you tell it to use the Windows settings (the other radio button)?

Hello Tsuneo,

Thanks for the information. I had not actually made that assumption because I have seen the list of CDC events that get generated for these calls. But it does look like the line coding tracking is the cause of this LV issue. The ICDI firmware does handle these events but it looks like it might be trying to be a bit too clever.

I'm going to start the process of getting a respin for this firmware. This will also require a new release of LMFlashProgrammer to deliver the update to the boards.

Hi Mitch,

Yes, there is the same error message when using Windows setting.

Jan

Stellaris Mitch said:

I'm going to start the process of getting a respin for this firmware. This will also require a new release of LMFlashProgrammer to deliver the update to the boards.

Hi Mitch,

Please excuse me being impatient, but what is the typical timeframe required for a respin to be finalized?

So far I have many emails from NI local guys, but nothing productive on their side.

Jan

Hi Jan,

After some scheduling issues, I made and tested the ICDI firmware change last week. It was built late last week and should clear QA late today or tomorrow. Once I see it go live on the website, I will post on your thread here and let you know.

And for information purposes, the problem:

Prior to this change, the ICDI firmware reported its calculated baud rate when asked. This, of course, can be +/- 1% of the set baud rate. It appears most of the serial terminal applications don't read back the baud after setting it or they accept the +/- 1% within the error margin. LabView apparently does not - it generates an error if the returned rate does not exactly match. This is why 9600 worked (and 2400) but none of the baud rates would work within LabView.

Hi Mitch,

Still no solution.

Have the answer from NI

"Ive heard back from our R&D. And the response as below;

This problem seems to be something that TI is looking to fix with future firmware updates. It seems to be rooted at the fact that our functions do an actual check of the baud rate set and will not proceed unless the actual baud rate is what we set it to. TI mentions that because there is a certain error margin, the baud rate is not actually set to what the user commands.

-This is a known issue for a large number of third party devices when setting baud rates. (CAR #182027). There is no current known workaround through VISA and it does not look like we will be fixing the issue before the next release for 14.0 since the CAR has been deferred.

One thing we COULD try is to handle the error and proceed with the program having ignored the error. You can look at ways to do this by the following

KB:

How Do I Ignore a Specific Error in LabVIEW?

http://digital.ni.com/public.nsf/allkb/BF72229C53F7633386256EDD0069331B

Let's attempt to ignore the error and just trust the driver to be able to communicate at the incorrect baud rate. Please ensure the customer knows that this error is being thrown because of VISA's double checking of the actual baud rate. This makes sure we are communicating at the baud rate we told it to. If the instruments has a certain error margin which VISA does not tolerate, it is unfortunate, but ensures robustness of the application."

 ....

and this is funny

"Please let us know how else we can assist."

unable to attached the vi, but still doesn't work

Hi Jan,

There is updated firmware available which should fix this problem by always returning the baud requested (if it was within a valid range) rather then the actual baud. You can update the ICDI firmware on the Launchpad boards with LMFlash Programmer.  That option is found on the "Other Utilities" tab. You will need to have the Launchpad connected via USB to the host machine with the DEBUG port.

I apologize this took so long to get posted and for the delay and notifying you in this thread.

Hi,

Thanks, but can you give me an updated link to LMFlash Programmer?

as the one in your latest post goes into version 1601 and does nothing.

Jan

Hi Mitch,

I am so glad and relieved, that I can press the green "Yes" button and accept the resolution of the problem

Thanks very much to you and everyone else involved. Much appreciate it.

Best Regards

Jan