Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Stephen

Pages: [1]
1
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!

2
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()

3
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...

4
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.

5
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.

Pages: [1]