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.

Is USB0ID PB0 polled during ROM boot loader with erased flash.

Guru 55913 points
Other Parts Discussed in Thread: EK-TM4C1294XL, TPS2052B, TM4C1294NCPDT

Notice the EK-TM4C1294XL launch pads ICDI does not have USB0ID connected from the Host USB port yet the OTG port does.

Will the ROM boot loader react to USB0ID PB0 signaling when a Host would then control the PB0 signal during a DFU cycle direct to the TM4C1294 via USB0?

 TM4C1294 USB0ID PB0:

This signal senses the state of the USB ID signal. The USB PHY enables an integrated pull-up, and an external element (USB connector) indicates the initial state of the USB controller (pulled down is the A side of the cable and pulled up is the B side).

Host is on what side A/B, or does it even matter. Good to know when making a custom board where the USB port multitasks between host/device modes and or may have multiple end points asserting over the same differential pair..

Is RBL protocol scenario more a dynamic function derived from the run time DFU device driver at the Host side. If that is the case the PB0 signal will not come into play during RBL?

  • Hello BP101

    PB0 is not polled. However to ensure that it is not checked by the USB controller and that is available for GPIO function when in RBL I would still need to check. Good question!!!!

    Regards
    Amit
  • Hi Amit,

    "However to ensure that it is not checked by the USB controller "

    Was only guessing the USB0ID PB0 Analog input signal was being polled by the USB control register during clock times regardless of RBL being invoked/ running.

    Perhaps the default USB reset configuration does not enable PB0 to be checked when the RBL is invoked. It would seem plausible engineers considered the USB port could also be used in Host mode by the application not just for binary IPL via RBL.

    The difference for leaving USB0ID disconnected from the ICDI TM4C123 connector is it runs in device mode but with multiple channels enabled (port bundle mode) rather than only a single channel mode as might a device or host require/provide? Cisco does similar on gigabit switches, that is configures port bundles on the back plane to speed up throughput.

    One way to find out move JP1/2-3 (OTG) and try to flash target via RBL and LM-Flash via USB/DFU?
  • Hello BP101

    I checked the ROM code and the PB0 pin is not being configured. This would leave PB0 available for GPIO function.

    The DFU is a Device implementation only.

    Regards
    Amit
  • Hi Amit,

    "The DFU is a Device implementation only."

    By that you are inferring the data transfer speed during flash is 250kbps, one channel USB mode? Seems odd the USB controller specification v2.0 boasts 12mbps or 1.5mbps per channel in other TI data sheets. Then when the channel is configured for host mode we can expect the higher transfer speed at 1.5mbps? The best speed reported by Bulk USB driver in device mode is 250kbps and is reporting 4kbps throughput printing USBprintf() lines.

    Never had the opportunity to go under the hood in the past and see what was making USB possible. The 8 individual configurable channels is good news for USB Hub connections on the OTG port. Seeing is believing as they say but so far very impressed by the data throughput, even at 4kbps printing 10 times faster than virtual COM port serial at 460800 Baudot.

  • Hello BP101,

    I would suggest USB.org DFU specifications for DFU specific question. For speed specific question Mathieu did explain it well on his post.

    Regards
    Amit
  • Hi Amit,

    Sorry for some confusion here on my part.

    Was referring to DFU dynamic firmware update built into LM Flash Programmer, manual selection setting (USB/DFU). If not mistaken Mathieu did not explain in clearly what mode or how 5.3Mbps USB speed was achieved, CB1 asked that as well.

    The reported 5.3MBPS seems to contradict the TPS2052B datasheet topic any single channel does not exceeding 1.5MPS. Yet 8 x 1.5MBPS=12MBPS as reported in TI datasheet TPS2052B page 20. Perhaps the TPS2052B 2010/11 datasheet is referring to USB v.1.0 specification and should be updated?

    UNIVERSAL SERIAL BUS (USB) APPLICATIONS:

    The universal serial bus (USB) interface is a 12-Mb/s, or 1.5-Mb/s, multiplexed serial bus designed for low-to-medium bandwidth PC peripherals (e.g., keyboards, printers, scanners, and mice). The four-wire USB interface is conceived for dynamic attach-detach (hot plug-unplug) of peripherals. Two lines are provided for differential data, and two lines are provided for 5-V power distribution.

    TM4C1294NCPDT datasheet:

    ■ USB 2.0 high-speed (480 Mbps) operation with the integrated ULPI interface communicating with an external PHY

    Text does not specify what any single channel port speed might be possible. 

    Do we need to sign and accept NDA just to be able to disclose the USB individual channel speed in the forum?

  • Hello BP101

    The bandwidth can be taken up by one channel if only one channel exists. Note that in the USB Spec the max bandwidth per transfer type is given. It is not split as per channel as implementations can have more than one channels (in TM4C129 it is 2 x 8 endpoints)

    For TM4C129 the NDA is required to get the full USB section.

    Regards
    Amit
  • Hi Amit,

    > The bandwidth can be taken up by one channel if only one channel exists.

    Just for giggles what is the entire bandwidth of a single channel without an external PHY? Seems the USB Bulk device example lower layer device configuration renders a throughput that tops at 250kbps. That is by using USBBufferwrite() to immediately transfer packets and not by direct writes into the FIFO and later issuing USBBufferDataWritten().

    Not complaining as 4kbps again is 10x faster than UARTprintf(), now comprehend UART was interfering with EMAC DMARIS codes 99525/98496, most often leading to exception 11. Seems those 2 AIS codes are normally occurring on a intermittent basis relative to local packet traffic. Possibly the slower but constant UARTprintf() accesses at times was slowing down the EMAC DMA engine and the APB databus had some sort of a collision. We still use the UARTpintf() but only to monitor and log Exosite connection errors such as AIS 99525.

    Back to USB land:
    Sounds plausible the bandwidth setting is part of HNP for the SRP handshake requesting a Bulk secession and we end up at 250kbps? So the transfer bandwidth is relative to one of the individual types?

    4 transfer types: Control, Interrupt, Bulk, and Isochronous

    16 endpoints including two hard-wired for control transfers (one endpoint for IN and one endpoint for OUT) plus 14 endpoints
    defined by firmware along with a dynamic sizable FIFO support multiple packet queueing.

  • Hello BP101,

    I will take the example of USB High Speed. The Max bandwidth is dependent on the type of transfer and the packet size. In the USB2.0 Specification this corresponds to the data in Table 5-3, 5-5, 5-8 and 5-10.

    Now this is the theoretical maximum. The application SW overhead of the host and device would result in numbers lesser than the theoretical maximum. In the USB Bulk example there is no HNP/SRP. It is the manner in which application is written. The end point is only invoked when there is a transfer. So once there control end point is done with enumerating and it is not called by the application, it does not participate any further.

    Regards
    Amit
  • Hi Amit,
    >The end point is only invoked when there is a transfer.

    Have noticed a few times that the Bulk client echo mode (-e) will loose RX connection with target and error 31. Once that error the USB cable OTG port has to be pulled, close/reopen the client. Seems as if the initial device configuration of the Bulk client enumerates the Windows device driver endpoint via negotiation control packets. If the Windows client is launched prior to the target USB port being fully initialized there are no packets received at the bulk client when the target LP finishes initializing the USB port. Bear in mind we are continuously polling for RX packets to UARTpintf() in the while loop of the Bulk client. The Target starts sending packets to the USB enumerated channel right after reset upon the USB port being initialized.

    If only the end point is being enumerated by the target it shouldn't matter if the Windows client is open prior to enumerating the only available channel. Since the channel is dedicated by set ID class type and cast by the USB device driver only to be received by the target USB. That said it appears the (bulk type) client invokes the low level driver sending control packets to the target USB one time and one time only. That seems to indicate a negotiation process takes place not from the target but from the client to the host USB port.

    That behavior seems to contradict the explanation that SRP and HNP are not being invoked.
  • Hello BP101

    I do remember one of Tsuneo's post mentioning the same as a property of Windows (and that the post on the TM4C Forum).

    Regards
    Amit
  • Hi Amit,

    Will have to search if Tsuneo resolved the issue thanks for the tip. :-)

    Opened new post USB Bulk client error 31.