I have a critical situation with a product that is being updated to a Kinetis processor and production is being held up by this issue! A service request was entered weeks ago; however, the responses have not been helpful. I would really appreciate any help in resolving this problem!!
I have a program running on a Kinetis K601FN150 target board that is supposed to communicate via USB with desktop apps on both a Mac and a PC.
I am using Freescale's USB Stack Version 4.03 and CW 10.2.
The Kinetis program sends vendor requests over the Control EP and transfers data over a Bulk EP.
When the Kinetis program runs from a download over JTAG (debug and run) the program works perfectly.
When the Kinetis program runs from a POR, it enumerates successfully but fails after the Set Configuration call in the desktop app. It does not respond to the first vendor request on the Control EP. The result is the same when communicating with either the Mac or the PC app.
To try and determine where the program is failing, I placed print statements in both the USB_ISR() and the USB_Bus_Token_Cpl_Handler() routines.
These added print statements will cause the downloaded version to fail after the first sequence of a Vendor Request on the Control EP and an IN command on the Bulk EP. However I can cause the program to run correctly by using breakpoints in the desktop app to control the communication. This same use of breakpoints does not improve the program when it starts from a POR. The print statements reveal that the Set Configuration command completes normally but there are no subsequent interrupts received by USB_ISR(). This is also confirmed by the output of a USB analyzer which shows the vendor request being sent with the setup packet and the DATA0 packet - but there is no responding ACK. I have all the error interrupts enabled but no error interrupt is being generated either.
I am really at a loss as to what to try next but really need to get this working.
There must be something different about the downloaded version versus the one running out of reset
but I don't know what (although it seems like a timing problem).
Have you tried to do a reset in the debugger?
Where do the printfs go? If it is a uart is it interrupt driven and do the in interrupts handlers re-enable interrupts?
I once had a similar problem, and it had to do with the interrupt table not having the proper entries for a real reset.
No I haven't tried doing a reset in the debugger. How do you do that - do you mean a software reset? Although I haven't been successful in exiting the lowest power modes that exit through a reset.
The printfs are through a uart. Most of the Kinetis module software is generated by Processor Expert. The one main exception is the USB module. I let PE generate the initialization code and then used that in my program along with the USB Stack. The interrupts in the uart ISR are re-enabled. The print statements are only used for debugging purposes and are not present in the production software.
The interrupt vector table is created by PE but I do substitute or enter some of the ISRs with other routines such as USB_ISR in the case of USB.
It does seem that interrupts are either not getting re-enabled or re-enabled quickly enough.
Thank you for your response.
The icon in the debugger that looks like a red circle with an arrow in it. does a reset. Pause the program then click icon.
Not 100% sure how close this is to POR, but you might get a hint...
Quite often low power modes do not function properly in debug mode, so this may not be an indicator of an issue. The RM should say if this is the case.
There must be a difference between using the reset in the debugger and a POR. I tried it and the USB program ran correctly but still doesn't run correctly from a POR.
No I haven't had any breakthroughs yet.
However I have discovered that if I perform a POR followed by the reset and go commands using the J-Link Commander, the usb communication works great. If I perform the POR without the J-Link reset and go, the program fails - always at the same point and after a successful enumeration.
What is different about the reset that is performed by J-Link and a POR? And can I create the same J-Link reset in my code?
It is really strange because USB stack examples work with and without JTAG tool connected, after POR in the TWR boards. It could be something related with power timings in your board. You could try to put a delay in the main() before running the USB tasks, to delay the connection with the host and to understand if it is something related with that, When you perform a reset with JTAG power is stable.
I agree this seems very strange but if it were an issue with power timings, then why would the device be able to enumerate successfully first? The usb communication stops after a successful Set Configuration control write by the desktop app. I have tried using a breakpoint in the desktop app before calling the control write after Set Configuration but that doesn't have an effect.
I still haven't been able to get this to work properly. I really need some advice as to what to look at next. Please if anyone has any ideas, please let me know!
Here is a description of the current situation:
1 - The device's usb program is downloaded via JTAG. The device program will communicate correctly if the device program is started first and the desktop program is started afterward OR if the desktop program is started first and the device program is started afterward.
2 - The device is started from a POR. The device program will NOT work if the device program is started first and the desktop program afterward. However, the device will enumerate correctly with the desktop OS. But no communication occurs when the desktop program is started - the desktop program thinks the device is not responding. After instrumenting the device software I know that the SOF interrupts still occur but no token complete interrupts are generated. There are no error interrupts at any time and there is no stall interrupt. The output of a usb analyzer doesn't show a problem with the enumeration.The last sequence of the enumeration is a GetStringDescriptor and it completes normally.
3 - The device is started from a POR. The device program will work if the desktop program is started first and the the device program is started afterward. This unfortunately doesn't solve the problem because the desktop programs that the device needs to communicate with expect the device to enumerate first. I have this working only with my debug version of the desktop program on a Mac.
Below are two images from a usb analyzer that can hopefully help illustrate the issue. Any help would be greatly appreciated!
The first image shows the usb communication when there is success. The desktop software begins with the "Set Configuration" command (line 812). The first request for data from the device occurs at line 831 which is a vendor request. The device responds over a bulk endpoint. This is followed by another vendor request for the next set of data. The device responds again and this sequence continues until all requested data has been received.
SUCCESSFUL RUN - Running from JTAG
The image below shows an unsuccessful run. Enumeration proceeds normally and the desktop software issues the "Set Configuration" command at line 342. At this point the setup packet doesn't complete because the device does not ACK after the data stage. The host retries the command but again no response from the device. I think the device then sends the ACKs but since they are 3 bytes instead of 1 they don't serve to re-synch the communication. The device doesn't generate any other token done interrupts but does respond to the the SOF interrupts.
FAILED RUN - Running from a POR
I don't have a tower board for the particular processor I'm using. It would take some effort to modify the firmware to run on a tower board because of the other peripherals I'm using.
I do have boot code that is based on the MSD class that works fine and is used for firmware updating.I have removed the boot code for testing the firmware USB and am running the firmware starting at address 0x00000000.
The difference I see between the boot code USB and the firmware USB is how quickly communication starts after enumeration. In the case of the boot code the OS immediately initiates the MSD driver once the device has been enumerated. In the firmware case the user may plug the device into the host where it is enumerated but no further communication is initiated until the user starts the host program. As I mentioned before, if the host program is started before the device is plugged in, the USB program works fine - but if the device is plugged in first and then the host program is started the program does not work.
Just some suggestions of what I'd try:
In Processor Expert, do you have the option enabled to utilize POR defaults during initialization? I believe it is a setting pertaining to the configuration component, and it defaults to using POR values. If Freescale has a POR value defined incorrectly for your processor, then this should force all registers to be exactly what you'd want.
Assuming your debugger is loading a .mem configuration file (what the debugger uses to configure it's "reset" state), take a look at the the file, and compare the register settings it's using to what you have on power-up. Instead of using a "Codewarrior Download" debug, try using a "Codewarrior Attach". This will let your code boot up without the debugger, then you can "Attach" to the running app, pause the operation, and read out registers.
To clarify, you ARE NOT using a bootloader for testing, correct? Are you still redirecting your vector table, even though you're running from 0x00000000? If you are redirecting your vector table, are you sure you're copying over the right amount of bytes? This will vary by processor. Look in the NVIC table in your reference manual to see the number of vectors that must be defined. I've seen some of the bootloader App Notes copy the vector table incorrectly; for instance, instead of copying 0x400/4 uint_32 values, they'll copy 0x400. This would overwrite some of your data init values, and would give unpredictable results.