USB raw microcontroller not working well with VISA

[echarry]

Hi all,

Ideally I am trying to drive the MC9S08 Freescale microcontroller (USB integrated) according to one AppNotes from them (AN3582), using Labview 8.0 under Vista (I know that you'll say that they incompatible, but so far it hasn't given me any problems - hopefully is not the case for this one).

Labview implements the USB low-level drivers with VISA API. The system recognizes it fine (dodgy sometimes) and I can read the dev and conf descriptors (please see attached figures). This is why I'm bent to say it's not a Vista/LV8 problem. The firmware from the AppNotes is just a datalogger (GPIO's and ADC readings).

According to the text, there are 5 pipes -> 0: control; 1: bulk/Out (command); 82: bulk/In (Status); 83: bulk/Out (Data Out); 85: interrupt/In (Data In).  As you can see in the attached figures, I can communicate with the control pipe using MAX nicely.

The problem is that I cannot set the commands to access the modules ADC (0x02), GPIO (0x06), TPM (0x07) etc which are described in the AppNotes and in the code. And I've spent considerable time already in this trial and error scheme.  The ISR should jump to the specific routine in a switch - case, according to these modules. 

Although you don't know how the firmware is, as far as I understood, I assume that whenever I set a command (e.g. 06 00 0F using VISA write) -the four MSB LED's should turn on/off for example). Besides, if I want the actual ADC configuration it would be (02 02) and I should then wait for an interrupt event  in my intr-in pipe and then read the data out, correct?  I tried those two VI's (interruptusb and bulkcontrol) but no success. Again, I can read the control pipe, so I assume that I am not that far away.

However when I try to read the status from the EP1 or EP85, I get "unknown". And the error struc returns 0xBFFF003E (I/O error).

I am not sure about the VISA read/write and interrupt commands. As far as I know, write and read are just for bulk EP's and interrupt of course just for int transfers.

Is there any specific procedure before undertaking these commands? Should I set in the property node the bulk-out to 1 before doing the write/read (although it already recognizes it as EP1)? These commands go down through the pipe 1 bulk  right (command)?

Sorry for the extense E-mail, although any clue might be already fantastic. This is already driving me nuts.

Thanks so much,

Edgar Charry

[TobyHex]

Hey Echarry,

I have been looking into your issue and I have some recommendations on articles that I would like for you to look at. Specifically within these articles the first one is for What is the Difference Between USB Raw Control and USB Raw Bulk? I am pretty sure you know these differences, but the links at the bottom of the page may prove useful. As for the error that you are experiencing, I have looked that up and found Error BFFF003E Occurs after a VISA Read/Write

that explains your error as well as a way to fix it. Let me know if this helps, as well as a more specified question that I can look into if you have more for me.

Thanks again and have a great day.

Regards,

Nicholas K

[echarry]

Hi Nicholas,

Thanks for the reply!

They didn't seem to help me out here. I'll keep trying.

Btw, to I need to set a buffer size for a USB raw communication? Or even flush my buffer before reading? I thought this was only necessary for RS232/GPIB comms.

Question is: why I can read the descriptors from my device using pipe 0 and by reading my other pipes' status I get this error? Maybe the device is in another state, than configured. So that'll mean, that I can read the device/interface/conf descriptors, but I just cannot control it.... I don't know..

Any ideas?

Thanks!

[echarry]

Nicholas,

Some other symptoms:

1) VISAIC sees my device, but I cannot see the number of my in-endpoints;

2) Although I manage to control the LEDs of the board, I just can't read data back from my microcontroller (pipe 84) my VISA read (it returns timeout) - I' ve  checked my firmware and with my LED I checked that data's being trasfered over indeed. So I am bent to believe it is LV problem. (Detail: in MAX, the only pipe that works for me (nr 1) doesn't show up).

3) Below you can see

a. NI-Spy when trying to read the initial status from my pipes

1.  VISA Get Attribute ("USB0::0x15A2::0x0005::NI-VISA-10002::RAW", USB_INTR_IN_PIPE, 130)
Process ID: 0x00000878         Thread ID: 0x0000108C
Start Time: 00:33:29.289       Call Duration 00:00:00.000
Status: 0 (VI_SUCCESS)

 > 2.  VISA Get Attribute ("USB0::0x15A2::0x0005::NI-VISA-10002::RAW", USB_INTR_IN_STATUS, -1)
> Process ID: 0x00000878         Thread ID: 0x0000108C
> Start Time: 00:33:29.289       Call Duration 00:00:00.001
> Status: 0xBFFF003E (VI_ERROR_IO)

3.  viGetAttribute (0x083CAF98, 0x3FFF018F, VI_FALSE)
Process ID: 0x00000878         Thread ID: 0x000011F0
Start Time: 00:33:29.741       Call Duration 00:00:00.000
Status: 0 (VI_SUCCESS)

b. My settable attributes from MAX.

VI_ATTR_TMO_VALUE = 2000
VI_ATTR_MAX_QUEUE_LENGTH = 50
VI_ATTR_TERMCHAR = 0x0A
VI_ATTR_TERMCHAR_EN = VI_FALSE
VI_ATTR_IO_PROT = 1
VI_ATTR_SUPPRESS_END_EN = VI_FALSE
VI_ATTR_USB_MAX_INTR_SIZE = 8
VI_ATTR_USB_CTRL_PIPE = 0x0000
VI_ATTR_USB_BULK_OUT_PIPE = 0x0003
VI_ATTR_USB_BULK_IN_PIPE = 0x0084
VI_ATTR_USB_INTR_IN_PIPE = 0x0082
VI_ATTR_USB_ALT_SETTING = 0
VI_ATTR_USB_END_IN = 5

Thanks in advance,

Edgar Charry

[TobyHex]

Hey Edgar,

I want to try and simplify your problem down. From what I understand you are able to communicate to your microcontroller just fine, its the communication back that is causing the problem correct? If that is the case lets try simplifying your code down. If your board has some kind of potentiometer on it, lets try just getting it to send that information back and just do a VISA read within LabVIEW. I also would like for you to take a look at this forum titled  GEtting started with USB communication via VISA. Which has many great examples on using VISA with USB as well as a USB sniffer.

Regards,

Nicholas K

[echarry]

Nicholas,

Thanks for the reply.

As a matter of fact, I managed to get my micro finally going with a bit of thinking and luck. I was practically stalling my endpoint, requesting many reads faster than it could answer back.

However I had though a question: I want to sample data at 1khz from my sensor. This means in the best case I have to poll my USB device at 1ms, as I am using interrupt endpoints. Right? On top of that, there's LV programming, Windows managing process etc.

Therefore,  I am also using a producer-consumer struc, and reading out data with a timing loop at 2ms. which will give me max 500 Hz. Which is also Ok.

With the read signal, I need to low-pass filter it with a fc of 10Hz. My signal has freqs of 1-2Hz and I need to separate DC to AC. So I use another low-pass filter of 0.3Hz (DC) and a high-pass filter for the AC with the same cut off frequency (using a fs of 500Hz now). However I just can't see the first noisy ignal, smoothed. I did it in the analog domain with the same order and fc and worked fine!

As attached I send you a copy of the VI. Sorry about the mess. Wanted to get the signals up and running.

Any suggestions in regard of this processing is welcomed.

Thanks in advance.

Edgar Charry

[TobyHex]

Hey Edgar,

I am happy to hear that you now have communication with your microcontroller. If you do not mind being a little more specific on your question so that we can narrow down what it is we are trying to do that will be very helpful in getting you an answer as soon as possible. Also, another resource that might be useful to you is the manufacturer of the microcontoller, as they would have specifics on their onboard sensors that I would not, and could give us a little more detail so that we can get you up an running.
Thanks again and have a great day!

Regards,

Nicholas K

[echarry]

Hi Nicholas,

In what the sensor concerns, it's fine.

Basically I am using a timed loop to read data from a Queue at 2ms. I set then a butter/LPF with fc at 10Hz (I know that my signal lies between 1-2Hz anyway). But it filters the whole thing! The amplitude gets decreased by almost everything!

I also wouldn't know what would be better: logging the incoming data in one 1D array and filter it as a whole, or filter my signal ptbypt as a new byte comes in.

Any suggestions are welcomed!

Thx

[G-Money]

echarry,

From a performance point of view, it is better to build the data into an array and then filter the whole thing. Calling the manipulation every iteration for one data point is overkill. As for filtering being the resoultion you want, you would not be sure until you try it. Glad you got your microcontroller running and I am very impressed that your LabVIEW 8.0 is running on Vista. Hope this helps!!

[echarry]

HI G-Money,

Thanks for the message. I was initializing my ptbypt filter VI every loop, without need. 😃

I had though other 3 questions:

1) I imagine it's though important to initialize my filter for the first time using the "First Call? Function". Although not initializing it, still filters my signal fine. The Butterworth VI's initialize button just hands over the coeffs for the IIR cascade. Is this correct?

2) Regarding the performance: I found though the following manual " GETTING STARTED WITH LABVIEW POINT-BY-POINT VIS".

I wanted my signal to be displayed in real time. As far as my LV's knowledge goes, the waveform chart is faster. So, after reading out from the queue every 2ms, a new sample is filtered and displayed. Thus I wouldn't need to wait for my whole array to be filtered and displayed.

a. Correct?

b. What displays faster: wiring an array to the waveform chart or just one point (I'm naturally bent to say that just one point, but I am not sure about which case to choose)?

I disregarded using the waveform graphs, because it slowed the displaying update down.

3. Do I need to use Queues at all, even using USB interrupts? I assume everytime data is needed to be sent from the device to the host (interrupt), it's not lost. Naturally because the host polls the device and request this data to be sent. And what the processing on the host concerns, if I just log this incoming packet into an array, then it wouldn't be lost at all, even during the processing.

Does this make any sense?

Hopefully I had made myself "understandable".

Thanks !!!

Edgar Charry