uTasker for FRDM-K22F, too many options

[davepfaltzgraff]

I have downloaded the uTasker code for the FRDM-K22F on the KDS IDE and find my mind boggled by the options. My goal at this time is to be able load a USB-MSD bootloader on to the FRDM-K22F and then use that to load a simple application. (I guess like Blinky.)

So, I have some simple questions to get me focused:

1. Which build version do I want? The IDE gives me a choice of 7!

2. Where can I find project for the application, like Blinky, that has an appropriate 'ld' file?

I have been able to get a clean build, but I am not sure I'm on the right track.

Thanks, Dave

[mjbcswitzerland]

Hi David

1. Which IDE will you be using? If KDS, MCUXpresso or other Eclipse based one you may find this step-by-step video of use: https://www.youtube.com/watch?v=K8ScSgpgQ6M&list=PLWKlVb_MqDQFZAulrUywU30v869JBYi9Q&index=9
It explains the targets, whereby the standard one is the uTaskerV1.4_Flash (for application) or uTaskerSerialLoader_Flash for the serial loader so you will want to build the serial loader one and then the application.
For a written guide see https://www.utasker.com/kinetis/compilers.html

When built you will find binaries in the output directories
\Applications\uTaskerSerialBoot\KinetisDesignStudio\uTaskerSerialLoader_FLASH
and
\Applications\uTaskerV1.4\KinetisDesignStudio\uTaskerV1.4_FLASH
(assuming KDS is used). The first can be loaded to the board and then second then by the serial loader.

2. There is one single project for the application (not multiple examples) and the single project can be configured for any processor, board and many options.

So that one can start simply there is a define in the application's config.h called BLINKY and if you enable it it will automatically reduce the complete project to the simplest case (a single LED output blinking at 2.5Hz - retriggering the watchdog via a task controlled by the SYSTICK interrupt). Choose FRDM_K22F as board and ensure that the Cortex-M4 core (or board/part accordingly) is selected in the IDE and the correct linker script is used (for this board it is K_512_128.ld as also shown here: https://www.utasker.com/kinetis/FRDM-K22F.html)

Once you have the blinky project working you can instead do a "Hello world" one (enable HELLO_WORLD instead) which again will work on any board with no more configuring.

The next step is to remove these two defines and then you have the complete project with USB stack, file system and various other features which can be configured by enabling or disabling the defines in the same file - eg. if you want USB device operation in the proejct just enable USB_INTERFACE and USB_DEVICE_SUPPORT and choice which class(es) should operate (like USE_USB_CDC, USE_USB_MSD, USE_USB_AUDIO, etc.)
Another example: USE_MAINTENANCE will add a command line interface on UART, USB-CDC and Telnet (depending on which are available) with mny menus line low power control, memory monitoring, memory viewing and debugging, etc.). If it is not desired just command out USE_MAINTENANCE.

For HW specific adustments use app_hw_kinetis.h where you can more select HW specific things like the clock and pins used or UART instance used by the command line interface, plus enable or disable peripherals (ADC, DAC, CAN, port interrupts, etc.) so that you can be sure you have only exactly what is really needed by the overall project. (The default will be fine for all development boards and custom target can be may there by copying the closes existing board and changing the details).

The idea is that any board can be configured with many different features without needing to change code or take parts from specific examples and manually mix them to get a complete product. Instead one just configures as much or as little as needed, on which ever board or processor. If the processor is changed there is no more work than select the different board. And if more capability is needed just select an i.MX RT and have the project running there instead.

Once you get to a stage where you want to further customise the project configuration (with new task and application controls) this video [https://www.youtube.com/watch?v=_7Rxdr0NKWE&list=PLWKlVb_MqDQFZAulrUywU30v869JBYi9Q&index=23] shows how to go about that so that the final project shares all common resources but the custom parts can have its own repository.

A playlist of videos showing various topics is here: https://www.youtube.com/playlist?list=PLWKlVb_MqDQFZAulrUywU30v869JBYi9Q

There are i.MX RT videos too at https://www.youtube.com/watch?v=GXztWg9m6_8&list=PLWKlVb_MqDQEOCnsNOJO8gd3jDCwiyKKe which are more or less identical in the use case so anyone who can build (and develop) for Kinetis can move to i.MX RT without really needing to do anything differently or learn new tools, libraries and code.

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]

[davepfaltzgraff]

HI Mark,

What I found out was that there was a problem with the OpenSDA loader application on the FRDM-K22F board. With Erich Styger's help, I got that cleaned up and now I am able to compile and load the uTasker application and have the unit show up as DATADISK 1 on my system. So, at this point I have the basics up and running.

What I need now is the information I need to change in my ld file (like K_512_128.ld) so that the application is put where it will run with the relocated vector table, etc. For example to use an example from the Kinetis SDK. I sort of remember seeing that information somewhere, but now that I got this far I can't seem to find it again! Could you please provide a pointer?

Thanks, Dave

[mjbcswitzerland]

David

Beware that you have loaded the uTasker application project and not the serial loader (the serial loader will give you "UPLOAD_DISK", whereby the application that you have built is emulating FAT according to https://www.utasker.com/docs/uTasker/uTaskerEmulatedFAT.pdf

You can also quickly distinguish loaders from applications since loaders flash the LED at 5Hz and application as 2.5Hz.

There is a guide to preparing applications for use with the serial loader in appendix B of https://www.utasker.com/docs/uTasker/uTaskerSerialLoader.pdf whereby you can also use K_512_128_BM.ld as a reference. The only difference is the link address, which is (by default) 0x8080 for MSD loader operation (and application don't need to contain flash configurations). SDK examples will tend to run with such a linker script change as long as they relocate their interrupt vectors to SRAM (the start of SRAM) and don't leave them in Flash.

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]

[davepfaltzgraff]

Hi Mark,

OK. I'm back to my original comment of too many options. Let me explain the situation... The device was designed around 5 years ago, and, although patterned after the FRDM-K22F board, is highly utilized. So, the UARTs, SPI, I2C, etc. are committed. Also, there is no pin directly available to the user. So far the USB is used for as a CDC device to a PC, or under certain conditions as a  controller for a USB-Serial-Bluetooth device. Because of the type of application, the device has to be returned to the "factory" for any firmware upgrades via a JTAG download. Because of the cost of shipping, it is desired to implement a USB-MSD interface. To keep it simple for the end user, it is felt that only that interface should be implemented.

So, what I am hearing you say now, is that I should focus on only the "SerialLoader" application - in spite of it's name and then go from there. Is that right?

One thing that confuses me is:What is the difference between the BM (bare minimum), Serial, full uTasker1.4, etc.? (When I go to the smorgasbord, I don't know what to taste first!) I am sure this is documented somewhere, but it wasn't clear to me, a novice to this environment.

Just a note: I have been looking around and have found many variations of boot loaders - to the point of blowing my mind! Many of them are old, require very specific development environments, etc., with a good many leading to dead-end or non-existent web pages. I feel that the uTasker approach will work, but the variations are too many for someone with my limited experience to cope with. So far, the document that you reference in your last paragraph seems to be the most helpful.

Thanks, Dave

[mjbcswitzerland]

Hi David

From what you have described the serial loader is, as you also say, what you need. You can do USB-MSD device, USB-MSD host (memory stick) or both at the same time. If you have no user inputs to force the mode you can command it from your application (see the serial loader mailbox description in appendix C of https://www.utasker.com/docs/uTasker/uTaskerSerialLoader.pdf). You can also see the serial loader in operation, with demonstration of it being commanded from the application in this video: https://www.youtube.com/watch?v=dq-m-Dokq7E&list=PLWKlVb_MqDQFZAulrUywU30v869JBYi9Q&index=28 (it is not on a Kinetis but the Kinetis works identically, as do i.MX RT parts).

As background information:
- the "Bare-minimum" loader is used mainly as support for over-the-air (OTA) loading. It is named "Bare-Minimum" (historically) because is used the absolute minimum code to do such a job and can't actually live by itself but instead is combined with an application which actually does the loading of the code. It does however guarantee fail safe uploading and encrypted loading in 2..4k of code (usually occupies one flash sector) and has been used reliably in millions of devices since 2004 when it was first used. It is described in "Bare-Minimum" Boot Loader: https://www.utasker.com/docs/uTasker/uTasker_BM_Loader.pdf and there is also a video at https://www.youtube.com/watch?v=lm3M-ZlaFLQ&list=PLWKlVb_MqDQFZAulrUywU30v869JBYi9Q&index=17
It requires the application to "receive" a new (optionally encrypted) version and save it to either internal or external flash, reset and the "BM" loader completes the replacement of the old application by the new one.

- The serial loader is called "serial loader" because it allows loading new code over serial interfaces (UART, USB, Ethernet, I2C, SPI/SDHC). It is also known as a "standalone" loader since it 'can' live alone. That means it can be loaded to a board by itslf and applications then loaded/replaced using it. It can't (safely) update itself with a new serial loader though (but can do so if combined with the "BM" loader - this is however another story so I'll not diverge here but do see the i.MX RT loader video below).
This is certainly the one that you need and the various serial interfaces and how to configure them are detailed in the serial loader's guide: https://www.utasker.com/docs/uTasker/uTaskerSerialLoader.pdf
If you know KBOOT, or MCU Loader as I think it is called now, you will be familiar with "serial" loading. The uTasker serial loader includes KBOOT compatible loading on UART or USB HID but adds support for all Kinetis devices (rather than needing to port to otherwise not supported devices) and adds more features and loading modes (it also adds AES256 encrypted loading to KBOOT, as it also does to other methods).
The most popular mode tends to be USB-MSD mode and you will usually find the serial loader project pre-configured for this (probably composite with KBOOT USB-HID and SREC/iHEX on UART) so enabling the board type you want and building should essentially already give you the operation.
There are some serial loader videos:
- https://www.youtube.com/watch?v=bilc_4Cr7eo&list=PLWKlVb_MqDQFZAulrUywU30v869JBYi9Q&index=13
- https://www.youtube.com/watch?v=awREsqeCEzQ&list=PLWKlVb_MqDQFZAulrUywU30v869JBYi9Q&index=22
- https://www.youtube.com/watch?v=MXsJvTdCcH4&list=PLWKlVb_MqDQFZAulrUywU30v869JBYi9Q&index=25
This one details the further development of the concept for use on i.MX RT parts, where the same serial loader and encrypted OTA support is fully integrated: https://www.youtube.com/watch?v=2XfgZq19XDw&list=PLWKlVb_MqDQEOCnsNOJO8gd3jDCwiyKKe&index=4&t=28s

- uTaskerV1.4 application is an application (like your application) containing a certain, configurable functionality that usually gives 90% of what is required for most projects immediately so that develops can get on with adding the actual additional functionality to realise a specific product rather than first needing to learn a lot of HW details and put various peripheral examples together to try to get a working framework to start with. Essentially it usually allows halving development times in comparison with going the traditional way and so is of interest to project developers who need reliability and short project cycles and thus lower development costs.
Since you already have an application this is not of use to you in this project.

Basically it is true that the uTasker project has very many possibilities but if you know which method you want you can just select it and it will already solve your present requirement without needing to learn or use the other features today.

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]

[davepfaltzgraff]

Hi Mark,

After getting sidetracked for a few days, I'm back on to this. But, I feel as though I must be doing something wrong. I'll admit I need hand-holding, but this  is only frustrating me. Based on your last response, I went back to the original downloaded code and built up an image. On trying to run it, I immediately hit the "unknown interrupt" and it seems to be when the program enables the watchdog. A key clue is that the reset LED blinks at a 2 second rate.

I thought, OK, download the code from the web site (uTaskerSerialBoot_FRDM-K22F_KBOOT_HID_UART_MSD.bin) and run that. I had to get to a point where SOMETHING worked! But the result was the same - just a blinking red LED.

My configuration is a K22F board with the OpenSDA and the Segger application loaded in to the K20 processor. I connect the PC (Windows 10) to the debug port and run J-Link. The second session is here. (Note the first one loaded fine and this just confirms that the firmware was already loaded.)

====

SEGGER J-Link Commander V6.62d (Compiled Mar  2 2020 09:23:14)
DLL version V6.62d, compiled Mar  2 2020 09:22:41

Connecting to J-Link via USB...O.K.
Firmware: J-Link OpenSDA 2 compiled May 27 2019 11:01:03
Hardware version: V1.00
S/N: 621000000
VTref=3.300V

Type "connect" to establish a target connection, '?' for help
J-Link>connect
Please specify device / core. <Default>: MK22FN512XXX12
Type '?' for selection dialog
Device>
Please specify target interface:
  J) JTAG (Default)
  S) SWD
  T) cJTAG
TIF>s
Specify target interface speed [kHz]. <Default>: 4000 kHz
Speed>
Device "MK22FN512XXX12" selected.

Connecting to target via SWD
InitTarget()
Found SW-DP with ID 0x2BA01477
Unknown DP version. Assuming DPv0
Scanning AP map to find all available APs
AP[2]: Stopped AP scan as end of AP map has been reached
AP[0]: AHB-AP (IDR: 0x24770011)
AP[1]: JTAG-AP (IDR: 0x001C0000)
Iterating through AP map to find AHB-AP to use
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0xE00FF000
CPUID register: 0x410FC241. Implementer code: 0x41 (ARM)
Found Cortex-M4 r0p1, Little endian.
FPUnit: 6 code (BP) slots and 2 literal slots
CoreSight components:
ROMTbl[0] @ E00FF000
ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 000BB00C SCS-M7
ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 003BB002 DWT
ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 002BB003 FPB
ROMTbl[0][3]: E0000000, CID: B105E00D, PID: 003BB001 ITM
ROMTbl[0][4]: E0040000, CID: B105900D, PID: 000BB9A1 TPIU
Cortex-M4 identified.
J-Link>loadbin z:\David\Freescale\FRDM-K22f\Bootloader\uTaskerSerialBoot_FRDM-K22F_KBOOT_HID_UART_MSD.bin, 0
Halting CPU for downloading file.
Downloading file [z:\David\Freescale\FRDM-K22f\Bootloader\uTaskerSerialBoot_FRDM-K22F_KBOOT_HID_UART_MSD.bin]...
J-Link: Flash download: Bank 0 @ 0x00000000: Skipped. Contents already match
O.K.
J-Link>

====

What am I doing wrong?

Thanks, Dave

[mjbcswitzerland]

Dave

>>Based on your last response, I went back to the original downloaded code and built up an image.
I am assuming you mean a "serial loader" image for the K22.

>>I thought, OK, download the code from the web site (uTaskerSerialBoot_FRDM-K22F_KBOOT_HID_UART_MSD.bin) and run that. I had to get to a point where SOMETHING worked! But the result was the same - just a blinking red LED.

Since that binary is a known good image and is behaving the same as the one you built I suspect the following:
- the serial loader is starting and configuring the watchdog for a 2s timeout
- it detect data where the application is expected to be and so jumps to it
- that data is probably something random in memory (IAR only deletes the code area that it loaded so you may have remaining parts of a previous application.
- this fails and the watchdog fires and  repeats this forever (hence the 2s flashing reset LED).

1. You can do a chip erase before loading the serial loader which should case it to start and remain in the mode because there is no application present
2. Assuming you have the two switches as the FRDM board you can hold the "watchdog disable" one at reset and the watchdog will be disabled rather than enabled. The expected result would be that it fails but doesn't repeat. The only point in doing this is to prove the watchdog reset theory.
3. You can hold the "force loader " switch at reset so that it doesn't try to start a detected application. This would allow you to delete the data that is in the application area and then program a reference application (or yours, which is your main goal).

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]

[davepfaltzgraff]

Thanks, Mark, for the detailed explanation. I'll work my way through it and see how it goes...