RTOS/TM4C1294NCPDT: USB connection issue on custom board, working fine on EVAL board.

richard payne

Part Number: TM4C1294NCPDT

Tool/software: TI-RTOS

Ref:

I have working USB CDC driver on TI EVAL board but did not work on custom board.

From what I read in USBAnalyser, it seems to be connected but unable to respond to VID/PID number and thus highlight USB nodevice error (or similar). The custom board has isolation device of same design I used on LPC154x device which was working good. I'm unsure if USB-ID would have impacts. I have not installed any TI driver. I have latest version CCS 8.0 with RTOS and TIVA library as of today. My PC is window 10. The custom board has the same TM4C1294 device as in EVAL board.

The firmware was based on RTOS, TI example USB CDC driver that found in TI library, I copied over to custom workspace and added several codes (GPIO, Timer, SPI, etc) to achieve custom operation. Even with modified firmware, the USB worked fine on EVAL board (TM4C1294 boosterpack) but it did not work on custom board (see schematic).

In the custom board, I have 16MHz XTAL instead of 25MHz XTAL but I included the code to boost 16Mhz to 120MHz to match system clock (see code below). Later on I going to change 16MHz to 25MHz (on order) if this solves USB clock issue.

(1) Is there code to correct USB clock from 16Mhz, can u provide which one.

(2) Does USB operation has impacts because of different XTAL 16MHz and 25MHz, even the system clock is 120MHz.

(3) I'm open for idea how to attack the problem and have USB working. I have studied and worked on USB project via LPC1549 many years ago so I'm familiar with them.

#ifndef THISISEVALBOARD
    uINT32 ui32SysClock = SysCtlClockFreqSet((SYSCTL_XTAL_16MHZ | SYSCTL_OSC_MAIN | SYSCTL_USE_PLL | SYSCTL_CFG_VCO_480), 120000000);
#endif

over 6 years ago

0 richard payne over 6 years ago

Genius 4640 points

I have studied datasheet and TivaWare USB document about the SysCtlClockFreqSet and ruled out the clock frequency issue since it set to 480MHz on VCO so assumed it provide 60MHz as needed to USB. I do not expects 25MHz would fix it but I give it a try just in case.

I wish to note I cannot find SysCtlClockFreqSet or similar arrangement in EVAL USBCDC demo code, please explain how this firmware setup the clock correctly, do they use default value XTAL=25MHz, VCO=480MHz and SYSCLK=120MHz ?

I have studied the USBCDC configuration, where under CDC run on USB_DEVICE and it set to eUSBModeForceDevice which mean the ID and VBUS is ignored, so I ruled that out. I do not need to ties ID HIGH or LOW?, I just leave it floating unless there bug I'm not aware of.

I then compared the EVAL board circuit in term of D+ and D- polarity connection allowing isolation barrier to pass thro and found no defects.

I have not yet installed driver in window 10 and do not need to because the it worked on EVAL board.

I'm running out of idea, suggestion?.

One idea, I could hack the non-isolated GPIO line and connect to USB connector temporary to check USB response before isolation side. I like to try out other option before coming to that.

2nd idea is to remove 100R resistor R18 to isolate ID and isolate VBUS. I power the board elsewhere with VBUS isolated and ID isolated and see what response from Window 10 come out in context of <eUSBModeForceDevice>.

I appericate your input.....

0 Ralph Jacobi over 6 years ago in reply to richard payne

TI__Guru*** 131520 points

Hello Richard,

I will need to review this in more detail tomorrow in the office, but some initial comments:

1) There is SysCtlClockFreqSet code in the example I provided:

    // Run from the PLL at 120 MHz.
    //
    g_ui32SysClock = MAP_SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ |
                                             SYSCTL_OSC_MAIN |
                                             SYSCTL_USE_PLL |
                                             SYSCTL_CFG_VCO_480), 120000000);

2) 16MHz crystal should be okay, I haven't seen any reports of 16MHz not being compatible for USB. The only requirement for 25MHz crystal is for Ethernet.

3) Leaving the ID pin floating is fine as long as you aren't using OTG mode.

0 richard payne over 6 years ago in reply to Ralph Jacobi

Genius 4640 points

Hi Ralph
Thank I suppose to attached schematic, can you see it from your end, if not I can resend.
I found there bug in hardware, where it set to 240MHz VCO to provide 120MHz SYSCLOCK (as it handled by SysCtlClockFreqSet() ) instead of 480MHz, would this impact the 16MHz/25Mhz XTAL for USB?
R.

0 Ralph Jacobi over 6 years ago in reply to richard payne

TI__Guru*** 131520 points

Hello Richard,

I do not see the schematic, so please try and resend it, thank you.

When you mention bug in hardware, do you mean SYSCTL#22/SYSCTL#23? If so, no that would not impact the XTAL for USB.

0 richard payne over 6 years ago in reply to Ralph Jacobi

Genius 4640 points

Image deleted as requested

Ralph, If you can, please delete the image after you use it, thanks.

0 richard payne over 6 years ago in reply to richard payne

Genius 4640 points

0 Genatco over 6 years ago

Guru 54568 points

Hi Richard,

For one RTOS does not require Tivaware calls to set the MOSC or PLL for USB0 30Mhz clock minimum. Made same mistake some time ago when RTOS configure Boot Clocking options tab has check box to enable PLL, if enabled output is checked this disables PYSDIV clock divisor. Enable PLL check box works in reverse of typical PLL configuration, we leave it unchecked.

Also force device mode USB configuration may not work if VBUS pin has been partially compromised. That is PB1 is +5v tolerant but injection current perhaps can flow from PC USB port into PB1 if the MCU is powered down and the USB cable left in computers USB port. Only takes a few times and MCU pin PB1 becomes compromised.

0 Ralph Jacobi over 6 years ago in reply to richard payne

TI__Guru*** 131520 points

Hello Richard,

Thank you for all the details, I've had proper time to review everything presented.

So you are able to transfer some data packets but just not finish enumerating? If so, I am not sure the issue would be hardware related then. If the USB bus is able to communicate to the PC successfully I don't see why it would stop on account of hardware when it gets to the PID/VID exchange.

To that point, more specifically, if the 16MHz crystal had been an issue, you would not have gotten any USB communication working, so I believe your crystal configuration is fine.

Instead of focusing on hardware, I have a suggestion regarding software:

You mentioned not applying the TI Windows drivers before, have you attempted that in the mean time? If not, please try and apply the latest USB driver patch (will link below). Since this is a new board it would enumerate on a new port and it could be that the Windows drivers are now needed to handle. A LaunchPad's enumeration may have been saved from whenever it was first connected and so if it was correctly enumerated in Windows 10 before the updated drivers were needed then it would appear they are not necessary as you believed, but in reality it is quite possible that you would need them for your new design to allow it to properly enumerate.

software-dl.ti.com/.../SW-TM4C-2.1.4.178.PATCH-1.0.zip

Arm-based microcontrollers

Arm-based microcontrollers forum

RTOS/TM4C1294NCPDT: USB connection issue on custom board, working fine on EVAL board.