Bootloader with MK20DX256

[HowieM]

I am trying to use the MSD bootloader with this uC on custom hw.  I have added #define K20D72M in config.h (added KINETIS_MAX_SPEED 72000000, otherwise same as TWR_K20N50M), and new linker file (copy of included K40 linker file).  The board has an 8MHz crystal, so I used the same #define block as TWR_K20N50M in the app_hw_kinetis.h for the CRYSTAL_FREQUENCY, CLOCK_DIV, CLOCK_MUL, etc.  When I run the bootloader (forced to bootloader mode) and connect the USB port to PC, I get the "USB device not recognized" msg.  It looks like the device is not enumerated, but I am not sure why.  On the debugger, I see that the USB suspend/resume routine is executed right after plugging into the USB port.  Have I missed something in converting to this part?

[mark]

Hi

When USB doesn't work it usually means that the USB clock is not configured correctly. It must be exactly 48MHz.

For the K20 72 MHz part with 8MHz crystal I recomment running it at 72MHz as follows:


    #define CRYSTAL_FREQUENCY    8000000                                // 8 MHz crystal
    #define _EXTERNAL_CLOCK      CRYSTAL_FREQUENCY
    #define CLOCK_DIV            4                                       // input must be divided to 2MHz..4MHz range (/1 to /25 possible)
    #define CLOCK_MUL            36                                      // the PLL multiplication factor to achieve operating frequency of 72MHz (x24 to x55 possible)
    #define USB_CLOCK_GENERATED_INTERNALLY                               // use USB clock from internal source rather than external pin

Note that in the USB initialisation the USB clock is set and there are a few PLL frequences that it can use to generate the accurate clock. See fnConfigUSB() - if you run the project in the simulator there will be an error when this is executed and an accurate USB clock can not be set.

From your explanation I didn't actually see an error but I suspect that it will turn out to be the frequency somewhere.

Regards

Mark

[HowieM]

I can't seem to find my problem.  Looking at SIM_CLKDIV2 register, USBDIV = 2 and USBFRAC = 1.  USB clock should be 72 MHz x (USBFRAC+1)/(USBDIV+1), which would be 48 MHz.  Is there any external pin or handy method I could use to confirm the 72 MHz core or 48 MHz USB operation?

[HowieM]

Forgot I have a TWR-K20D72M... loaded the bootloader and confirmed at least the 72 MHz is correct because the RS232 timing was good for 115200.  Still have the same USB problem. 
I tried the Visual Studio simulation, but it will not run after compiling (Visual Studio Express 2013).  I get an error that it can't find the *.exe file, but there is an extra "." in the path -- D:\uTasker\Applications\uTaskerSerialBoot\Simulator\.\Debug\uTasker.exe.  Without the \., the file is there but I don't know how to fix that yet; this is my first time using Visual Studio.

[HowieM]

Ah, I got the simulation to run/debug.  I had to change the linker output file name to uTasker.exe.  It stopped with a "uMalloc failed!!" exception message.  I increased the OUR_HEAP_SIZE multiplier from 8 to 24 and it runs fine in the simulator, but still getting USB device not recognized when connecting the actual hw.

[mark]

Hi

I also didn't see a problem with the clock and, since the simulator also didn't warn that the frequency couldn't be calculated from the PLL setting I woudl suggest the following two things:
- Check in fnConfigureUSB() in usb_loader.c.

#if defined _KINETIS
    tInterfaceParameters.ucClockSource = INTERNAL_USB_CLOCK;             // use system clock and dividers
#else
    tInterfaceParameters.ucClockSource = EXTERNAL_USB_CLOCK;             // use 48MHz crystal directly as USB clock (recommended for lowest jitter)
#endif

It may a be that the version that you are using has a list of boards which select INTERNAL_USB_CLOCK. Since ALL Kinetis types need it I modified it some time ago to use _KINETIS instead since when making a new board type that was not in the list caused a failure (until added).

- Check that the USB-D+ and USB-D- lines are indeed connected correctly in the HW. For enumeration to start it takes only a pull-up resistor on the D+ line. If the D- line were not connected it would also result in failure.

Regards

Mark

[HowieM]

INTERNAL_USB_CLOCK is defined, so I'm ok there.  I have tried the TWR-K20 board and my hw with same USB cable and neither one works, although the same cable works on my TWR-K60.  I will try comparing scope traces on D+ and D- with the working K60 and non-working K20.

[mark]

Hi

Have you tried a pre-built binary: http://www.utasker.com/SW_Demos.html ?
These work on my TWR-boards so it would verify that the HW is not to blame.

If nothing helps, could you tell me the exct SW version that you started with and send me the configuration files that you modifed so that I can verify on a standard HW to work out what can go wrong?

Regards

Mark

[HowieM]

Thanks for the suggestion. I tried flashing uTaskerSerialLoader_K20_72.S19 on the TWR board and it works fine.  My modified code must be the problem!  I started with v1.4.3, and here are the files I changed.

[mark]

Hi

I didn't see any problem with the configuration and the simulator is not showing any problems.

However I see that V1.4.3 doesn't have a configuration for the TWR-K20D72M, which is what you are actually configuring for. This also means that the reference binary was produced after this version.

There is a version V1.4.4 Beta 1 at the bottom of the page: http://www.utasker.com/forum/index.php?topic=1721.0
which has a complete set of board configurations in the serial loader project. I checked the configuration against your and also didn't see any reason for the USB not to work.

I am now wondering whether this could be a compiler issue(?). What compiler are you using to build the project?

What I would also suggest is to use the Beta version since you only need to select TWR_K20D72M in config.h to get the complete setup that was used to build the reference. I am suspecting a difference you a certain compiler version at the moment but first I would see whether the effect is the same with the Beta.

Good luck

Regards

Mark

[HowieM]

I am using CodeWarrior 10.5.  I can't unzip V1.4.4 Beta with the password I have for V1.4.3.

[HowieM]

Sorry, it did unzip in spite of the "incorrect password" message.  This beta version is much more user friendly in CW 10.5!  I set the target for TWR-K20D72M, and it compiles/downloads/ runs without problem.  After I adjust some of the hw settings for my board, I should be good to go.  Thanks for your help!

[HowieM]

As a first try on my hw, I disabled the watchdog and changed the DEMO_LED_1 from bit 7 to bit 6 to line up with an LED on my board.  My K20 device is an 80 pin pkg instead of 100 pin, but otherwise same PN.  My LED blinks in boot loader mode (5Hz), but the dreaded "USB device not recognized" is still a problem.  I double checked the USB connector wiring and don't see a problem there.

[mark]

Hi

The V1.4.4 Beta 1 has a low of new serial loader stuff in it and was also 'streamlined' to the CW10.5 so I am pleased that you noticed the improvements.

I still don't understand why your configuration didn't work because I didn't 'see' the reason but I would use the V1.4.4 Beta anyway since it operates well and has various additional refinements in the loader operation too - plus it has been configured for and tested on just about all existing Freescale boards.

If your new board doesn't behave it sounds to be down to HW.

Check that you connect the VOUT33 output with the VREGIN input (a 2.2uF capacitor is recommended in the data sheet). This is the power supply to the USB transceiver and without it there will be (big) problems. If you copied a board design this detail is often not obvious and it wouldn't be the first time that it has been 'missed'.

Regards

Mark

[HowieM]

I didn't have a cap on VOUT33, so I added the 2.2uF.  That gets me through enumeration but I have some garbage file names that show up.  I didn't have a cap on VREGIN either, so I tried adding one there (4.7uF) but no help.  The garbage characters seem to be consistent and not random.