Hello, everybody!
I would like to share with you a USB MSD Host bootloader I developed in MCUXpresso 10.0.0 with SDK v. 2.2 drivers and FreeRTOS. Most of the code was taken and reused from SDK's "usb_host_msd_fatfs_freertos" demo code and the application was adapted from AN4368 USB MSD Host bootloader code for TWR-K70 (also posted on this Community: https://community.nxp.com/docs/DOC-102616).
This bootloader reads the application's raw binary (.bin) file stored in a USB memory stick and programs it into Flash area reserved to the application.
Status messages are sent through the MCU's UART connected to the Freedom board's Open-SDA port to the personal computer and can be seen on a Serial Terminal.
Attached are two bootloader versions: one for FRDM-K64F and the other for FRDM-K22F, as well as a user guide, boarding the following topics:
The projects files and folders are not linked to anywhere and their paths are referenced to the workspace in MCUXpresso, which means that it can be imported and copied to your own workspace.
I'm not an advanced level programmer, it is the first time I write and publish a document like that and I know that either the software and the document can be improved. For this reason, all the source code is open and I leave an .docx version of the user guide so anyone can modify it for better.
I hope it can be interesting and helpful for somebody.
Required setup:
Best regards,
Marco Aurelio P. Coelho
DFAE - Siletec Eletronica
Yes I need, can you send me?
Hi Alexandre
As we talked by e-mail, I was able to migrate the code to MK22FN1M0AVLL12 and sent it to you and by the images you sent me by e-mail, the status messages displayed show that all worked.
The last update from you was that your application is not running.
Could you please send me your application so I can check if it is correctly configured for the bootloader?
Thanks and best regards!
The bootloader, the person Marco P Coelho from SILETEC help me, the
bootloader I think it is operating, but the image.bin
(pisca_LED_TESTE_BOOTLOADER) that is the application that is loaded from
pen drive is not running after the bootloader charge the application. I
make the modifications but not run.
2018-07-27 13:57 GMT-03:00 MAPC <admin@community.nxp.com>:
NXP Community
<https://community.freescale.com/resources/statics/1000/35400-NXP-Community-Email-banner-600x75.jpg>
Re: USB MSD Host bootloader for K22F and K64F MCU's
reply from Marco Aurelio P. Coelho
<https://community.nxp.com/people/MAPC?et=watches.email.thread> in *Kinetis
Microcontrollers* - View the full discussion
<https://community.nxp.com/message/1039522?commentID=1039522&et=watches.email.thread#comment-1039522>
Hello avppoian,
Is it possible for you to share the final project? We would also like to implement the same bootloader on the same MCU.
Regards,
Mark
Marco Aurelio P. Coelho with engineers of NXP help me to solve the problem, now is working well. I will send my contribution of MK22FN1M0AVLL12 bootloader to Marco. Thank you very much.
I am trying to use this for MK22FN1M0AVLL12 but not work, I tryed a lot of things to change but not work. Anybody can help me about this to portate the code to this microcontroller?
Hi Alexandre
The K22 on the FRDM-K22F board is an F7 type and the K22FN1M0 is an F5 type, whereby there are a number of incompatibilities.
You will thus need to use a different set of HW library files and possible modify some of the driver code to be able to work with the other part.
Both F5 and F7 K22s are supported in the uTasker serial loader (it adapts itself automatically without needing different libraries) if you need immediate operation to avoid a porting exercise. If you are only allowed to use unsupported open source code you can still find the same functionality in the open source version at GitHub. The full-featured and supported professional version is available for evaluation if you contact me.
Regards
Mark
Hello, everybody
I substantially reduced the bootloader codes by optimizing them to Release mode and disable SDK_DEBUG_CONSOLE option in Preprocessor Settings.
Now FRDM-K22F bootloader takes 34,712 bytes of Flash and 46,044 bytes of RAM, but it actually takes 49,152 bytes if Flash, since the first three blocks of 16K must be protected against erasing and writing. At least, we can save 16K more to the application. The code was modified to jump to reprogram the application code starting from 0xC000.
The FRDM-K64F bootloader takes 34,680 bytes of Flash and 46,056 bytes of RAM, but it actually still takes 65,536 bytes of Flash, since the first two blocks of 32K must be protected against erasing and writing.
Regards,
Marco Coelho
DFAE - Siletec Eletronica
Hello everybody again!
I have created updated versions of the USB MSD Host bootloaders for FRDM-K22F and FRDM-K64F with the newest version of SDK v. 2.3. Although the user guide mentions SDK v. 2.2, all the steps can also be followed for SDK v. 2.3 versions.
The frdmk64f bootloader firmware takes 61,704 bytes of Flash memory and 50,676 bytes of RAM memory and the frdmk22f bootloader firmware takes 63,920 bytes of Flash memory and 49,904 bytes of RAM memory.
The printf functions were replaced with low level functions for saving Flash memory.
Have them attached bellow.
I hope it can be helpful for somebody.
Thanks and best regards,
Marco Aurelio P. Coelho
DFAE - Siletec Eletronica
Hi Marco
Have you analysed why the loader is so large? When I compare with the uTasker USD-MSD host (memory stick) loader with debug output enabled on UART I get 27.4kBytes for FRDM-K64F, FRDM-K22F it is 27.3kBytes and for a FRDM-KL25Z 26.8kBytes. In each case it requires around 5k of SRAM.
The flash requirements are about 45% and the SRAM around 10% of the values that you are seeing.
Do you have compiler optimisation enabled and do you know whether the overhead is coming from a particular library in the framework? If I use FreeRTOS as OS rather than the uTasker OS I get about 5k Flash and 4k SRAM increase which is not that significant so I suspect maybe specific drivers or stack are not efficiently utilised in some way (?)
Note that if I enable both USB-MSD host (memory stick) and USB-MSD device loading so that either can be used (auto-detection) the flash requirement is around 34k and SRAM increases by 1k.
Eg. of loader operating with debug on output:
uTasker Serial Loader V1.5
===========================
[0x00008080/0x00025fff]
bc = blank check
dc = delete code
ld = start load
go = start application
> Switching to host mode
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 - Passed
UFI REQUEST SENSE -> Status transport - Passed
UFI FORMAT CAP. -> Stall on EP-1
EP-1 cleared
Status transport - Failed
UFI FORMAT CAP. -> Stall on EP-1
EP-1 cleared
Status transport - Failed
UFI FORMAT CAP. -> Status transport - Passed
UFI READ CAP. -> Status transport - Passed
Mem-Stick mounting...
***Disk E mounted
Mem-Stick present
**********************************************File valid
**********************************************
Software Updated
I think that is is important to ensure that a maximum of 16k SRAM is required and maybe less that 32k Flash otherwise it restricts use to larger devices and excludes its potential in a lot of smaller KL parts with USB.
Regards
Mark
Hi, Mark
Yes, I agree that my code is too big and I need to improve it, specially to support smaller parts in future as KL MCU's. So far, I could reduce FRDM-K22F firmware to 60,444 bytes of Flash and 49,904 bytes of RAM by disabling SDK Debug Console (SDK_DEBUGCONSOLE=0) in Compiler Settings /Pre-Processor. Relib(nohost-nf) is the library that more reduces Flash memory, keeping support to File System functions.But it is too much yet. What more optimizations do you recommend?
Maybe, I have to enable compiler optimization or move it to release mode. I'm afraid that some optimizations can damage the code. Anyway, I always keep it baked it up. I'll be working on it and I let you know if I get some progress.
Thank you very much for your comment. Suggestions, hints and complaints are always welcome.
Best regards!
Marco Coelho
DFAE - Siletec Eletronica
Hi Marco
You should be able to optimise for size - if code stops working it is because the code is incorrectly written and needs to be fixed - it is (normally) not that the compiler breaks the code.
You can get references for USB-MSD host loaders for most Kinetis devices/boards at the links below in case you want to compare settings and the code itself. They can be imported to KDS or build with CW, IAR, Keil, Green Hills, Atollic, Crossworks, CooCox, etc. whereby IAR will generally give the smallest code even if it is only a matter of a few percent smaller.
Not that the USB-MSD host (memory stick) loader supports also encrypted binary files, which is a feature that is requested in many real use cases.
Regards
Mark
Free Open Source solution: https://github.com/uTasker/uTasker-Kinetis
Working project in 15 minutes video: https://youtu.be/K8ScSgpgQ6M
Fleible boot loader: http://www.utasker.com/docs/uTasker/uTaskerSerialLoader.pdf
- UART SREC, iHEX, KBOOT, AN2295 Developer's serial loader compatible
- USB-CDC (SREC, iHex)
- USB-HID AN4764 compatible and KBOOT
- USB-MSD binary, iHex, SREC
- USB memory stick
- SD card
- Modbus UART RTU/ASCII
- Modbus/TCP
- I2C
- Ethernet web server
Multiple loader methods can be enabled at the same time!
Mark,
I created this project to meet a customer's need and I thought it would be good to share it with you in NXP Community.
But there is no doubt that uTasker is a better and much more complete solution than mine. Besides, supporting multiple interfaces and encrypted binary files really is a great advantage. Congratulations for your solution and thanks for sharing it with me.
I'll keep working to improve my bootloader in my spare time.
Best regards,
Marco Coelho
DFAE - Siletec Eletronica
Hi Marco
Thanks for explaining the background of your project, it always puts thing in to a better perspective to know such details.
I expect that you will find that the FAT that is used includes things that are not needed and can be reduced. The FAT is also the largest part of the SD card or memory stick in the uTasker solution (there are a certain amount of things that it needs to be able to do that requires also quite a number of lines of code to be compatible with FAT12/16 and 32 with long file name support, etc. (about 10k code). A USB-MSD loader with just USB stack and no FAT is about 16k in total size (OS, Flash driver, USB driver, USB class, loader application).
Good luck!
Regards
Mark
Good job!
Thank you for the contribution!
You are welcome, Hui_Ma!
Regards!