Bootloader MSC does not work - without my patches...

[davenadler]

I find in the bootloader reference manual that drag-and-drop to MSC only supports SB format files.
I found the ELFTOSB user guide, which states that the ELFTOSB executable is included in the bootloader package.
OK, I found the ELFTOSB executable, but...

1. The bootloader package provides the elftosb sources, however they fail to build (using Visual Studio 2012).
   My bad, it clearly says needs a newer version of Visual Studio.
2. The examples provided for the bootloader do not include the necessary conversion from ELF to SB !!!
3. I tried to use the BD file in the root of the LED blinker app, and while elftosb appears to work, the generated SB file does not work. At Frank's suggestion I also tried using SREC instead of ELF with same results (unlike ELF, SREC doesn't generate the incorrect RAM fill instructions below). I also tried changing "erase all" to section erases, with same result.
   make --no-print-directory post-build
   Build boot-loadable SB file
   elftosb.exe -V  -z -c C:\K64\NXP_Kinetis_Bootloader_2_0_0\apps\led_demo\src\led_demo_drn.bd -o led_demo_freedom_A000.sb led_demo_freedom_a000.elf
   warning: line 10: end address of address range is before start address
   warning: line 11: end address of address range is before start address
   warning: line 12: end address of address range is before start address
   warning: line 13: end address of address range is before start address
   Boot Section 0x00000000:
     ERAS | adr=0x0000a000 | cnt=0x00000004 | flg=0x0000
     ERAS | adr=0x0000a400 | cnt=0x00000004 | flg=0x0000
     ERAS | adr=0x0000a800 | cnt=0x00000004 | flg=0x0000
     ERAS | adr=0x0000ac00 | cnt=0x00000004 | flg=0x0000
     LOAD | adr=0x0000a000 | len=0x00000400 | crc=0xedb4632d | flg=0x0000
     LOAD | adr=0x0000a400 | len=0x00000010 | crc=0x7bf1a8b4 | flg=0x0000
     LOAD | adr=0x0000a410 | len=0x000005fc | crc=0x18f25f7b | flg=0x0000
     FILL | adr=0x1fff0000 | len=0x00000400 | ptn=0x00000000
     LOAD | adr=0x1fff0400 | len=0x00000084 | crc=0x64bc47db | flg=0x0000
     FILL | adr=0x1fff0484 | len=0x00000020 | ptn=0x00000000
     FILL | adr=0x1fff04a4 | len=0x00000004 | ptn=0x00000000
     FILL | adr=0x1fff04a8 | len=0x00000400 | ptn=0x00000000
     JUMP | adr=0x0000a4d9 | arg=0x00000000 | flg=0x0000
   
4. When I drag&drop led_demo_freedom_A000.sb to the bootloader, the chip resets... but LEDs never blink.
   The STATUS.TXT file goes from "Ready" to "Transfe" and sits there like loader never completed.
5. I get exactly the same results with pre-built bootloader (as with the bootloader I built with KDS specifying only MSC):
   C:\K64\NXP_Kinetis_Bootloader_2_0_0\targets\MK64F12\iar\binaries\freedom_bootloader.bin
6. There are no prebuilt example SB files provided with the bootloader!
7. The example LED program is built properly. If I directly flash the LED example, and then restart the board by plugging in only the K64F USB, the bootloader starts, then branches to the LED application and the LED blinks.
8. This makes it certain there is something wrong with the ELFTOSB processor and/or the bootloader!
   We need your help in getting this resolved!
   Similar problems have been reported here: https://community.nxp.com/thread/436171

Can you please provide:

1. An example BD file for the LED blink application, that creates an SB file which actually works with the bootloader?
2. Current sources for ELFTOUSB that build correctly with Visual Studio?

Thanks!
Best Regards, Dave

PS: K64F Freedom board, latest Kinetis Studio 3.2.0, SDK2.0

PPS: Here's the BD file:
// 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 {
     demo = extern(0);
}

// create a section
section (0) {
    //  erase all;
    erase 0x0000A000;
    erase 0x0000A400;
    erase 0x0000A800;
    erase 0x0000AC00;
    //erase 0x0000B000;
    //erase 0x0000B400;
    //erase 0x0000B800;
    //erase 0x0000BC00;

    // Doesn't work: load $A1*, $P1* from demo;
    load demo;

    // jump to entry point
     jump demo;
}

[ramboyang]

Hi Dave,

1. Regarding the elftosb compiline issue, VS2015 is required to build elftosb successfully. Please refer to Section 2 Development tools in Kinetis Bootloader  v2.0.0 Release Notes.pdf  for more details.

2. Regarding  sb generating, it is highly recommended to generate SB file with srec file or binary file, KEIL, IAR, KDS, ARM-GCC all support generating srec easily. Of course, the elf file is also supported for SB file generation, but the elf file contains both RW data and RO data, some filters are required to filter the RW data out, otherwise, the elftosb tool will try to load all sections to SB file, which may hit the reserve RAM region, just as what you have seen in your case. Besides, the filter may vary among different project, it  fully depends on the linker file.

[davenadler]

I finally got MSC bootloader working on Freedom K64F. Here's what I had to do:

1. Bootloader as delivered produces NO INDICATION OF WHAT FAILED when it doesn't load an SB file.
   Modify bootloader to:
   - Fix bug that truncated reported status in STATUS.TXT file
   - Add report of last SB operations status result to the STATUS.TXT file.
     Look up this status in the bootloader reference manual to find out what went wrong!
2. Bootloader as delivered was, err, challenging to debug with MSC. For debug build:
   - Write debug_printf's to new DEBUG.TXT file; now easy to debug!
3. Local configuration changes to bootloader:
   - enable ONLY BL_CONFIG_USB_MSC (not HID or others)
   - disable BL_FEATURE_FLASH_SECURITY
   - disable BL_FEATURE_ENCRYPTION_MMCAU
4. Bugs in ELFTOSB cause it to emit erroneous load and clear commands for RAM, despite specific statement in the ELFTOSB manual stating ELFTOSB will not emit such instructions. See the original posting above for an illustration. Since NXP delivered obsolete/wrong ELFTOSB sources as explained above, I can't fix it. Consequently, per Frank's suggestion, use SREC format to create SB file (for which ELFTOSB doesn't have this bug).
5. As I can't find an example of how to set up any of the security features, and got security-related errors from the bootloader, all the security features are disabled.

I've attached the code with the above bootloader bug fixes and enhancements.

I'll post a separate question about the security setup.

NXP: Please:

1. Provide correct ELFTOSB source code!
2. Incorporate the attached fixes into the bootloader!
3. Provide a working bootloadable SB-format example including security features!
4. Fix ELFTOSB so it does not emit incorrect RAM fill/load operations in SB file!

Thanks,
Best Regards, Dave

PS: If anyone wants to try this quickly on the K64F Freedom board, I've attached the prebuilt bootloader and example program. First, drag the bootloader BIN onto the mbed virtual drive. Then, unplug the debug USB, plug in the K64F USB, and drag the blinky SB file onto the bootloader's virtual drive.

[ashesman]

Great work.  Really saved my a^$e!

I spent hours today trying to work out why this stupid thing wouldn't work!  I copied your modified files into my project and away it went!  The source files were all good.  The project files reference absolute paths eg source files and post build so needed a bit of a tickle up.

The supplied .ld file does not seem to work with srec files.  It gives error: line 8: source type does not support sections.  However, just using the basic file below seemed to work fine...

sources {
myElfFile = "led_demo_freedom_a000.srec";
}
section (0) {
erase all;
load myElfFile;
reset;
}

Thanks for all your work.  I hope NXP pull their fingers out of their butts and apply the necessary changes to get this all working properly.  And also support some more part numbers!!!

Cheers

Ashley

[frankvanhooft]

Congrats Dave for getting it working, and thanks very much for posting your updates. I'm quite curious to do a diff to see the bug fixes you did.

[frankvanhooft]

Dave, welcome to the battle. I also struggled with silly compile errors and the like to get things working. (Although I never tried building the elftosb tool.)

One thing you might try, is to convert a Srecord file to an .sb, not an ELF. The elf file contains RAM information which (in my experience) seemed to confuse the elftosb tool (or something). I had better results converting s-record files, which only contain flash information.

Given that the blinky app is so simple, just a few lines of code, you can easily build & download it (using jtag) on its own and confirm it works on your hardware. Also make sure you're building it for the correct start address. I don't know what it'll be for the K64, but it won't be 0x00000000 the start of flash; it'll be much further along in the flash to allow space in flash for the bootloader first - in my case I build the app for a start address of 0x8000, and my bootloader builds to a size of about 26kB so that's comfortably inside of the allocated 0x8000.

Good luck.

Frank.

frankvh.com

[davenadler]

Thanks Frank. I already checked the sample LED blink loading the debugger (works fine). Per your suggestion I also tried SREC, does not work either. I updated the question above to clarify all this. Lets hope NXP responds before my customer here says "move on to a different vendor"...