What is this mystery bit in K60 USBx_USBTRC0?

[talktrn]

Working on the Kinetis version of MSD Bootloader from AN4379, have successfully ported to TWR-K60 and TWR-K70 after a great deal of editing to make it correctly read SREC files using the FTFE "phrase" writes -- the AN4379 original code doesn't work correctly for the K70 due to the 8-byte "phrase".  All that is working quite well now, but found some odd behavior of TWR-K70, while the TWR-K60 works perfectly.  Also have this running on MCF52259 with same codebase.

Proper operation is:

1. TWR board initializes as MSD as drive 'f:' (or whatever), puts up a file screen with 'READY.TXT' as the only file

2. Drag the file to be flashed onto the drive

3. TWR flashes the file

4. TWR de-initializes the USB which closes the drive

5. TWR re-initializes the USB, so PC re-enumerates it and the drive window re-opens with SUCCESS.TXT as the only file

Works perfectly on the K60, but on K70 only steps 1-3 happen.  The de-initialize code does not work like K60.  So did some digging and I find something very odd, here's the code from AN4379, 'usb_dci_kinetis.c' module:

uint_8 USB_DCI_DeInit(void)

{

     /* Detach CFv1 core to USB bus*/

     USB0_USBTRC0 &= ~0x40;

The same bit is manipulated when the USB is initialized and elsewhere (it gets set), but in the latest Ref Manuals for K60 and K70 this bit is shown as "reserved" and "always 0".  Elsewhere in the AN4379 code, in 'usb_dci_kinetis.h' can be found:

#define _USBREGEN (0x04) /* Use the internal regulator */

#define _USBPUEN (0x40)  /* Use internal pull-up resistor */

#define _USBRESET (0x80)

The first two defines are not used anywhere, but the last _USBRESET is used in the code, and corresponds correctly to the RESET bit in USBx_USBTRC0.  So is the mystery bit (I call it that because it is manipulated as shown with literal value, while ALL other bits throughout the code are named) really the pull-up enable bit, or maybe it does nothing?

So I disabled the line of code shown above in DeInit() and found immediately that the K60 code now does not de-initialize the USB, and therefore does not close the drive window or do steps 4 and 5.  This line of code is required on my TWR-K60 board (maybe has older chip?).  I see that it is defined differently in earlier version of the K60 Ref Manual (K60P144M100SF2.pdf), and is still shown as "reserved" but noted with "Software must set this bit =1".  That note appears also in K40 Ref Manual, but is now deleted in latest K60 Ref Manual (K60P144M100SF2V2.pdf) and K70 Ref Manual (K70P256M150SF3RM.pdf).

So what is the implication of this bit?  Why is it needed in K60, and in fact can be seen in CodeWarrior 10.4 debug registers window as turning on and off?  But it does nothing in K70 register display, and doesn't respond to the code in AN4379 that manipulates it.

Also, more important to me as I've got to ship this thing, what exactly is wrong with K70 such that it will not de-initialize, clearing the window, and then reinitialize with SUCCESS.TXT.  All seems to revolve around not deinitializing USB.  And what does the comment about "Detach CFv1 core" mean to a Kinetis chip? Any ideas?

[mjbcswitzerland]

Douglas

I can't say exactly what the purpose is of this bit, but I set it to '1' when working in FS USB mode (and then keep it like this when the D+ pull up is on) as well as enabling the pull-up in USB_OTG_CONTROL.

Using this technique I haven't had problems with any KL or K parts (from KL02 to K70) as used in the following boot loader:

https://community.freescale.com/message/377071

However I don't re-enumerate during the operation but instead just jump to the new code after successful programming (or display the loaded SW - name and date etc. until the user pulls the USB cable, or until the user ejects the drive [depending on option setting]). When re-entering the boot loader the loaded file name and data is still shown since the fiel object is saved to the Flash with the program code (the code can also be read back [download] with optional password protection).

In case of any operating descrepancies there are pre-build USB-MSD loaders for most Freescale Tower and Freedom boards at the link in the link above, which allow checking register states with the debugger if it helps.

Coming also from the Coldfire V2 world before Kinetis it is worth noting the the USB OTG controller in the Kinetris is almost compatible with the one in the Kinetis (apart from some tranceiver and interrupt status details) and the same boot loaders run on all Coldfire V2 parts too (using the corresponding V2 HAL).

Regards

Mark

http://www.utasker.com/kinetis.html

[adriancano]

Hi,

I am not really sure about the behavior of this bit, but what you mentioned from the reference manual has to be a Documentation mistake. We will check this and I hope we can give you further information abut this issue.

Compare the code you are using with the KQRUG document of the USB module. What Mark mentions it a good practice, I recommend to you to use the Mark's workaround.

Hope I can have more information later.

-----------------------------------------------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer button. It would be nice!

-----------------------------------------------------------------------------------------------------------------------

[bobpaddock]

USB0_USBTRC0 |= 0x40; /* Asynchronous Resume Interrupt Enable / Attach ColdFireV1 USB core to bus */

Is the documentation I came up with after lots of digging, when I was working on a HID for the KL25.

The Kinitis documentation says the bit is reserved yet all example code show it set. :-(