Problem running MSD Bootloader with k60FN1M

[ERussell]

I am having trouble getting the USB MSD Bootloader to work on my target board which has a K60FN1M chip.  I am using CW 10.2 running under Windows 7 - 64 bit .  I am also using the Freescale USB Stack v 3.2.0 instead of the code provided in the sample application for the Kinetis Dev kit. After making necessary changes to definitions from the K60 512 example I am able to enumerate and erase the flash. 

What happens when I open the Windows folder after enumeration is that I am asked if I want to scan and fix Bootloader (F. No problems are found after the scan. After dragging and dropping the image file (a S19 file), the K60 resets after beginning to erase flash and Windows says it cannot find the drive. I choose the "Try Again" option and start the program running again on the K60, go through the same process and drag the image file to the Bootloader drive. This time it gets through the erasing flash step, opens the image file, calls FlashApplication and recognizes that it is a S19 file, prints the "FLASHING... "and "Please do not remove your device" messages, calls FlashApplication, Flash Array, and FlashLine functions. The program never actually tries to program the flash but gets into a loop of erasing the flash from the function call in the routine MSD_Event_Callback. Eventually Windows gives up trying to complete the copy. The image file name shows up on the Bootloader drive underneath Ready.txt but of course Windows says it is an invalid directory name.

Could anyone shed some light on where the problem(s) are? Any help would be greatly appreciated!

Thanks.

[apanecatl]

Hi Elizabeth, you are basing your USB DEVICE bootloader in a USB HOST bootloader app note, if you were to use it as a host there would be no functional difference,

I recommend you base your MSD bootloader in the following app note:

http://cache.freescale.com/files/microcontrollers/doc/app_note/AN4379.pdf

And base your flash driver in the USB DFU code for the K70 included in the example (K70 works at 120 MHz at has 1MB flash) :

http://cache.freescale.com/files/microcontrollers/doc/app_note/AN4370.pdf

[ERussell]

I've done some more testing and have found out a few things and have gotten a little farther, but have still not succeeded.

I made several changes to the example MSD Bootloader project.

1 - In routine FlashArrayS19() in file, Loader.c, I initialized the variable "result" to 0 which was preventing multiple calls from executing.

2 - The second change was to limit the SRecord size to 32 bytes because the variable "totalL" in the FlashArrayS19() routine was defined as a uint8. The default SRecord size of my image project in CW was 252 which would translate into about twice that many hex digits. I could just as well change the size of "totalL".

3 - The third change was to correct the FTFE command for programming to 0x07 which programs 8 bytes at a time. The example program used a command of 0x06 and programmed 4 bytes at a time which is not defined for my processor.

At this point I get as far as programming the first set of 8 bytes, but the FTFE_STAT afterward has the Read Collision Error bit set and the program halts with a Hard Fault exception. I can, however, use the debugger and step through the Flash_ByteProgram() and successfully program the number of bytes passed in. But of course by that time the USB connection has ended. I've tried disabling/enabling interrupts at various places - at the beginning/end of FlashArrayS19(), at the beginning/end of FlashLineS19(), and at the original location before/after the call to Flash_ByteProgram() but the result has been the same Hard Fault exception after the first 8 bytes are written.

How can I figure out why/when the Read Collision Error is occurring?

Thanks.

[ERussell]

Well I've managed to get a little further, but am still not successful. I am now running the project as a purely RAM version instead of my Flash based version which uses ROM to RAM copying to put the routines that command the Flash into RAM.

What is happening is that the first SRecord line programs successfully. However, this line doesn't have a length that is a multiple of 8 bytes so, as in the example code, I padded the buffer to flash with the appropriate number of bytes of 0xFF. But when the second SRecord line is ready to flash, the starting address, being contiguous with the first line in this case, addresses the padded bytes that were added to the end of the first line. Trying to write to a flash location that has already been written to yields an access error even if the contents of the location is 0xFF.

Is there anyway of getting around this?

Otherwise I will need to do a bit more manipulation of the SRecords to ensure that the buffer to flash has a multiple of 8 bytes of actual data.

Thanks.