Problems implementing USB MSD bootloader on K20

[primozrebec]

Hi all,

i am trying to implement USB MSD device bootloader using Kinetis K20, CodeWarrior 10.4, processor expert and MQX lite OS. I think there is a problem with USB somewhere because my device is correctly enumerated and i can see file in BOOTOLOADER MSD drive when i attach my device to computer. Problem is when i try to write file to MSD drive. Windows reports timeout writing after few minutes. I did some debugging in MSD_Event_Callback function found in disk.c and figured out that USB_MSC_DEVICE_WRITE_REQUEST case is NEVER reached.  Any advice would be appreciated.

[pozz]

Just a trivial question. Is your USB MSD bootloader host or device type?

I'm interested in implementing a USB MSD host-type bootloader on K20 microcontroller (a USB pen-drive with a suitable file is connected to the microcontroller and the firmware upgrade will take place) but I worried after reading your post here.

[primozrebec]

As i wrote in the first post, my USB bootloader is device type.

[danielecortella]

Hi ,in this days i have work for find a solution with the freescale stack library. A fist solution, that i find, is to increase the buffer length in the file usb_msc.h changing:

#define  MSC_RECV_DATA_BUFF_SIZE            (512)

#define  MSC_SEND_DATA_BUFF_SIZE            (512)

in  :

#define  MSC_RECV_DATA_BUFF_SIZE            (8192)

#define  MSC_SEND_DATA_BUFF_SIZE            (512)

now i can load in to the sdcard files with dimension up to 8192byte, the problem with the MSD seem to be that the recieve buffer will not be emptied, writing the data, when it's reaches the maximal content of data. The file send to the device is not splitted in more small packages with the dimension of the buffer

[mjbcswitzerland]

Hi All

Since I have seen that there are a few difficulties with K20 projects requiring boot loaders I have added a TWR-K20D50M loader to the uTasker flexible boot loaders at

µTasker Test Software and Demos

This is discussed a little in this thread: K60F120M bootloader

The 50MHz K20 is rather different from the K20F100 (for example) but there are virtually no differences in the FS USB interface across device types (apart from the USB clock selection and setting in some cases) so there shouldn't be chip specific problems in boot loaders or other applications.

The uTasker loader (with SREC, USB-MSD, SD card and Ethernet loaders) allows the USB-MSD to be used immediately on most device types (in case of the need for a version for a specific processor that hasn't been tested yet just ask) - setting the processor type in the project is about all that is needed to move between devices - and it builds with CodeWarrior, GCC, Rowley Crossworks, Keil uVision and IAR.

Any one with the tower board can try out the loader at the download above. See the "readme" in the package for practical advice and see the video linked in the other discussion.

Regards

Mark

[kai_liu]

Nice, I will have a try anyway. Can I run it in FRDM-K20D50M? Any difference of push buttons setup between TWR and FRDM?

[mjbcswitzerland]

Kai

The FRDM-K20D50M is very different to the tower board, although they both have the same processor.

Since I don't have the FRDM board I have just set up the projects from its data sheet and simulated it  - the following settings had to be adjusted:

- UART is set to 0 (multiplexed to B port) to match the connection on the FRDM to the OpenSDA. UART should communicate via the virtual port and software loading should then be possible as long as the driver correctly implements XON/XOFF protocol (I experienced some such board level implementations not stalling correctly on XOFF which would lead to overflows when Flash blocks are being programmed - although standard serial/USB cables always work correctly)

- The LED output is set to PTD4 (green LED should flash)

- I disabled the SD card since the board doesn't support one

- There are no switches on the board (apart from a reset button) so I set the FORCE boot input to PTE0 and the watchdog disable input to PTE1. These are available on jumper pins so connecting the appropriate pin to GND will be like pressing a switch.

This means that SREC and USB-MSD loading should be supported for this board although not tested on the real HW yet. If you would like to see whether it does the job you try the loader SW: [Link removed]

There is a test application for loading via the UART (via the OpenSDA virtual port):[Link removed]

and one that can be loaded via USB-MSD: [Link removed]

The application will flash the green LED slower than the boot loader does and display a menu on the UART.

To repeat - I can't test on the HW at the moment so can't "guarantee" that it works but there is still a good chance since I could confirm most things in the simulator.

Regards

Mark

Update: tested software version available now at µTasker Test Software and Demos

[kai_liu]

Mark,

Thanks. Very helpful. I will follow this thread.

Allan

[mjbcswitzerland]

Hi

I received my Freedom FRDM-K20D50M and tried the loader (linked in previous post) and found that it didn't work on my board. It turned out that the crystal is connected without any feedback resistor or load capacitors and the software was configuring it for high gain. This means that the oscillator was never starting and so nothing happened (possibly some boards do start but probably marginal).

So I modified the oscillator setting to configure low gain and then all worked as expected.

As I feared (see previous post) the SREC loading via the OpenSDA virtual com didn't work correctly because it doesn't look to respect XON/XOFF protocol. This means that it doesn't stop sending data to the UART when a block of program data is to be committed to memory and there is an overflow (and error). That is a shame but the USB-MSD is so much faster anyway and maybe that problem will be fixed in a future OpenSDA version.

The 'official' USB-MSD loader is now here:

http://www.utasker.com/SW_Demos.html#K20

Regards

Mark

P.S. The connector to ground to force the loader mode at reset is J19 pin 4 (PTE0).

[kai_liu]

It seems FSL FRDM doesn't mount that resistor very often, which has been talked for a long time. Yes, the previous release doesn't work. So I still working on my own and many other bootloaders. (at least four). Now I got one working this morning.

I will test the new one. Thanks for your attention, anyway.

Yours sincerely

Allan K Liu

[kai_liu]

Any update? It is hard to debug USB indeed since it involves interactions between host and device. I would like to suggest you guys to add printf() in criticial suspected routines to find out why USB_MSC_DEVICE_WRITE_REQUEST is never called.

Alternatively, you can reach support from the author of https://community.freescale.com/docs/DOC-95494.

[primozrebec]

I've contacted FS support regarding this problem. I was told that they've tested for this issue on a K53N512 device using MSD example that can be found in FS USB stack. They did't have any problems like i have. I didnt't find this answer very helpful.

I did some research on the community forum and found another user with the problem like mine but using different MCU: https://community.freescale.com/message/366699#366699

I have also tested for this problem on KL25Z demo board and there is exactly the same issue as we have on our custom bord with MK20DN512 MCU.

Any advice or confirmation from FS employee would be appreciated.

[kai_liu]

Re: FDM KL25Z USB4.11 USB MSD Device Disk Format Issue is about FAT12/FAT16, maybe different from your issue?

I am trying to port my previous KL25Z MSD bootloader to K20 (FRDM). However I am not good at CW, I used to IAR. FSL MSD bootloader does have a framework, but it has not been tested on IAR/Keil toolchain.

It will take more time to release it.

[primozrebec]

Please, see the second comment from the author:

...

Next I tried a basic write operation with dd, "dd if=/dev/urandom of=/dev/sda bs=512"

This is where things fell apart. Linux appeared as if it successfully wrote the data however when I re-read my image no change would occur. If it can't complete a basic write operation I can't expect it to be able to format. I looked in the code and the correct USB op code is generated for a write operation. It receives WRITE_12_COMMAND /*opcode : 0xAA */ and attempts to execute the function "msc_write_command(controller_ID, cbw_ptr,csw_residue_ptr,csw_status_ptr);" in "usb_msc.c"  .

In this function there is a segment of code

	if(_usb_device_get_transfer_status(&controller_ID,
	BULK_OUT_ENDPOINT, USB_RECV) != USB_STATUS_IDLE)
	{
	(void)_usb_device_cancel_transfer(&controller_ID,BULK_OUT_ENDPOINT,
	USB_RECV);
	}

This if statement returns true which I believe cancels or blocks the write attempts.

it returns hex 11 as opposed to the 0 its looking for which is defined as USB_STATUS_IDLE. Issue is, theres no way for that function to return 0 so the usb device cancel transfer is always called... Currently it receives a "bus idle error"... I've tried disabling this error but it still failed to complete the action somewhere in the USB stack...

....

[danielecortella]

Hi all, in this moment i'm implementing a system with a sdcard connected to the FRDM-KL25 and i'm using the MSD for communicate with this through the Pc and i have the same problem that you have. When i try to write a file i can't, the same problem is present when i open a file created with the fatfs where the pc wait many seconds (30sec) before that i can see the text of the file. There is a an error with the call to the function write..... Debugging the usb i see that when a command of write is executed the usb protocol the msd crash and a status_cancelled is executed. I don't know very well the usb protocol but in the read operation executed by the pc there is also the command SCSI for a write (visible in red in the image, the next data are the information to be write) but the system crash because the function write_block is never call. Someone can help us??? THANKS

 

[primozrebec]

I ran an USB analyzer software on the port where MSD device is connected. When i try to write file to it i get "babble detected" error. Please, see the attached image.

[nicknax]

Primoz

This could be related to FDM KL25Z USB4.11 USB MSD Device Disk Format Issue and Need USB Mass Storage on FRDM-KL25Z Platform

Nick

[rossreinhardt]

Hi,

I would also like to know if you got this working.

I used the project from K20 USB device MSD bootloader as a baseline for a K20D50M and am having the same problem.

If the project is run in the debugger or attached to the debugger it flashes properly, but if it is run stand alone the MSD is enumerated but it looks like USB_MSC_DEVICE_WRITE_REQUEST is never called.

[refikhalilov]

Hi,

I have exactly the same problem using FRDM-K20D50M. Do you have some success already ?

BR

Refo