K22PM121x Flashloader

[brunopaillard]

Is there a way to install the Kinetis Flashloader into the MK22P121Mxx microcontroller (on the FRDM K22F board) so that it behaves like a production device.

I need to work on production tools.

Thanks

Bruno

[santiago_lopez]

Hi Bruno,

Did you mean the Kinetis Bootloader? (Kinetis Bootloader|Freescale). This software is intended to enable kinetis devices for self-programming and you can download the source code from the web page. Right now it supports Kinetis K64F12, but as I mentioned, the source code is available and you can modify it to make it work with the K22.

Saludos

[brunopaillard]

Hi Santiago

Is there an executable image that would work exactly the same as the one that is in the factory device? This way I could be sure to test my production tools exactly as they would work on a factory device, and not worry about possible problems that would come from wrong project settings and the like.

Thanks

Bruno

[santiago_lopez]

Do you mean the firmware loaded in the auxiliary Kinetis K20 that works as debugger and bootloader for the freedom board?

[brunopaillard]

Hi Santiago

No, I mean the FlashLoader, that is present in all factory MK22P121Mxx microcontrollers (discussed in Ch 13 of K22P121M120SF7RM.pdf), and that can be used to initially load firmware in a freshly assembled board based on that MCU (using the MCU's own USB connection for instance).

Bruno

[mjbcswitzerland]

Bruno

Are you sure that these parts are presently shipping with the loader pre-installed? It is essentially the KBOOT loader but the present version (FSL_Kinetis_Bootloader_1_0_2) doesn't support the full set of interfaces listed there and also doesn't include a K22 target.

It is possible that there is a not-yet released version that generates a binary that is being installed - if the binary exists but is not made available you can order a chip and then do a memory dump so that you have a copy of it.

Regards

Mark

[brunopaillard]

Hi Mark

I have no way to be sure. I can only go with what the documentation (K22P121M120SF7RM.pdf) indicates. All I have in my hands right now is the FRDM K22F board, in which, of course, the MCU has been reprogrammed with the out-of-the-box examples.

This being said, the documentation is clear, so I would expect a factory MCU to have the Kinetis FlashLoader programmed in Flash.

Bruno

[Jorge_Gonzalez]

Hello Bruno:

You are correct, K22FN512 devices as the one in FRDM-K22F should come from the factory with a Flashloader. I do not see the binary available to recreate the Flashloader, but a major release of KBOOT is coming tentatively in December and it might come with the source files and the binary for the flash loader.

However this Flashloader is a one-shot firmware and it gets erased after the first programming, leaving the MCU in the same state as the one you have in FRDM-K22F, so I do not see any settings to worry about regarding the production tools.

Regards!,
Jorge Gonzalez

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

[brunopaillard]

Hi Jorge

I looked at the KBOOT package, which includes a binary image of the Flash Loader for the MK22FN512x12. This is flashloader_loader.bin and flashloader_loader.srec. I have been able to (re)install these packages into Flash.

From that, I have been able to develop and test our production tools. Everything is working as it should, except the following annoyance (observed on the freedom K22F board):

-     When the Flash Loader is in Flash, powering and booting fresh from a USB connection (connecting the board to the PC through the MCU's USB connector, which also powers the MCU), the MCU enumerates correctly as a HID device, up to a point where, after NAKing 11 requests, it sends 3 unrequested 3-byte packets to the PC (orphans). At this point the PC closes the connection, which becomes unusable.

-     From that point, pressing the reset button (forced MCU reset while USB connected - and powered) causes the MCU to enumerate correctly this time, and stay functional.

-     Is this a known behavior?

-     Should I expect a newly assembled MK22FN512 (out of production) to behave like this?

-     Anyone knows what causes this?

[mjbcswitzerland]

Hi Bruno

I have a TWR-K22F120M and a FRDM-K22F and run the same software with USB device on both (using 48MHz internal crystal-less clock).

The TWR-K22F120M USB works well.

The FRDM-K22F USB is "extremeny" unreliable - usually the emumeration works but then I see a lot of orphaned packets on the other endpoints and the connection fails (often quickly and almost certainly after a short time)..

When I load flashloader_loader.bin to the FRDM-K22F it also has lots of probems; sometimes it won't enumerate and often can't connect to the KBOOT tool when it does. (Initially I thought I must have made an error in the FRDM-K22 setup and that is why I checked with the loader SW and found that it was also unuseable).

Since the TWR-K22F120 (same processor in BGA and same code) operates normally I suspect that there is a design problem in the FRDM-K22F HW, especially as you also report that you see strange things (but I would say that your board sounds to behave a bit better than mine).

Since I am trying to validate a USB stack for both the TWR and FRDM board this difference is causing me some problems so I am going to have to do some more study - the only things that I can think of at the moment is to improve the VOUT33 decoupling or try removing some of the HOST components to hopefully find an improvement.

Regards

Mark

http://www.utasker.com/kinetis.html

[brunopaillard]

Hi Mark

Thanks for the quick feedback.

Just to put the most information on there: I do not find any problem with the firmware that I designed, based on USB_LDD. That would seem to exclude a hardware issue. Also, if it was a problem related to Vcc stability, I would expect to see more variability in the time at which it conks out. It always does the complete HID enumeration without problems (this is not so quick so Vcc must be good enough for long enough for that), then after NAKing 10 to 12 packets it always sends 3 3-byte orphan packets. This seems to be very repeatable.

Still, there is not much difference software-wise between a Power-On Reset and a Reset-Pin Reset, that would be a good argument in the hardware-issue argument...

I will try to get a look at the code. It is not for KDS, but still should be able to look at the source.

Thanks!

[mjbcswitzerland · Accepted solution]

Hi Bruno

My FRDM-K22F board started to behave reliably again yesterday (alhough I didn't do anything to it (?)) so I took the opportunity to complete validation of the work that I was completing on it (in parallel with the TWR-K22F120M, which was always behaving normally).

At these links I have posted KBOOT compatible (UART and USB-HID) loaders (including also USB-MSD composite since the KBOOT PC tool is presently too slow for productive use)

http://www.utasker.com/kinetis/FRDM-K22F.html

µTasker Kinetis TWR-K22F120M support

Then I re-verified with the freedom_bootloader.bin (powering the board via the OpenSDA connector and directly via the K22's USB connector).

1. Connecting and powering directly to the K22 causes enumeration to start but it fails during the process. I think that the embedded code sets the USB to suspend state (maybe much too soon, and during the enumeration). Since the reset button doesn't work when powered like this the board is then not further usable.

2 Powering via the OpenSDA connection and connecting the K22 USB doesn't do much useful - I didn't see it responding to any enumeration SETUP tokens and it set itself to suspend again.

However, a reset using the push button then allows it to work and KBOOT can subsequently be used.

So I tried the compatible KBOOT version that I had prepared in both configurations as comparison (you can do the same if you are interested - the binary "uTaskerSerialBoot_FRDM-K22F_KBOOT_HID_UART_MSD.bin" is on the linked page.

In both cases the enumeration (there is a lot more activity since the MSD hard drive is also being mounted by the PC on connection) was normal and the MSD part worked correcty.

I am not sure about the KBOOT PC software because I find that sometimes it doesn't see the interface and when I close and open it again it then it does (I think that it is generally not yet very stable).

Therefore I can confirm that the KBOOT embedded USB-HID mode is presently not reliable on either connection configurations. A manual reset recovers (when powered by the OpenSDA connector) but it never operates when powered only via the K22 USB connector. In comparison, I can use the uTasker KBOOT compatible version in both configurations. This means the issue must be of embedded SW nature and so improvements must also be possible.

Regards

Mark

µTasker Kinetis support

[brunopaillard]

Hi Mark

Much the same here!

I can add the following details:

-     The reset button on the FRDM K22 board can work if jumper J9 is moved. In that case the reset does not come from the OpenSDA MCU anymore, but directly goes to the target K22 MCU. In that case also a reset makes things right even if the OpenSDA MCU is powered off.

-     I am not using the KBOOT PC tools, so I cannot comment on them. It is possible that they have their own reliability problems. But the tools that I made for production do work reliably (once the board is manually reset).

-     I have tried to boot is slow mode, it does not change anything.

-     I have tried to disconnect the Open SDA MCU as much as possible, thinking it may be an interference caused by the Open SDA MCU waking up and doing "something" to the K22 while it is enumerating. I have removed UART isolation resistors R66 and R68, as well as cut the permanent trace on header J4. This does not change anything.

-     It is possible that the firmware sets the MCU's transceiver to suspend at the wrong time. What I observe in sequence is (not exactly what I reported initially):

     -     The enumeration proceeds very well up to the end. The last commands are Set-Idle and then Get-Report-Descriptor, both of which are answered correctly by the K22.

     -     Right after that the PC begins sending IN packets (normal process of probing the HID device for an IN report), which the K22 NAKs for a while

     -     After a while (7 to 10 NAKs) the K22 stops NAKing

     -     The PC sends 3 IN packets in sequence that remain without response

     -     Then the PC resets the link, and tried to re-enumerate 3 times

     -     Each time the K22 stays silent

     -     Then the PC places the link in suspend

All of the PC's behavior is normal and consistent with a device that just goes dead and stops responding to all requests. The real question is "why does the HID device go dead right after enumeration?" and more interestingly, "why does it not go dead after enumeration when it starts from a Pin reset?"

Best regards

Bruno

[mjbcswitzerland]

Bruno

It may be worth you creating a service request because you will be relying on the pre-loaded boot loader for production programmig and if the loader supplied in the chips is unreliable it will continue causing production difficulties.

The KBOOT development is very slow (there are still only very few parts supported and the PC tool is not yet suitable for productive use) so you may otherwise be waiting for a final solution long after you want to start your production.

Personally I would just use EzPort for programming all K parts because it is simple and efficient and doesn't restrict a solution to chips that are supplied with a special loader.

Regards

Mark

http://www.utasker.com/kinetis.html

[brunopaillard]

Hi Mark

I may look inexperienced but, how do I go about creating a service request? Can you send me a link, I cannot find this anywhere.

I apologize for the bother!

Thanks

Bruno

[jeremyzhou]

Hi Bruno,

I'd like to confirm that which version you use, Fig 1 shows FRDM-K22F jumper setting and REC details, it works well.

Another point that I'd like to confirm is whether through a HUB or not when you connect the FRDM-K22F to the PC.

Have a great day,
Ping

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

[brunopaillard]

Hi Ping

It seems like I have the same version as you show. See picture:

I tried on a USB2 root, USB3 root, and USB3 hub: No difference.

I am not sure that the USB module goes into suspend, but it is clear that it stops responding after enumerating. See the trace below when the USB connector is inserted:

Notice the 3 un-responded IN packets right after the last Get_Report_Descriptor.

After "Button" reset it goes well (See below):

[brunopaillard]

Hi Ping

Can you confirm the following please?

- The version of firmware that I use is flashloader_loader.srec from FSL_Kinetis_Bootloader_1_1_0\target\MK22F51212\binaries

- I placed it in Flash of the MCU using the Flash tool in KDS (using the J-Link OpenSDA connection connected on J5)

Is that the correct firmware and procedure?

Bruno

[jeremyzhou]

Hi Bruno,

I used the flashloader_loader.bin which resides in ~\FSL_Kinetis_Bootloader_1_1_0\FSL_Kinetis_Bootloader_1_1_0\targets\MK22F51212\binaries.

And I installed the flash load to onto the FRDM-K22F board through the way that mentioned in the Demo Applications User-s Guide for the Kinetis K22 Platforms.

I've attached the doc and you can refer to it for details.
Have a great day,
Ping

[brunopaillard]

Hi Ping

I just bought a brand new FRDM K22F board.

-     Out of the box, I connected to OpenSDA connector.

-     Dragged flashloader_loader.bin to the mbed storage, the way you explained.

-     Disconnected from the OpenSDA connector and connected to the MK22FN512's USB connector.

-     I see two distinct behaviours (sometimes one, or the other):

     -     Either it behaves exactly as I described before (enumerates, and then does not respond anymore and the host closes the link)

     -     Or does not enumerate at all (never responds, enumeration stops after 3 attempts from the host)

-     In all cases after pressing RESET enumeration proceeds normally, just as I described.

In the documentation that you provided the text always asks the user to "PRESS THE RESET BUTTON ON THE PLATFORM", and of course when you do that it enumerates correctly, as I indicated before.

But when the MK22FN512 boots from a USB connect (POR reset), the flashloader_loader firmware does not enumerate correctly.

Is there something that I am doing wrong?

Bruno

[jay_heng]

Hi Bruno,

KBOOT team has already knew this issue, We are working on it. Seems there are many factors that influence this problem: FRDM hardware, SDA MCU firmware, bootloader code, etc...

Will update the info if we find out the root cause.

Best Regards,

Jay