K81 ROM bootloader execute command doesn't work

[GET]

Hi community,

We've created a simple application which should be run from RAM using ROM bootloader execute command. Application sets own stack pointer in the very beginning. We can load application to RAM using bootloader write command. Also we are able to start application from debugger by setting PC and SP manually. However bootloader execute command (0x09) doesn't work. I've checked jump and stack address values, byte order (LSB first) etc. I get ack and generic response with correct status, but nothing happens after that. Application has been compiled for thumb mode. I've added breakpoints in the debugger for both odd and even addresses, but nothing happens after generic response. Also bootloader doesn't respond to i2c messages until reset.
Similar application works properly on KL17 microcontroller and exec command works just fine to start application on KL17. SP set in the application, so for KL17 it is enough to send execute command with jump address only.
If I start K81 application from RAM with PC and SP set, it works just fine. If I set PC to proper value and SP to 0, it doesn't start. And it doesn't work at all if exec command called.

Is there any special about execute command on K81?
Any ideas?

[jingpan]

Hi GET,

Have you set the interrupt vector table? (SCB->VTOR)

Regards,

Jing

[GET]

Yes. I use standard code from MCU Xpresso and it works just fine for KL17. Also it works fine if I set SP and PC in debugger:

void ResetISR(void) {

// Disable interrupts
__asm volatile ("cpsid i");

__set_MSP((uint32_t)g_pfnVectors[0]);
SCB->VTOR = const_get_vector_table();

SystemInit();
[...]


I flash image to 0x20000900. And reset ISR can be found at offset 1f8.
Here is the memory map:

.after_vectors.reset
0x0000000020000af8 0x64 objs-k81/startup/startup.o
0x0000000020000af8 ResetISR

So if I jump to thumb address 0x200000af9 from debugger, I can start my application. But not if I call exec in ROM bootloader.
Obviously vector table should be set to make ResetISR to work.
Also I've checked I have proper SP address in the vector table.

[jingpan]

Hi GET,

I made a simple demo to illustrate the work flow.

1. I use led_blink as example, which you can find in SDK. I change it to run in RAM  and set VTOR register in start of main(). Compile the project and generate bin file.

2. Connect to bootloader by:

       blhost -p COM10 -- get-property 10

3. Download the bin file:

       blhost -p COM10 -- write-memory 0x20000900 twrk81f150m_led_blinky.bin

4. Run:

       blhost -p COM10 -- execute 0x20000b0d 0 0x2002fff0

Regards,

Jing

[GET]

Hi Jing,

Thank you. This doesn't seem to work for me as well.
- blhost works just perfectly (I use i2c). I can ping the device, write memory etc.
- blhost execute doesn't show any errors.
- I have only final device now and it has no led. I found that in my binary ResetISR has address 0x20000b21. I set Ozone debugger breakpoint there, but no stop happens on blhost execute call.
- I modified example so I write a magic value to the RAM address 0x2000000. But I can't see that magic value in the debugger after blhost execute call.
- blhost refused to work after blhost execute, so execution really jumps somewhere.
- If I pause execution in debugger, it always stops at address 1C000792 which is definitely not a part of the led blinker:
1C000792 B 0x1C000792

[jingpan]

Hi,

0x1c000000 is the start address of ROM code. It seems it did not execute your code, or executed but reset. If it reset, you can see a signal on reset pin.

Can you use blhost to download code to flash and run?

Regards,

Jing

[GET]

Yes, blhost seems to work as expected.
I asked my colleague to build your project in his environment and to give me a ready binary. The ResetISR address in his environment is 0x20000b0d, but outcome after execute is exactly same. Code runs in the loop:
1C000792 B 0x1C000792

This seems to be some final loop.
I've enabled breakpoint on core reset, but debugger doesn't stop there.
Also I've enabled stop on every fault/exception, but nothing happens.
If I reset to bootloader with NMI pin, debugger happily stops at "CPSID i" instruction at address 0x1C0001EC:
>1C0001EC CPSID i
1C0001EE LDR R0, [PC, #0x38] ; [0x1C000228]
1C0001F0 LDR R1, [PC, #0x38] ; [0x1C00022C]
1C0001F2 STR R0, [R1, #8]
1C0001F4 MOVS R2, #0
1C0001F6 MOVS R3, #0
1C0001F8 MOVS R4, #0
1C0001FA MOVS R5, #0
1C0001FC MOVS R6, #0
1C0001FE MOVS R7, #0
1C000200 MOV R8, R7
1C000202 MOV R9, R7
1C000204 MOV R10, R7
1C000206 MOV R11, R7
1C000208 MOV R12, R7


So I believe debugger is working.

[jingpan]

Hi GET,

I tried I2C interface again. I use TWR-KV46 as the translator. And use the BusPal software in MCUBOOT2.0.0 package. It works fine.

.\blhost -p com33 --buspal i2c -- get-property 10

.\blhost -p com33 --buspal i2c -- write-memory 0x20000900 k81led.bin

.\blhost -p com33 --buspal i2c -- execute 0x20000b0d 0 0x2002fff0

Maybe the problem is caused by your translator?

Regards,

Jing

[GET]

Hi Jing,

Thank you very much. Outcome is same.

root@host# $BLHOST write-memory 0x20000900 k81led.bin
Ping responded in 1 attempt(s)
Inject command 'write-memory'
Preparing to send 9816 (0x2658) bytes to the target.
Successful generic response to command 'write-memory'
(1/1)100% Completed!
Successful generic response to command 'write-memory'
Response status = 0 (0x0) Success.
Wrote 9816 of 9816 bytes.
root@host# $BLHOST execute 0x20000b0d 0 0x2002fff0
Ping responded in 1 attempt(s)
Inject command 'execute'
Successful generic response to command 'execute'
Response status = 0 (0x0) Success.
root@host#

I put breakpoint to 0x20000b0d, but nothing happened.
When I stopped MCU, it was executing an infiite cycle somewhere in bootloader:

 1C000792   B              0x1C000792

Obviously, K81 doesn't respond to blhost after execution until reset.
blhost get-property 7 lists "execute" along other supported commands.

I'm wondering if some pin combination can prevent from executing?

I have to say also that outcome is same with empty internal flash.

[jingpan]

Hi,

Before download program to RAM, have you clean the Flash, especially the 0x400~0x410?

I don't see any pin combination can prevent from executing. Maybe you can try download from USB or UART? They needn't a translator.

Regards,

Jing

[GET · Accepted solution]

Finally it works with naked attribute added to ResetISR. Stack pointer has been set to 0 at exec call, but SP set to a proper value in the ResetISR instead.