USB MSD Host Bootloader for K22FN1M0

[ARQuattr]

I used AN4368 a while ago to customize the USB MSD Host bootloader for the MCF52259 MCU, and it works OK.  Now we are upgrading to the Kinetis MCU and I'm wondering if I should try to adapt the same bootloader code to that MCU (K22FN1M0), or try to use the new KBOOT.  Neither of these support have this MCU directly, so I assume I would have some work either way porting from K60 or K64 to the K22, but I'm not sure what would be easiest/best/recommended.  The KBOOT documentation doesn't seem to go into much detail on customizing (neither did AN4368 but I already figured it out somewhat), and the projects are for IAR where I prefer using CW.  I was inclined to go with AN4368, but I saw the KBOOT released recently and being suggested by a few people on the forum.

I'm wondering if anyone has any experience creating or customizing a USB MSD Host (not USB device) bootloader for the K20-series, by either of these or any other method?

Thanks,

Angelo

[jeremyzhou]

Hi Angelo，

Thank you very much for your focus on Freescale Kinetis product. I'm glad to provide service for you.

As Mark mentioned previous, the KBOOT've not supported MSD host  so far. So I'd like to suggest that you'd better modify the AN4368 for MK60 to fit K22.

Hope this reply to help.

If you've any furhter question about it, please feel free to contact with me.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[mjbcswitzerland]

Hi All

It has been some time but there has been a lot of testing of various memory sticks (including a few very strange ones...) but things look very good now for the USB-MSD host method in the uTasker serial loader.

In fact it has been combined with USB-MSD device so that a board can either be a device (when reset with a PC host connected) or will load code from a memory stick in host mode if not.

As reference I have attached such a version for the TWR-K21F120M (and the TWR-K22F120M - which I didn't test though since my board decided to die on me, but is expected to work). There are reference applications (called "software.bin") at the following links that can be put into the root of a memory stick for loading in case anyone wants to try it (or a binary to load when in USB-MSD device mode)

http://www.utasker.com/kinetis/TWR-K22F120M.html

http://www.utasker.com/kinetis/TWR-K21F120M.html

Various Kinetis boards with K and KL USB parts have been tested so essentially any chip can be used without development effort. Either USB-MSD device, USB-MSD-host or both at the same time!

In fact it is also possible to clone software between two boards (one acting as USB-Host and the other as USB-Device) using the loader and I will maybe shortly put together a video showing how it works.

Regards

Mark

[mjbcswitzerland]

Angelo

1. The USB controller in the Kinetis is 98% identical to the one in the MCF52259. Theoretically moving the original application to any Kinetis should be relatively straight forward (assuming that the code is written in a structured manner).

2. KBOOT and USB MSD host are completely different methods. If you could use KBOOT it means that you are open to other methods.

3. If you can use KBOOT you can also use the uTasker serial loader: KBOOT USB HID loader [uTasker Kinetis release V1.4.6] which is compatible with it but supports CW10.x, IAR, Keil, Rowley, Coo Cox, GCC and Atollic. It operates about 5x faster than the present KBOOT code, is about 1/3 the code size and can be built for any part (KE, KL or K series).

4. In addition, the loader in 3 can support (as alternative or in parallel) various other loading options: Kinetis Boot Loader for SREC UART, SD Card and USB-MSD loading

Regards

Mark

[ARQuattr]

Thanks Mark, I looked at your bootloader before but it appears to be a USB device bootloader, is that correct?  I require a USB host bootloader.  Are you saying also that KBOOT only supports USB device?

[mjbcswitzerland]

Angelo

KBOOT is essentially a PC program that allows loading code to Kinetis devices via various interfaces. It supports USB-HID device and so has nothing to do with USB-MSD host.

The uTasker serial loader supports various methods, including KBOOT compatible USB-HID device and UART. Presently I don't believe that KBOOT is popular and I also don't know whether it will become popular (the various I2C, SPI and CAN loading methods are probably very niche solutions) - USB-MSD device and SD card loading seems to be the highest demand according to user numbers. The uTasker serial loader will include USB-MSD host some time shortly but this is not yet on a priority path since the demand for memory stick loaders is fairly low (although certainly not zero).

Regards

Mark

[kevinpenn]

Hi Mark,

I'm in a very similar situation to Angelo and was hoping to utilize uTasker. Have you or will you anytime soon have support in your Serial Loader for USB MSD Host?

Thanks

[mjbcswitzerland]

Hello Kevin

Over a year ago I added USB host to mount memory sticks but I never got aound to making a loader version. In fact there has been no real demand for this so I suppose that I just forgot about it since then.

I'll take a look when I have a few moment to see whether there is much needed to complete the functionality and get back.

You may however also like to check out the following because it looks as though Aaron may already have a working host loader here: K64 bootloader

Regards

Mark

Kinetis: µTasker Kinetis support

K22: µTasker Kinetis FRDM-K22F support  / µTasker Kinetis TWR-K22F120M support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[mjbcswitzerland]

Hi Kevin

I have done some work on "finalising" a USB host memory stick based loader integrated in the uTasker serial loader package and can confirm that it is essentially operational (on K22, or any others with host support on the board).

Before releasing I will spend some time testing on various memory stick types and catching awkward situations (like someone pulling the stick out during the process) so that the chances of trouble-free and reliable operation is increased for first users. And, of course, update the user's manual (although the operation is 95% identical to the SD card loader) and ensure compatibility of a number of KL, K, KW parts that allow host mode on their eval-boards.

As a "taster" I have copied the debug output with an 8G TDK stick which has several hundred directories and files in its root that are scanned to try to find a new firmware to copy (which isn't there in this instance).

uTasker Serial Loader

=======================

[0x00008080/0x0001ffff]

bc = blank check

dc = delete code

go = start application

> USB FS device detected

USB device information ready:

USB2.0 device with 64 byte pipe

Vendor/Product = 0x1d0d/0x0213

Manufacturer = "TDKMedia"

Product = "Trans-It Drive"

Serial Number = "078C1019329E"

Bus-powered device (max. 300mA) with 1 interface(s)

Mass Storage Class : Sub-class = 0x06 interface protocol = 0x50

Endpoints:

1 = BULK IN with size 64

2 = BULK OUT with size 64

Enumerated (1)

LUN = 1

Status transport - OK

Status transport - OK

Status transport - OK

Mem-Stick mounting...

Sector 0x00000000 READ OK

Sector 0x00001f80 READ OK

Sector 0x00001f81 READ OK

Disk E mounted

Mem-Stick present

Sector 0x00003f80 READ OK

Sector 0x00003f81 READ OK

Sector 0x00003f82 READ OK

Sector 0x00003f83 READ OK

... [repeats for a number of sectors]

Sector 0x00003faf READ OK

Sector 0x00003fb0 READ OK

Sector 0x00003fb1 READ OK

Sector 0x00003fb2 READ OK

Sector 0x00003fb3 READ OK

No file on Mem-Stick

At a later time I am toying with an option to work with either USB-MSD or memory stick at the same time (start in device mode and if no enumeration during a couple of seconds move to host mode to see whether there is a stick inserted) so that maximum flexibility is achieved. This can also work alongside KBOOT HID mode (as composite with USB-MSD). In the short-term I will probably release the host mode within a week from now.

[Edit 1:] There are initial versions for TWR-K21F120M and TWR-K22F120M at µTasker Kinetis TWR-K21F120M support  and µTasker Kinetis TWR-K22F120M support

[Edit 2:] To demonstrate the target independency there is also one for the TWR-KL46Z48M at µTasker Kinetis TWR-KL46Z48M support

Regards

Mark

Kinetis: µTasker Kinetis support

K22: µTasker Kinetis FRDM-K22F support  / µTasker Kinetis TWR-K22F120M support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[kevinpenn]

Mark,

Thanks for the update and for working to release that.  I will evaluate my needs with what you've got out so far.

Thanks,

Kevin

[Edit 1]: I went to look at the initial version you uploaded for the TWR-K21F120M and unfortunately I am developing using Kinetis Design Studio so I can only flash .elf files to the board and not .bin.  Could you possibly generate a .elf and put that up? Thanks!

[mjbcswitzerland]

Hi Kevin

I have attached the .elf file from the TWR-K21F120M. This can be loaded with the KDS Flash loader.

Regards

Mark

Kinetis: µTasker Kinetis support

K22: µTasker Kinetis FRDM-K22F support  / µTasker Kinetis TWR-K22F120M support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[kevinpenn]

Mark,

Thank you very much for posting that for me.  I know this is an early version so I anticipated some bumps but I wanted to share my results.

I tested with two different flash drives, an 8 GB Sandisk Cruzer Glide and a 4 GB more generic drive by Alcor Micro with product ID 6387h.  I formatted both as FAT32. Both had "software.bin" that I pulled from the appropriate uTasker page.  When using the generic 4 GB drive, I could only ever get this:

uTasker Serial Loader

=======================

[0x00008080/0x00017fff]

bc = blank check

dc = delete code

go = start application

> USB FS device detected

Mem-Stick not present

Mem-Stick not present

Mem-Stick not present

I had better results with the Sandisk drive but not as well as you had in the example output you posted.  The results were somewhat inconsistent.  I tested two scenarios.

__________________________________________________________________________________________

The first scenario: I inserted the flash drive and hit the reset button.  Here is the terminal output I got every time:

uTasker Serial Loader

=======================

[0x00008080/0x00017fff]

bc = blank check

dc = delete code

go = start application

> USB FS device detected

USB device removed

USB FS device detected

Mem-Stick not present

Mem-Stick not present

Mem-Stick not present

_________________________________________________________________________________________

The second scenario: I hit the reset button on the board and waited for the 3 "Mem-Stick not present" messages to appear and THEN inserted the flash drive. Here is the terminal output I got every time:

uTasker Serial Loader

=======================

[0x00008080/0x00017fff]

bc = blank check

dc = delete code

go = start application

> Mem-Stick not present

Mem-Stick not present

Mem-Stick not present

USB FS device detected

USB device information ready:

USB2.0 device with 64 byte pipe

Vendor/Product = 0x0781/0x5575

Manufacturer = "SanDisk"

Product = "Cruzer Glide"

Serial Number = "20054255700CEB3ù¢`"

Bus-powered device (max. 100mA) with 1 interface(s)

Mass Storage Class : Sub-class = 0x06 interface protocol = 0x50

Endpoints:

1 = BULK IN with size 64

2 = BULK OUT with size 64

Enumerated (1)

LUN = 1

Status transport - OK

Status transport - OK

This is as far as the program got every time, as you can see, not as far as yours.  Also, each time the last three characters of the serial number are always different. 

____________________________________________________________________________________________

I'm not sure how to interpret it exactly without the source but I hope this can help you in your development.  We are hoping to be able to use the uTasker loader in an upcoming project

Thanks,

Kevin

[mjbcswitzerland]

Hello Kevin

Many thanks for the feedback. I have also had the opportunity to test with some more memory sticks in the meantime and have seen that some work always (I can load SW 100 times and it will always work exactly the same and error free) but some will either never enumerate or fail to mount (also in these cases it is almost alwas identical too).

First however to the serial number that you have with random end. This is because of the following: there are two defines that control how many strings are requested (max.) and how long the strings can be stored to, which are set to 3 and 16 respectively in this version. When strings are requested, they are requested with this maximum length (strings can be physically up to 256 in length) and it was expected that larger strings would only deliver the requested length, whereby your memory stick actually has a serial number string a little longer than the max. requested. However the reality is that it returns the unicode string with its full length, followed by a number of characters limited by the requested length (that is, it still returns the full unicode length embedded in the data). The result was that the output routine was printing the number of charaters indicated in the unicode string although not all content was actually requested/received.By limiting the unicode length to the maximum supported length during printout cuts off the end that was otherwise random and so solves this (increasing the local max string length would also solve it and keep the full size string).

The other behavior can be explained as follows, whereby it is to be noted that this version is a "fair-weather" version which doesn't include all error handling (some of which was originally also not expected to be necessary). In fact it doesn't handle unplugging and plugging in again - just the original, single plug-in.

1. Some sticks actually "plug in and out" a couple of times on power up. This may be due to their power supply circuit which has a time of instability when the Vbus is applied. I have also a stick that will always cause detection/removal/detection when already connected after a reset and I also need to plug this in once the board is operating for it to enumerate (the 'bounce' doesn't happen if I plug it in quickly). Presumably, when the driver handles plug-in/out/in it will then also have no problems with such sticks.

2. The second type of stick that I have found is one that seem to be very slow to actually start. That means that when the host tries to enumerate it it gets no response - presently this causes immediate failure since the enumeration state-machine only quits if anything fails (without retries after timeouts). When I compare the operation when connected to a PC I see that the PC also fails to communicate and it will go through a few retry cycles and after a delay the stick will then start responding. Some sticks obviously need some time to boot internally before the USB device is actually ready to work - even though the device has already pulled the D+ line high. Presumabyl refining the host enumeration state machine to include some timeouts and retries will be able to handle such sticks.

3. The third type is very similar to the one that you can enumerate but doesn't mount. In fact I have one of the same make as the one you have which behaves very similarly (see below) - it enumerates reliably (when inserted when running - but its D+ line 'bounces' when already connected). But it will never mount - note that it fails after a couple or transactions (as in your case).

What I have seen is that when the capacity of the stick is requested (the third transaction) there is a stall on the USB bus - this usually means that the device doesn't support the command. This was not anticipated and it presently causes the mounting to be aborted. The strange thing is that I tried a few other commands, like reading a sector instead, and they all stalled at this point. When I compare what happens when the same stick is connected to a PC the behavior is a little different (possibly because it is in HS mode rather than FS mode) and I see that rather than the bus stalling, the transaction receives a response that it has failed. I also see that the PC tries reading data, and also gets a failure as response. But the PC doesn't give up and keeps trying things and after about 2s (!!) or so the commands start working (passed, rather than failed is returned).

Here my "tentative" conclusion is that this stick type is also slow in starting (it is a 16 GByte one) and although the USB layer is fully operational many commands are presently not yet available. In FS mode it probably signals this with the bus stall and in HS mode with a status response instead. Not until after a couple of seconds will the device then signal that it is fully operational. This again means that the initialisation sequence (after the enumeration part) also requires the state machine that handles some failure and retries to ensure that sticks that require some time be become fully operational can be worked with.

> USB FS device detected

USB device information ready:

USB2.0 device with 64 byte pipe

Vendor/Product = 0x0781/0x5406

Manufacturer = "SanDisk"

Product = "U3 Cruzer Micro"

Serial Number = "43172009D7514E7"

Bus-powered device (max. 100mA) with 1 interface(s)

Mass Storage Class : Sub-class = 0x06 interface protocol = 0x50

Endpoints:

1 = BULK IN with size 64

2 = BULK OUT with size 64

Enumerated (1)

LUN = 2

Status transport - OK

Status transport - OK

<-------------------------------the next transaction (requesting disk capacity) fails and aborts the mounting

As a sanity check I just made a quick workaround as follows (file for the TWR-K21F120M attached):

1. Immediately enable the Vbus to supply power to the stick after reset

2. Start the USB task after 3s (to give the stick time to be ready)

The result was that there is no 'D+ bouncing and also the stick mouted and SW coud be uploaded, which seems to confirm the observations. It seems to be a suitable workaround for when the stick is already inserted (without complicated state machine) but would still not resolve the case where the stick is inserted during operation.

Maybe you could verify that it allows your stick to operate whereby I will work on the final solution (with intelligent state machine and plug in out in support).

The final thing to report today is that I have been verifying operation with several IDEs/compilers (the attached one was built with GCC). All behave identically apart from Keil uVision which has me stumped at the moment. This fails randomly during mounting (but so frequently that it is unuseable) and the failure is that the USB host randomly fails to start its IN polling when commanded (if I catch this and repeat it will mount but very slowly). The behavior is identical with all levels of optimisation and there are no registers invoved that aren't declared as volatile. Hopefully I will get to the bottom of this soon but at the momemt Keil can't be used ;-(

Regards

Mark

Kinetis: µTasker Kinetis support

K22: µTasker Kinetis FRDM-K22F support  / µTasker Kinetis TWR-K22F120M support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[kevinpenn]

Mark,

Thank you very much for the update.  I flashed your updated image and the address is fixed (as expected since that was an easy bug) but unfortunately my stick still will not mount.  I tried resetting with the stick already plugged in as well as resetting and plugging in the stick quickly.  Here is the terminal output:

uTasker Serial Loader

=======================

[0x00008080/0x00017fff]

bc = blank check

dc = delete code

go = start application

> Mem-Stick not present

Mem-Stick not present

USB FS device detected

USB device information ready:

USB2.0 device with 64 byte pipe

Vendor/Product = 0x0781/0x5575

Manufacturer = "SanDisk"

Product = "Cruzer Glide"

Serial Number = "20054255700CEB3"

Bus-powered device (max. 100mA) with 1 interface(s)

Mass Storage Class : Sub-class = 0x06 interface protocol = 0x50

Endpoints:

1 = BULK IN with size 64

2 = BULK OUT with size 64

Enumerated (1)

LUN = 1

Status transport - OK

Status transport - OK

Mem-Stick not present

As you can see, not much different.  I assume the 2 "Mem-Stick not present" messages are because of the USB task start up delay you added. After those 2 messages appear, the device enumerates but it appears it is getting stuck on the storage size request still. And after that, a final "Mem-Stick not present" message appears.  Would the delay you added fix the problem of the storage size request failing?

Thanks again,

Kevin

[mjbcswitzerland]

Hi Kevin

I have attached a version which delays the USB by 8s in case your card is really slow to be ready. The loader will poll for 12s (previously 3s and x3 respectively).

It is correct that you will see "Mem-Stick not present" a few times because the loader part is just checking whether there is media ready or not.

You will need to always reset with the stick in to make use of the added delay - the D+ bounce issue should generally be fixed.

Regards

Mark

Kinetis: µTasker Kinetis support

K22: µTasker Kinetis FRDM-K22F support  / µTasker Kinetis TWR-K22F120M support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[kevinpenn]

Mark,

Thanks for the quick update.  Using the updated version you just posted, my device will still not fully mount.  Once again, here is the output:

uTasker Serial Loader

=======================

[0x00008080/0x00017fff]

bc = blank check

dc = delete code

go = start application

> Mem-Stick not present

Mem-Stick not present

Mem-Stick not present

Mem-Stick not present

Mem-Stick not present

Mem-Stick not present

Mem-Stick not present

USB FS device detected

USB device information ready:

USB2.0 device with 64 byte pipe

Vendor/Product = 0x0781/0x5575

Manufacturer = "SanDisk"

Product = "Cruzer Glide"

Serial Number = "20054255700CEB3"

Bus-powered device (max. 100mA) with 1 interface(s)

Mass Storage Class : Sub-class = 0x06 interface protocol = 0x50

Endpoints:

1 = BULK IN with size 64

2 = BULK OUT with size 64

Enumerated (1)

LUN = 1

Status transport - OK

Status transport - OK

Mem-Stick not present

Mem-Stick not present

Mem-Stick not present

Mem-Stick not present

Mem-Stick not present

Based on one of your previous comments, I was under the impression that after the two "Status transport - OK" messages, the next one (that seems to be a problem) was requesting the capacity of the device.  Is this right? You said then that it worked on the PC after a delay.  Is the delay you've added to the loader supposed to fix this?  Is it possible the delay needs to be even longer?

Thanks,

Kevin

[mjbcswitzerland]

Hi Kevin

The last test version had a huge delay of 8s and I can't imagine that the stick is still not ready, but I can't be sure at the moment. To get to the bottom of this and also allow identifying problems in the future (based on the fact that different memory sticks can behave very differently) it looks like much better debug output is going to be required, as well as the host also being very tolerant to some errors in the process that it needs to handle with repetitions and such. This will probably not be a simple and will require a lot of documenting in order to be able to follow (USB is not the nicest protocol to analyse and track). In the meantime it may be wise to find a stick that actually works reliably (as several that I have do, and also as my Cruzer does as long as I have an initial delay of greater than about 2s).

In the meantime your Cruzer stick is of course an interesting case that will also need to be understood and solved.

Attached you will find a diagram that I have which illustrates the operation of the HW driver, generic USB and class/application parts. They are not that simple to understand at the moment (I use simulation as well to make things fully clear as to how they are intended to operate) but it will help me to formally document and add error handling cases where needed - you will see quite a lot of timeout situations which will need to be handled. It is worth noting that such things are not actually handled by the HW so I plan on using a PIT for high accuracy interrupt based error timing (the HW driver already need this to generate reset timing anyway).

Since I certainly have an issue with my Cruzer stick that is not ready for operation until the power has been applied for around 2s, and I know that it stalls when operations are attempted, I have added the stall handling in the diagram. At the moment I don't remember the details of clearing a stall (I have done it at devices but will need to study up to do it as the host) but I have now added an event that the application will report on. This would then allow proving the situation for your stick - whether it is really still stalling after 8s!! [By the way - my stick would also need > 2s before the PC could work with it so if you can work with it and a PC within 8s it is also probably something else....].

Below is a reference of my Cruzer with no delay (showing the stall on the request as expected) - and then with an 8s delay (where it mounts and loads SW).

Attached is a version with this same output and a 16s delay so that you can verify with your stick. As noted before it would certainly be best to have a couple of reference sticks that do work reliably until the other ones are sorted out... I am hoping that there are not such sticks that are really going to need > 10s 'warm-up time' since it would still be anoying, even if the loader handles them correctly!

Regards

Mark

uTasker Serial Loader

=======================

[0x00008080/0x00017fff]

bc = blank check

dc = delete code

go = start application

> USB FS device detected

USB device information ready:

USB2.0 device with 64 byte pipe

Vendor/Product = 0x0781/0x5406

Manufacturer = "SanDisk"

Product = "U3 Cruzer Micro"

Serial Number = "43172009D7514E7"

Bus-powered device (max. 100mA) with 1 interface(s)

Mass Storage Class : Sub-class = 0x06 interface protocol = 0x50

Endpoints:

1 = BULK IN with size 64

2 = BULK OUT with size 64

Enumerated (1)

LUN = 2

UFI INQUIRY -> Status transport - OK

UFI REQUEST SENSE -> Status transport - OK

UFI FORMAT CAP. -> Stall on EP-0                                      <--- verification of stall on UFI FORMAT CAP. when requested quickly (presently halting further operation)

Mem-Stick not present

Mem-Stick not present

Mem-Stick not present

uTasker Serial Loader

=======================

[0x00008080/0x00017fff]

bc = blank check

dc = delete code

go = start application

> Mem-Stick not present

Mem-Stick not present

Mem-Stick not present

Mem-Stick not present

Mem-Stick not present

Mem-Stick not present

Mem-Stick not present   <--- 8s delay in this case

USB FS device detected

USB device information ready:

USB2.0 device with 64 byte pipe

Vendor/Product = 0x0781/0x5406

Manufacturer = "SanDisk"

Product = "U3 Cruzer Micro"

Serial Number = "43172009D7514E7"

Bus-powered device (max. 100mA) with 1 interface(s)

Mass Storage Class : Sub-class = 0x06 interface protocol = 0x50

Endpoints:

1 = BULK IN with size 64

2 = BULK OUT with size 64

Enumerated (1)

LUN = 2

UFI INQUIRY -> Status transport - OK

UFI REQUEST SENSE -> Status transport - OK

UFI FORMAT CAP. -> Status transport - OK    <---- now they pass without stalling

UFI READ CAP. -> Status transport - OK

Mem-Stick mounting...

Sec 0x00000000 OK

Sec 0x00000034 OK

Sec 0x00000035 OK

Disk E mounted

Mem-Stick present

Sec 0x00000f40 OK

Sec 0x00000f41 OK

Sec 0x00000f42 OK

Chunk removed...

Sec 0x00000f48 OK

Sec 0x00000f49 OK

Sec 0x00000f4a OK

Sec 0x00000f4b OK

Part 0x0000/8 0x008f5b40 OK

Part 0x0008/256 0x008f5b40 OK

Part 0x0108/248 0x008f5b40 OK

Part 0x0000/8 0x008f5b41 OK

Part 0x0008/256 0x008f5b41 OK

Part 0x0108/248 0x008f5b41 OK

Part 0x0000/8 0x008f5b42 OK

Part 0x0008/256 0x008f5b42 OK

Part 0x0108/248 0x008f5b42 OK

Part 0x0000/8 0x008f5b43 OK

Part 0x0008/256 0x008f5b43 OK

Part 0x0108/248 0x008f5b43 OK

Part 0x0000/8 0x008f5b44 OK

Part 0x0008/256 0x008f5b44 OK

Part 0x0108/248 0x008f5b44 OK

Part 0x0000/8 0x008f5b45 OK

Chunk removed...

Part 0x0000/8 0x008f5b70 OK

Part 0x0008/256 0x008f5b70 OK

Part 0x0108/31 0x008f5b70 OK

File valid

Part 0x0008/4 0x008f5b40 OK

Part 0x000c/256 0x008f5b40 OK

Part 0x010c/244 0x008f5b40 OK

Part 0x0000/12 0x008f5b41 OK

Part 0x000c/256 0x008f5b41 OK

Chunk removed...

Part 0x0000/12 0x008f5b70 OK

Part 0x000c/256 0x008f5b70 OK

Part 0x010c/27 0x008f5b70 OK

Software Updated

Hello, world... KINETIS  <--- loaded application running

[kevinpenn]

Mark,

Maybe it shouldn't be a surprise, but even with a 16 second delay the stick still stalled in the same place.  It must be some other issue as you though.  To verify that I didn't have some sort of faulty stick, I tried another identical model and had the same issue.  The generic stick I also tested initially still did nothing as far as mounting, only showed "USB FS device detected".  I was able to test with a third stick that turned out to be a Sandisk Cruzer Micro (VID: 5406h) that you have successfully tested with and that one was successful, as expected.  I used "software.bin" from the uTasker website and successfully loaded from the stick.  For the time being, this is good to have a working edition.  However, it is pretty important that the other Sandisk device be made to work as that is already established as what we use for field updates, etc.  I am sure that you want compatibility with as many memory sticks as possible as well.  Hopefully this information can help.  I can test as many other versions necessary with this specific flash drive.

Thanks,

Kevin

[mjbcswitzerland]

Hi Kevin

Thanks for the feedback again. Yes, I was not really expecting that an even "huger" delay would change things so in this case it sounds as though the stick either really doesn't support the particular request or requires something else to be done beforehand before it accepts it.

In this situation it is usually simplest to see what a PC does with it to get around the state and copy it, but if there is no USB analyser handy it may not be so easy to 'see' what it is doing. I'll do some more hunting and maybe can find an equivalent stick to work directly with.

The generic one's behaviour is the same as one that I have from Swissbit and looks to be due to enumeration failing when started too quickly for the stick (possibly after USB reset and not Vbus power on). With a little bit of error handing I don't expect this to be a big issue to solve - I have seen the PC also getting no responses when starting enumeration and having to repeat some things.

Since you also have a stick that is behaving well (same as mine) you could in fact concentrate on the overall loading usability/suitability for your final requirements. Apart from the fact that the connection/mounting take a little longer, the rest of the operation is identical to the SD card loader as described in http://www.utasker.com/docs/uTasker/uTaskerSerialLoader.PDF

The SD card loader part is what is printing out Mem-Stick not present whereby it works with either an SD card or (now) a stick (it sees it as a drive) so its code is media -independent.

It may also be time for you to receive the complete code so that you can confirm that you can build it with your favorite compiler/IDE and dimension its parameters (like application location and max. size, or if you want to work with encrypted applications). Using the "known-easy-going" stick I have never had a failure so under normal circumstances it looks fairly robust and the additional error handling necessary for the operation of the more tricky sticks will also ensure that the reliability improves too.

Regards

Mark

Kinetis: µTasker Kinetis support

K22: µTasker Kinetis FRDM-K22F support  / µTasker Kinetis TWR-K22F120M support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[kevinpenn]

Mark,

Unfortunately I do not have a USB analyzer available, not hardware or software.  I have looked through the SD section of the Serial Loader PDF and the functionality provided is what we are looking for.  It would definitely be beneficial for moving forward to receive the code to verify compiling and fine tuning as you said.

Thanks,

Kevin

[mjbcswitzerland]

Hi Kevin

I released an intermediate package and sent you links to it. You can build it with any of the compilers/IDEs listed at µTasker Kinetis support

With a little more 'tuning' of debounce and start delays I managed to also get my Swissbit stick to enumerate and it has a similar stall issue to your stick that is delay independent. It actually accepts the UFI Format Capacity immediately but stalls on the following UFI Read Capacity but this is very close to what you reported so I'll investigate and solve this next.

Since the solution is being refined I also optimised a bit to memory stick operation by removing the original SD card polling and now it will wait for the stick to mount for a limited time and only actually start the polling once the mounting has started. Attached is the latest TWR-K21F120M image where you may find that you "generic" stick starts to enumerate too. You will see 2s delays between the two 'problem' requests prior to mounting - the first allows my Cruzer to respond and the second is there in case the second request needs a little more time. Both will be removed later when the handling has been refined.

Regards

Mark