10 years, 4 months ago.

How to compile CMSIS-DAP bootloader

Hi all,

We have made a custom PCB with two kinetis processors on it. A K20DX128VFM5 as the debugger and a K22 as the actual processor.

Using Keil uVision v5.11 I can compile the bootloader (source gotten from the GIT repository). I can then program it into the K20 using our debugger running openOCD v0.8.

I then hold the board reset button and execute the code. I see the status LED blink. Then windows pops up with "unknown device". Looking in device manager I see PID 0 and VID 0 which doesn't seem as desired.

Debugging the code I have found that we get the USB IRQ and add the USB setup packet event to an event queue. However that event is never handled.

Debugging further I have found there is something seriously wrong with the .data and .bss sections. A slight mod to the code demonstrates this best:

In main.c just before main_task() add the following: static unsigned int abc = 0xDEADBEEF; static unsigned int def = 0;

Then to stop them being optimised out add the following to the top of the while loop in main_task(): abc++; def++;

Now compile the code and reprogram it and restart the program but do not run on. I can then use the following GDB command to look at the values for abc, def and what's in memory start of the upper bank of SRAM:

p/x &abc p/x &def p/x abc p/x def x/20xb 0x20000000

The results are:

<p/x &abc> 0x2000000C <p/x &def> 0x20000010 <p/x abc> 0x58335c38 <p/x def> 0x232e1955

<x/20xw 0x20000000> 0x20000000 0x11 0x84 0x6c 0xdc 0x02 0x05 0x18 0xef 0x20000008 0xbe 0xad 0xde 0x23 0x38 0x5c 0x33 0x58 0x20000010 0x55 0x19 0x2e 0x23

Now, looking in the memory map produced when building this image, abc is said to live at 0x2000000C and def at 0x20000010

However the values are clearly not being initialised correctly. Even more interesting is that you can see 0xDEADBEEF in the GDB mem dump, bytes 0x2000_0007 - 0x2000_000A. Which is not aligned by 4 as you would expect and is not in memory where you would expect it to be. Further more def should be straight after it, or at 0x2000_0010 but there are no 0s in the output. You may think def shouldn't be programmed in, since it can be zeroed during startup, however I can't find any code to zero anything and the memory map tells me that def is in the .data section.

You can also then stick a break point at the beginning of main_task where you would expect these to have been initialised correctly, and run on. They aren't.

<p/x abc> 0x3ed36f1b <p/x def> 0xecd62120

<x/20xb 0x20000000> 0x20000000 0xff 0xff 0xff 0xff 0xff 0xff 0x55 0x4b 0x20000008 0x34 0x74 0xc5 0xca 0x1b 0x6f 0xd3 0x3e 0x20000010 0x20 0x21 0xd6 0xec

As you can see the data has changed, and is now further away from what I'd expect it to be.

Finally, if you examine the elf (.axf) file, you can see where the code ends and the program data begins, and this matches what is programmed into sram initially (the first GDB dump). This suggests to me the uVision is building the elf wrong, but that seems insane.

I may be barking up the wrong tree, but if anyone could suggest what I'm doing wrong, that would be really useful.

Thanks, Andrew