Interrupt issue with TM4C129ENCPDT

Hi Adrian,

I am not sure that this will help you, but did you change your predefined symbol from "PART_TM4C1294NCPDT" to "PART_TM4C129ENCPDT"?

- kel

There is no such difference in these two parts. Can you try with TI RTOS once instead of FreeRTOS?

Thanks

Along w/suggestions of others - and especially since one advises that, "There are no MCU differences" might a, "Serious check of your custom board's signal routings" be in order? 

Our small tech firm always exercises each critical input via small, simple test code - along w/"known good" input pin toggling - which should easily reveal such routing/connecting correctness.  

In summary - the hardware must be properly managed prior to any external signal's triggering an interrupt.    Your report does not reveal such test/verify...  

In all such cases - the MCU's interrupt software is, "Held hostage" to the arrival of a "correct" external signal - arriving at the specified MCU pin...

Hello Adrian,

Can you share your schematics for the same? Would be a good idea to have a second look.

Regards
Amit

Thanks all for your feedback.

A few things in response:

1. I do have test code to verify the signal path. In fact, I'm using the UART in normal mode (non interrupt driven) during startup and then switch over to interrupt driven mode. It works just fine until I switch over, proving out the signal path. Good suggestion though, cb1_mobile, signal routing is often underestimated.

2. I did switch the symbols over to the TM4C129ENCPDT, just like kel suggested. You did prompt me to go back and double check on that and I found that somehow the compiler is also pointing to "inc/tm4C123gh6pm.h", which I was using earlier. After a thorough search through my files I found at least one occurrence where I included this file. That's gone/changed now, but after double and tripple checking, CCS still thinks I'm using this file along with the correct one for the tm4C129encpdt...

The UART is working now, but I'm still having an issue with the USB interrupts not firing. It is most likely related to #2 above, but unfortunately the USB library handles interrupts internally so I can't check if it's using the correct ISR number...

I am wondering why it works just fine on the TM4C1294NCPDT based launchpad, but not on a TM4C129ENCPDT. It looks to me as though the compiler/linker is reading the files in a different order and somehow gets it right for the former, but not the latter. Is it possible that the Tiva driver library could cause this "different path" to be taken? I would assume that it is possible and understand that this is a fairly loaded question, but maybe someone else was running into this before...

Hello Adrian,

Did you make any project settings change?

Regards
Amit

Amit,

No, I didn't. In fact, if I have my symbols set for the TM4C129ENCPDT and insert code to check if the USB library has turned the USB0 interrupt on, it reports that it is in fact on. Yet, the USB's control handler is never called. I then connect the TM4C1294NCPDT launchapd and download the code WITHOUT CHANGING ANYTHING and the control handler is called right away after the USB library is initialized.

Even without a USB cable plugged in, the USB library should assert an interrupt at least once upon initialization, so given that on my custom board I don't get the interrupt at all, I don't think this is a hardware issue.

I'm a little puzzled as to why the USB library doesn't seem to be working on one board, but not the other. Again, even if I had the USB routing screwed up on my board, the library should still assert the control handler ISR upon initialization, right?

Is there any way to query the state of the USB stack?

Thanks,
Adrian

Hello Adrian,

W/o a USB cable connected a device will not have anything to report as there is no HOST to send a data packet. The stack I believe is the RTOS USB Stack? if that is the case then you can check with RTOS forum. But if it is the usblib from TivaWare you can pull in the usbenum.obj global state variables.

Regards
Amit

Amit,

I'm using the TivaWare usblib.

Even without a USB cable connected (i.e. no host), the usblib should still assert the USB0DeviceIntHandler, which in turn calls the ControlHandler function (I'm using the code from the virtual serial port example). This has worked without any issues at all on both the TM4C123 and TM4C129 launchpad and I verified that the interrupt occurs at least twice when the library is initialized and no USB cable is plugged in. On my custom board the interrupt is not called at all.
I just found that the USBDCDCInit function will return NULL if the initialization was not successful. I'll have to check that tonight. However, I just can't wrap my head around this... If the initialization fails, that would still not indicate a hardware issue (e.g. something on the PCB or external to the Tiva uC), but rather a software/driver issue, right?

By the way, I'm forcing device mode so that VBUS and ID pins are not used and this has been working without issues so far.

I'll take a look at the global state variables too.

Thanks,
Adrian

Hello Adrian,

I have a TM4C129ENCPDT which I can use to check your code. Can you send me over the binary file as I may not have all that is needed to compile the code.

Regards
Amit