AnsweredAssumed Answered

What is this mystery bit in K60 USBx_USBTRC0?

Question asked by Douglas Triman on May 20, 2014
Latest reply on Jun 4, 2014 by Bob Paddock

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?

Outcomes