This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C1233H6PGE: Explanation for USBD_STATUS_STALL_PID on the IN pipe needed

Part Number: TM4C1233H6PGE

Hello Everyone,

We have designed custom boards using TI microcontroller TM4C1233.
The microcontroller's USB module is programmed as a bulk device using one IN and one OUT pipe.
The USB part of the board's firmware is based on TI Tiva bulk example and the PC side receives data using Lmusb.dll on top of WinUSB driver.

The PC application receives data using the following line:
dwError = ReadUSBPacket(MainForm->hUSB, szBuffer, sizeof(szBuffer), &ulRead, 450, NULL);

The problem is that the receiver often times out and then the board reports USBD_STATUS_STALL_PID condition on the IN pipe.

Can somebody explain what conditions can cause the IN pipe stall if the Tiva USB library function USBDBulkPacketWrite is used?

Every hint would be appriciated.

The microcontroller is labeled:
980 YF
TM4C1233
H6PGEI
38AK3TW
G4

Thank you very much in advance

Best Regards

Nils

  • Hello Nils,

    It's difficult for me to offer any feedback based on what is presented. The USBDBulkPacketWrite API calls two driverlib API's which are USBEndpointDataPut and USBEndpointDataSend, and between these 3 API's there isn't an explicit place where a STALL would be issued. Rather the USBDBulkPacketWrite may return back a '0' if it fails to transmit the data. That could be what is occurring? But I don't know enough about how/when it is being called to say if that is the cause for the STALL being issued.
  • Hi Ralph,

    thank you very much for your fast answere!

    Heres a liddle overview about our problem:

    The above mentioned controller sits in an analytical device and controls actuators, sensors and slave pcbs via CAN Bus. It collects status Inforamations and sends them to a control software via USB. Our problem is now that after 3-4 week in customer installations,40% of the Boards show the described USB Stall behaviour. The strange thing here is that it is coming and going, so sometimes we se valid communication and sometimes the controller just stops sending data.

    On our way to determine the source of this we already did the following measurements:

    1. Observered the USB Bus with scope. Peakshape is good. When we see no communication from the controller, we see the "ping" from the PC and it looks good to, so we think the hardware up to the controller is ok.

    2. Checked the system clock and power supply. These where perfectly stable during the USB time outs.

    3. Checked the Can Bus slaves if these time out, but these send there data on time.

    4. Used Microsoft Message Analyzer to log the USB communication. Here we saw the "Stall" conditions.

    Our software devs took your advice and investigated in the APIs and the USB library source code shows that the three API functions are well guarded against misuse indeed.

    We now begin to suspect writes to EEPROM. During writes to EEPROM the processor does not fetch instructions from program flash. But is it possible that an EEPROM write stops or interferes with the USB module state machine operation?

    Thank you very much in advance.

    Best regards

    Nils

  • Hello Nils,

    Sorry for the delay in getting back to you, a lot of info to digest and wanted to mull over it a bit. Unfortunately I don't have any real answer still either.

    Regarding the EEPROM, I took the time to look over the EEPROM functionality and also the errata associated with it, and I don't see any way that the EEPROM writes could affect that. I get your train of thought, but EEPROM should not block USB from working unless that was specifically built into your firmware as a customization for your system.

    From a prior expert, the reasons for a stall would be:

    1. Functional Stall: where the device is unable to send or receive the data and is cleared when the host gets a successful control request response

    2. Protocol stall: When the host sends a unsupported control request like an incorrect Set Configuration.

    I think we can rule out 2. as that would be clear on the analyzer captures, right? So we are left with Functional Stall as the only reason. Now that said, from all your testing and what I have looked it, it is looking right now that finding the root cause is quite difficult, so I'd like to at least try and discuss what sort of solution we need to be seeking as well.

    When the STALL occurs, do you have to reset the peripheral entirely to get it back running? How do you get the device sending data again? I recall there being cases the device gets 'stuck' in Stall mode, if that is the real issue then that would be something I can try and help address.

    And along those lines, what would be an acceptable solution for this issue? Is this issue a matter of wanting to be able to recover very quickly if it occurs, or flat out avoid the stall from occurring at all?

  • Hi Ralph,

    first of all thank you for your great effort!

    We where able to resolve our issues due to your thoughts. This is what we ended up with:

    Our custom board acts as a middleman: it receives measurement results from a sensor every 200 ms via CAN bus, repacks it and sends to a PC via USB bulk connection. There was no problem on the CAN bus, the packets arrived regularly without any delay. On the PC, however, sometimes the receiver timed out after 450 ms. The Microsoft Message Analyzer showed that the IN pipe reported USBD_STATUS_STALL_PID condition at that time.

    Wedid get the communication going again by firstly commanding the Tiva to disconnect from the USB (the OUT pipe was working OK) and after some time to connect again. This forced reenumeration on the PC and eventually the communication was restored. Then we tried turning ON the AUTO_CLEAR_STALL option on the IN pipe policy of the WinUSB driver, this worked much more quickly. But the timeout problem still remained.

    The instrument also had to record how many hours it had worked. This record had to survive instrument power offs. It was decided to write this record into EEPROM and update this every half an hour.

    We found a programming error in the firmware - the EEPROM write occurred much more frequently (about once a second). After several weeks of continuous use the EEPROM write times were apparently increased enough to block sensor packet transmission and to cause timeouts on the PC. After correcting the error the boards behave normally.

    **************************

    The too frequent EEPROM write seems to be the real reason because:

    1, The new boards initially  work normally. The timeouts appear after some weeks of operation. Replacing the board initially helps, then after some weeks the timeouts return.

    2. Changing the timeout value from 450 ms to 210 ms made timeouts to appear much more frequently on one of the boards we got back from the field.

    3. The above board works normally with repaired firmware, if programmed again with original firmware then the timeouts returned.

    I shall send you the best regards and many thanks from our developers in Talllinn.

    We are currently waiting on more "defective" boards from the field and see if this will work on all of them.

    Best regard from Germany

    Nils Müller

    Our custom board acts as a middleman: it receives measurement results from a sensor every 200 ms via CAN bus, repacks it and sends to a PC via USB bulk connection. There was no problem on the CAN bus, the packets arrived regularly without any delay. On the PC, however, sometimes the receiver timed out after 450 ms. The Microsoft Message Analyzer showed that the IN pipe reported USBD_STATUS_STALL_PID condition at that time.

    Wedid get the communication going again by firstly commanding the Tiva to disconnect from the USB (the OUT pipe was working OK) and after some time to connect again. This forced reenumeration on the PC and eventually the communication was restored. Then we tried turning ON the AUTO_CLEAR_STALL option on the IN pipe policy of the WinUSB driver, this worked much more quickly. But the timeout problem still remained.

    The instrument also had to record how many hours it had worked. This record had to survive instrument power offs. It was decided to write this record into EEPROM and update this every half an hour.

    We found a programming error in the firmware - the EEPROM write occurred much more frequently (about once a second). After several weeks of continuous use the EEPROM write times were apparently increased enough to block sensor packet transmission and to cause timeouts on the PC. After correcting the error the boards behave normally.

    **************************

    The too frequent EEPROM write seems to be the real reason because:

    1, The new boards initially  work normally. The timeouts appear after some weeks of operation. Replacing the board initially helps, then after some weeks the timeouts return.

    2. Changing the timeout value from 450 ms to 210 ms made timeouts to appear much more frequently (on the board you did bring to Tallinn last Thursday).

    3. The above board works normally with repaired firmware, if programmed again with original firmware then the timeouts returned.

    I think we should thank Mr. Jacobi for his efforts and close the forum thread.

  • Hello Nils,

    That is very interesting behavior. I would have expected the issue to occur more quickly than months based on the description. Your posting also jogged my memory further and I want to share this post that explains some of the EEPROM write operations, may be helpful to understand for future development: e2e.ti.com/.../940674

    Thank for circling back with the resolution, and glad my feedback was able to somewhat help!