TM4C1294KCPDT: Access/download older TivaWare releases?

Hi Brian,

Your correct about a few changes in USB after 12573 but not in the USB +Vbus detection register. Please check this +Vbus bit toggles in debug register when USB cable is plugged in/out. I have 12573 if you really need it, recall it was USB data integer character type that was changed in later versions.

My application has the TM4C in USB Host mode only, so I assume that +Vbus detection is not applicable.

Are there any Tiva USB Library changes that would affect USB Host mode?

Note that the usb_host_msc example runs fine on my custom hardware, and detection of an inserted USB memory stick works fine. Of course, this example matches version numbers, whereas my firmware was working with the older library and I assume I need to make some changes to get it working with the newer library release.

By the way, my application needs to detect a USB_CLASS_VEND_SPECIFIC device.

Brian Willoughby said:

so I assume that +Vbus detection is not applicable.

The ID pin is sometimes not used such as on the ICDI and it doesn't know if GTO is the power source, hate that!

So your +Vbus supplies power to USB device in host mode but PQ4 has to be enabled to output enable U4 TPS2052 to switch +5v into GTO port. Recall EK-TM4C1294XL the USB host was enabled via GPIO PQ4 port configuration defaults to open drain, disabling +5v from GTO device mode default where +Vbus is input.

I changed a few things, using a TPS2051 and placing USB0EPEN on PA6 (pin 40) instead of PD6. I modified the source to reflect these changes, and as I mentioned the USB memory stick host firmware works fine. The memory stick that I'm testing with (which happens to be branded from a Texas Instruments conference!) lights up to show that it's receiving power, and of course the access commands work.

I also moved the power default detect signal to PA7, allowing hardware peripheral power fault input pin function USB0PFLT to be enabled. This is an improvement over the EK-TM4C1294XL reference circuit, which uses a generic GPIO on PQ4 for some reason. I adjusted the source to reflect the use of this official pin.

The problem seems to be that my registered USB_CLASS_VEND_SPECIFIC driver is never called, but the event driver is correctly called on removal of my other USB test device. I may have to find the usblib source and compile it in to my firmware so that I can debug the upstream functions. At the moment, I'm linking in the pre-compiled usblib, so I have no easy way to debug why my driver is not called.

Note that I get the same behavior on the EK-TM4C1294XL platform, with appropriate changes to the firmware source because of the differing pins. Two years ago, this firmware was recognizing my USB_CLASS_VEND_SPECIFIC device, using an adaptor cable to mate the USB micro-B jack on the EK to the necessary USB A jack for my standard device cable. I didn't have my custom hardware platform then, but now the firmware has stopped working on the EK when built with the new CCS and new Tiva USB library. I wish I had saved an old build, because it would be useful to see whether an old binary still functions.

Part of the reason I'm testing with the usb_host_msc example is to confirm that there are no unexpected differences between my custom hardware platform and the reference EK-TM4C1294XL. So far, I've not seen any failures that are specific to my hardware (i.e. usb_host_msc works properly on both, but my USB_CLASS_VEND_SPECIFIC driver fails on both where it worked on the EK two years ago).

Brian Willoughby said:

I also moved the power default detect signal to PA7, allowing hardware peripheral power fault input pin function USB0PFLT to be enabled.

Made same changes for custom PCB layout but haven't had chance to test USBOPEN actually disables or not when a USB0PFLT fault occurs. Seems likely USB0OPEN should automatically disable upon UB0PFLT assumed from the limited text of pin function in datasheet. Example of our circuit layout may perhaps help to compare both our thoughts of this function are similar or not. Our idea was to allow either host mode or device mode similar to the EK but enable TPS and PQ4 power fault function of USB. 

Brian Willoughby said:

Two years ago, this firmware was recognizing my USB_CLASS_VEND_SPECIFIC device,

If you have Windows 7 drive protection enabled you can roll the same project directory back but be sure to first copy your folder to safe location.

Brian Willoughby said:

The problem seems to be that my registered USB_CLASS_VEND_SPECIFIC driver is never called,

Likely USBID interrupt triggers a call to function in the host mode support module and the interrupt is not being triggered for what ever reason. Be sure to check the TM4C1294NCPDT errata sheet for possible issues in the UB0 peripheral that might lead to your suspicion.  Recall some mention of USBID and R74 being necessary to limit current in host mode support. Recall in device mode you can change method type of USB connection to forced or checked, defines exist for other ways of testing connection modes. Hope this helps you :)

BP101 said:

Made same changes for custom PCB layout but haven't had chance to test USBOPEN actually disables or not when a USB0PFLT fault occurs. Seems likely USB0OPEN should automatically disable upon UB0PFLT assumed from the limited text of pin function in datasheet. Example of our circuit layout may perhaps help to compare both our thoughts of this function are similar or not. Our idea was to allow either host mode or device mode similar to the EK but enable TPS and PQ4 power fault function of USB.

Note that the call to USBHCDPowerConfigInit() takes bit fields that seem to allow actions to be taken to disable USB0EPEN when USB0PFLT goes low or high, as appropriate. Most chips we might use seem to be active low, which is easily supported with the right bit field. I have not reviewed the usblib sources to confirm that this works. My brief tests of changing the examples seem to make things less functional, so I have more to investigate.

	USBHCDPowerConfigInit(0, USBHCD_VBUS_AUTO_HIGH | USBHCD_VBUS_FILTER | USBHCD_FAULT_LOW | USBHCD_FAULT_VBUS_DIS);

BP101 said:

Likely USBID interrupt triggers a call to function in the host mode support module and the interrupt is not being triggered for what ever reason. Be sure to check the TM4C1294NCPDT errata sheet for possible issues in the UB0 peripheral that might lead to your suspicion.  Recall some mention of USBID and R74 being necessary to limit current in host mode support. Recall in device mode you can change method type of USB connection to forced or checked, defines exist for other ways of testing connection modes. Hope this helps you :)

My concern here is that the firmware was previously working on the LaunchPad, but now it does not, so that seems to remove my hardware changes from question. Whatever changed has broken the code for both hardware platforms.

Note that I did add a capacitor to the VBUS lines on my LaunchPad to protect from a latch-up issue that is known by Texas Instruments. That may be the current limiting issue you mention, or it could be some other problem.

I will read the latest errata, and then code review the usblib sources while stepping through operations.

Brian Willoughby said:

My concern here is that the firmware was previously working on the LaunchPad, but now it does not, so that seems to remove my hardware changes from question.

Long as everything is exactly the same cables etc. would have to agree some kind of library issue around the ID pin seems likely. Couldn't hurt to verify in debug register if the ID bit changes state when USB cable is hot plugged. 

Thanks for the USB0PFAULT configuration will have to include that in the host hub application if ever get to that some day. Currently using USB0 for device mode and hope to port GCv2 GUI ever TI removes required JTAG control of target. I can PM you the original zip file v12573 if you like.

BP101 said:

Long as everything is exactly the same cables etc. would have to agree some kind of library issue around the ID pin seems likely. Couldn't hurt to verify in debug register if the ID bit changes state when USB cable is hot plugged.

My assumption is that the ID bit is only needed when using the OTG mode. For forced Host mode, I would expect that the ID bit is ignored.

Also, the usb_host_msc example runs on my hardware as well as the EK, so whatever detection is needed is working in both places. I suspect my problem may be related to the Vendor Custom Class.

BP101 said:

I can PM you the original zip file v12573 if you like.

I found a backup of v12573, so I do not need that. It would be nice to know whether TI has a download page for legacy versions - that can be very important for some projects.

Brian Willoughby said:

For forced Host mode, I would expect that the ID bit is ignored.

Question seemingly remains as to how the up stream host driver function service routines become aware a device has been plugged into the USB host port.

Best of luck to get it all working again!

Hi Charles,
That was Brian's request not mine.

Hi BP101, Brian,
Ok. In case you must retrieve an older version please let me know. As you know latest version with issues/errata fixed is recommended for development but I can understand some developments are frozen for certain tool/library versions.

FYI, last week I went back to my 2-year-old firmware source and linked against the old TivaWare library and everything worked. This tells me that the new compiler is not a problem, nor is the new Code Composer Studio. When I replaced the old TivaWare library with the latest, things stopped working. That strongly suggests that something changed in the library, but I need to double-check everything.

Unfortunately, my new firmware source was not magically fixed by linking to the old library, so I need to do some detective work to narrow down the cause. My plan is to slowly introduce new source into the old source that is working, until I find my change that prevents even the old library from working. Meanwhile, I will also double-check that I was swapping between the old and new libraries correctly, because it seems suspicious that there are so many non-working combinations.

Brian Willoughby said:

My plan is to slowly introduce new source into the old source that is working, until I find my change that prevents even the old library from working.

Feel your pain - yet your use of "KISS" to systematically test & observe - registers as your "best & fastest" means to identify & fix.

Believe (many) here are similarly "guilty" in not, "Adequately preparing for future and/or unexpected needs."     Your plight - and logical attack - drives home the need for such "defensive environment capture & saving."     Even when - and especially when - you & I are "sure" we'll never need this code/environment again!

While I agree w/"slow" introduction - always there's the desire for "faster identification and resolution."    

Surely you've considered (potentially) speeding/easing this resolution by first, "Isolating & then probing" those program elements which are the largest sized/most often occurring and share certain "common" elements!      Should those "pass" - your further "probing/testing" has been reduced in size/scope - which should speed/ease/enhance your path towards success.

Another, "Diagnostic Speed-Up via Code Reduction" method which has proven successful sees your, "Systematic Removal and/or Bypass of individual MCU Peripherals - and any/all related program "calls."    When your issue has been reduced to an individual MCU Peripheral - usually - the solution quickly follows!

Good luck... 

FYI, part 2: I was able to merge my new source into the old source and now it's working. I used subversion to create a branch from the old code and then only had a few merges to make to bring it forward. When I find did a "merge reintegrate" to pull the branch back into the trunk, I saw that the only real differences were in the project files.

Since the project files are rather difficult to decipher, I did not take the time to discover which settings were causing my problem.

The good news is that my latest code is working with the 2.1.0 library release.

The bad news is that I still cannot get my code working with the latest 2.1.4 library release. There still seems to have been some sort of change in the USB stack that is not working with my firmware and hardware.

My plan is to continue using 2.1.0 until I run into a bug that can only be fixed by upgrading to 2.1.4, although I don't know how I'll be able to find the necessary changes. Maybe I'll get lucky.