(Thanks Daniel)
I took some time here to try and explain to others what is really going on and what I learned. It is on the web but scattered through many documents. It all stems from the fact that there are two USB ports on the Freedom Dev Kit and two processors. The K20 and the K22.
One is for the OpenSDA (K20) debugging interface processor and the other for our target (K22) processor. Both processors can run a bootloader and an application.
As you can see in this image, there are two USB ports on the Freedom Dev kit. The one connected in the picture is for the OpenSDA (K20 processor). The other one is for us (K22 processor). This is very important because both ports can show up in Windows as a USB memory interface with different names. Note: In this picture, I also connected the Segger EDU Mini debugger to unbrick my K20 OpenSDA processor. (another thread on this forum)
Let's quickly start with the K20 OpenSDA processor. It is running a bootloader and an application. If you hold SW1 / Reset button down while plugging in the OpenSDA USB port, the K20 will boot up in its bootloader mode. Depending on the version of the bootloader, it will look in windows like BOOTLOADER (OpenSDA v2.1) or DAPLINKBOOT (OpenSDA v2.2).
Now, if you don't hold the SW1 / Reset button down while plugging in the OpenSDA USB port, the K20 will boot its OpenSDA Application (You can find various ones on the web from mbed, segger, etc.). These applications are what makes debugging nice and easy from MCUXPresso. I used the file "01_OpenSDA_FRDM-K22F.bin" and it allows the K20 to show up in windows like E:/FRDM-K22J with the following files on it.
The USB Port connected in the picture above is for Debugging our target processor (K22). You can also drag and drop any compiled application (*.bin file) on to the E:/FRDM-K22J drive and it will program the K22 assuming you leave the default link address in flash alone (0x0000). You can do this from now until the end of your debugging your application and be very happy. I did not want this, I wanted a Bootloader on the K22 that always remains resident and there is a SDK package which contains the bootloader and the blinky examples.
Once I compiled the bootloader (linked to address 0x0000 which is the default), I can drag and drop it on the E:/FRDM-K22J drive via the OpenSDA USB port and it will run.
You can now move the USB cable to the K22 USB port and see our bootloader. It will show up in windows as "E:/FSL Loader"
Now, you can build applications for the K22 linked just above the bootloader at address 0xA000 as shown in this image.
After you install an application linked to 0xA000 and resey the board, the K22 will look to see if SW3 is pressed. If it is pressed, it will stay in the bootloader and show up in windows as "E:/FSL Loader". If it is not pressed, it will jump right to the application. (All of this behavior is controlled in the bootloader config.h file when compiling the bootloader.
WARNING : As of this time, you cannot drag and drop binary files (*.bin) on to the K22 bootloader, they must be in *.sb file format. The basic command to do this is "elftosb -V -c led.bd -o led.sb" where the configuration *.bd file format is show here.
C:\temp>type led.bd
sources {
# BIN File path
myBINFile = "frdmk22f_led_demo_freedom_a000.bin";
}
section (0) {
#1. Erase the internal flash
erase 0x0000a000..0x0010000;
#2. Load BIN File to internal flash
load myBINFile > 0xa000;
#3. Reset target.
reset;
}
I hope this all helps, I have moved on to modifying the bootloader for better behavior.
Hi Gary:
Please refer to following doc for the location of the bootloader and application
SDK_2.5.0_FRDM-K22F\middleware\mcu-boot\doc\MCU Bootloader Demo Application User's Guide.pdf
Regards
Daniel
