Debugging uTaskerV1.4_BM.elf on TWR-K64F120M in MCUXpresso

[Stephen]

Hello,

I recently got the uTakser v1.4 code. I successfully configured, compiled, downloaded and stepped through the uTaskerBM_loader.elf bootloader code, and the normal uTakserV1.4.elf (application without bootloader support PFLASH origin=0x0).

Now I would like to do the same with the uTaskerV1.4_BM.elf (application to use with bootloader module with PLASH origin=0x8080). It compiles and downloads but the debugger is not hitting the first breakpoint - possibly the chip is resetting before the break point is hit.

I am guessing that I am missing a setting in the debug configuration, but I have not been able to make it work as of yet. Any tips? I am new to Kinetis so I was hoping to get a quicker answer than me reading through the manuals at this point...

This is on the TWR-K64F120M in MCUXpresso 10.1, PE Micro Multilink Universal FX debugger.

[mark]

Stephen

I don't have much experience with MCUXpress at the moment - I prefer KDS since it is more mature - when I worked with MCUXpress 10.0.0_344 I found a number of things that made it rather awkward to work with so I am waiting for a more mature release where I hope some rather basic things are then fixed.

Usually debuggers shouldn't have any problem with working with uTaskerV1.4_BM.elf - for example quality IDEs like IAR just work as normal. I remember that CW10.x needed a reset command to be executed before it would stop at the entry point. You could try doing that to see whether it then starts behaving.

Another trick to use for basic IDEs that are inflexible (eg. they assume things that may not always hold true in general firmware projects) is to manually set a break point at the entry point of the application, reset and run to it and then it may start working normally.
A further trick is to read the first two long words at the start of the application (in this case 0x8080 and 0x8084). Command a reset then manually enter the first value in the SP register and the second value in the PC register., which corresponds to being at the entry point of the application. Now it may work normally.

If I remember correctly, the version of MCUXpress that I tested with only displayed the internal registers as decimal values unless configured individually to display as hex - this is something that early KDS versions did so it is like they are going through the same process of redeveloping something that was working quite well and doing the same mistakes again - no idea why a programmer wants to see internal registers displayed in decimal - perhaps they have hired an accountant to program for them ;-)

I also remember that I never managed to get a post build bat file to correctly execute in the environment (in CW.x and KDS - both similar Eclipse and with the same GCC compiler - it was no problem). I gave up (it is not a big issue) at the time since there were more important things to do.

A couple of days a go I did receive a message that there is a new version ready so I'll upgrade shortly and have a go too...

Regards

Mark

[Stephen]

Okay, thanks for your feedback. I'm new to ARM, as well as MCUXpresso, so a lot of unknowns at the moment.

I have the exact same debugger issue with a sample project I made with PFLASH code that doesn't start a 0x0 as well. Part of my thinking of getting uTasker was to look at all the settings, linker file, alignment of the interrupt vectors, etc. to see how the bootloader and application co-exist nicely on a K series chip.    My goal is to get a bootloader system in place...

Yes, I ran into the generate.bat issue. The _BM project was creating an elf without the _BM, but the generate.bat was attempting to relocate it as if it did have the _BM.

Both uTaskerV1.4_FLASH and uTakserV1.4_BM_FLASH configurations were using  ${ProjName} for the Artifact name (Project Settings > C/C++ Build > Settings > Build Artifact > Artifact). So both created uTakserV1.4.elf, but the generate.bat for the _BM was looking for uTaskerV1.4_BM.elf. One way to fix this is the change the _BM Artifact name to ${ProjName}_BM .

Additionally, the rem lines in the bat file were not recognized as comments? I don't know why. I just deleted them so I wouldn't get any errors.

[Stephen]

FYI, I have exactly the same situation in Kinetis Design Studio 3.2, on a FRDM-K64F using the embedded OpenSDA USB debugger.

I don't think this has anything particular to uTasker. Even if I create a bare project with a different FLASH origin I get this issue. Makes me think I am missing something that should be obvious...

[Stephen]

Looks like the IDE uses the real offset of flash for the PC, but does not set up the SP correctly. The SP gets loaded with all 1's, probably because that is the data at 0x0.

The fix is in the Startup tab of the Debugger Options. Uncheck the "Run on reset", and then put in a few custom GDB commands:

set $sp=*((long *)0x8080)
set $msp=*((long *)0x8080)
set $pc=*((long *)0x8084)
continue

If you check Run on Reset, the custom GDB commands don't work correctly. The 'continue' command reproduces the same behavior so it runs until reaching main()

[mark]

Stephen

One of the workarounds that I use is to manually set the SP.

This tells me however that you have loaded the offset application but don't have a boot loader in place. If you load the debugger first and then the application (assuming the IDE doesn't delete it, or you load the application with the debugger) you may then find that it works - it will run the boot loader and immediately jump to the application, where the jump sets the SP correctly.

Often I load the application with the boot loader (eg. USB-MSD is faster than the debugger) and do a debugger "connect" rather than loading code, which avoid the debugger possibly deleting the loader in the process.

Regards

Mark

[Stephen]

Yeah - if I had the bootloader in place and did not overwrite it, this would not have occurred. I thought I had tried that, but apparently not...

However, the IDE is inconsistent. It knows to not use the default PC location, but does use the default SP location.

So, this means if I place (and don't overwrite) any application at 0 that has the same start of stack that the 0x8000 code does, everything debugs fine. The IDE jumps straight to the 0x8000 code, but pulls the SP from 0x4 instead of 0x8004.

Anyway, thanks!