Getting started: KBOOT MSC on KL25 questions

[frankvanhooft]

I'm using kboot 2.0 and KDS 3.2. I'm trying to get kboot running as a mass storage device on a MKL25Z128. So that I can plug the KL25 into a PC, have it appear as a drive, then drag&drop a firmware file onto it.

I've succeeded in building KBOOT and programming it into the KL25. I took the "freedom bootloader" project, and modified bootloader_config.h so that only MSC was selected.

#if !defined(BL_CONFIG_UART)
#define BL_CONFIG_UART (0)
#endif
#if !defined(BL_CONFIG_I2C)
#define BL_CONFIG_I2C (0)
#endif
#if !defined(BL_CONFIG_SPI)
#define BL_CONFIG_SPI (0)
#endif
#if !defined(BL_CONFIG_USB_HID)
#define BL_CONFIG_USB_HID (0)
#endif
#if !defined(BL_CONFIG_USB_MSC)
#define BL_CONFIG_USB_MSC (1)
#endif

When I plug the KL25 into a windows PC, a drive pops up! Amazing. What a good start. But I can't progress beyond this.

The "status.txt" file says "ready".  This is Info.txt:

Kinetis Bootloader K2.0.0

System device ID: 0x25152486
Flash size: 131072 bytes
Flash range: 0x00000000-0x0001ffff
Flash sector size: 1024 bytes
Flash blocks: 1
RAM size: 16384 bytes
RAM range: 0x1ffff000-0x20002fff
Reserved region 0: 0x00000000-0x000073ff
Reserved region 1: 0x1ffff000-0x2000111f
Verify writes: yes
Check reserved regions: yes
Boot config present: no
Peripheral detection timeout: 5000 ms
CPU clock: 48000000 Hz

To test the bootloader, I built the example project LED_demo_freedom_8000, then drag&dropped the resulting S-record file (named led_demo_freedom_8000.srec) into the drive. Nothing interesting happened, it appeared to be ignored, and the status.txt file continued to say "ready".  I also tried creating a "raw binary" .bin file instead of a .srec file, but the bootloader didn't appear interested in that file either.

Both the bootloader & the led_demo project were built as "release".

Any idea what's going on?  Why can't I drop the led_demo file into the KL25Z?

Many thanks for any suggestions!

[Jorge_Gonzalez]

Hi Frank Van Hooft,

The KBOOT v2.0 MSC volume cannot take S-Record or binary files. It uses a special kind of file called Secure Binary (sb file). You can refer to the document called "Kinetis Elftosb User's Guide" for details. This document is available in KBOOT installation folder or online:

C:\nxp\NXP_Kinetis_Bootloader_2_0_0\doc\Kinetis Elftosb User's Guide.pdf

http://www.nxp.com/files/soft_dev_tools/doc/user_guide/KBLELFTOSBUG.pdf 

Next document in community can also be useful:

https://community.nxp.com/docs/DOC-332379 

Regards!
Jorge Gonzalez

[frankvanhooft]

Thanks very much Jorge - that's the pointer I needed. I've moved forward a reasonable amount and am now stuck on something new.

I have tested the little "led blinky" test program mentioned above on it's own and it works fine. However, it appears that KBOOT is unable to program it into the flash. I am generating an sb file, and drag&drop'ing it onto the KL25. The status.txt file changes from "ready" to "transfe"  (it cuts off the word 'transferring') and remains stuck there.

What's very interesting is that I can use jlink to program the test blinky into flash, and when I do that KBOOT is happy to run it. KBOOT is setup to wait 5 seconds to check the USB port, then run the user application. So I can power on, wait 5 seconds, and then the LED starts blinking. Perfect! Except it was jlink that programmed blinky into the flash, not kboot.

This is the .bd command file (SimpleLoad.bd):

// Define one input file that will be the first file listed on the command line. The file can be either an ELF file
// or an S-record file.
sources {
inputFile = extern(0);
}

// create a section
section (0) {
    erase 0x00008000..0x0001FFFF;
    load inputFile; // load all sections
    call inputFile; // jump to entry point
}

This is how I call elftosb:

elftosb -V -c SimpleLoad.bd -o led_demo.sb led_demo_freedom_8000.srec

This is the output of elftosb:

Boot Section 0x00000000:
  ERAS | adr=0x00008000 | cnt=0x00017fff | flg=0x0000
  LOAD | adr=0x00008000 | len=0x000000c0 | crc=0x47f47181 | flg=0x0000
  LOAD | adr=0x000083c0 | len=0x00000404 | crc=0xdc8fcc3e | flg=0x0000
  CALL | adr=0x000084e9 | arg=0x00000000 | flg=0x0000

It all looks very reasonable to my eyes. However it seems clear that kboot is not even getting to the point of erasing the flash. (I have tried using an .elf file to create the .sb file, as well as the .srec file, but the end result was the same.)

Any idea why kboot appears to be stuck in the "transferring" state?

Thanks.

[frankvanhooft]

Ah-ha! I have something working. I've been searching the forums and trying many many things. It's obvious other people have been having the same problem, so I'll post my finding here in case it helps others.

The root problem is that specifying an address range to erase does NOT work. For example, the following does NOT work:

// Define one input file that will be the first file listed on the command line. The file can be either an ELF file
// or an S-record file.
sources {
inputFile = extern(0);
}

// create a section
section (0) {
    erase 0x00008000..0x0001FFFF;
    load inputFile; // load all sections
    reset;
}

However, the "erase all" command DOES work.  This works:

// Define one input file that will be the first file listed on the command line. The file can be either an ELF file
// or an S-record file.
sources {
inputFile = extern(0);
}

// create a section
section (0) {
    erase all;
    load inputFile; // load all sections
    reset;
}

A problem for me (and likely many others as well) is I cannot use the "erase all" command, because I store calibration and other user settings in the flash, and I don't want that data blown away during an upgrade.

As a crude solution, putting a whole bunch of individual "erase" commands in the command file also works. For example:

// Define one input S-Record file that will be the first file listed on the command line.
sources {
inputFile = extern(0);
}

// create a section
section (0) {
    erase 0x00008000;
    erase 0x00008400;
    erase 0x00008800;
    erase 0x00008C00;
    erase 0x00009000;
    erase 0x00009400;
    erase 0x00009800;
    erase 0x00009C00;
    erase 0x0000A000;
    erase 0x0000A400;
    erase 0x0000A800;
    erase 0x0000AC00;
    load inputFile;
    reset;
}

(You would think such contortions shouldn't be necessary, given the S-record file already contains addresses, so the elftosb tool already knows the flash address range that needs erasing. But apparently this hoop-jumping really is currently required. If the source for elftosb were available this might be a nice option to add.)

Quite exciting; it's working and I can progress on my project.

Frank.

frankvh.com

[davenadler]

Thanks for this Frank.
I think I understand from your posting: the problem lies in the bootloader v2.0 usb-msc processing of SB format, yes?
Did you fix this or has NXP acknowledged and/or fixed the problem?
Thanks!
Best Regards, Dave

[frankvanhooft]

Nothing that I've heard. I'm just working around it as mentioned above.

Frank.

frankvh.com