LPC Microcontrollers中的主题 Re: Jump from bootloader to actual firmware

Jump from bootloader to actual firmware

lpcware — Wed, 15 Jun 2016 17:12:14 GMT

Content originally posted in LPCWare by DennisFrie on Wed Sep 24 15:37:41 MST 2014
Hi guys
I'm using a secondary bootloader on my LPC1549, but keep getting a hardfault error, when calling the main firmware.

The bootloader is placed in flash address 0x00 and the main firmware is loaded to 0x2000.

Atm. I'm testing with a very basic sketch, where the "bootloader" just calls the main-firmware.

This is what I'm doing atm:

// Start by disabling interrupts, before changing interrupt vectors
__disable_irq();

// Set vector table offset
SCB->VTOR = 0x2000; // Note, can be anded with max allowed address, 0x3FFFFF80

// Create pointer to new program address
void (*code_ptr)(void) = (void (*)(void))0x2000;

// Call firmware at address 0x2000 (from pointer above)
code_ptr();

Looking at application note AN10866 for LPC17xx, the program counter and stack pointer is changed, but I'm not sure if the vector table offset is enough on LPC15xx.
Trying to change the stack using the code below, my LPC dev. board crashses completely

asm volatile("ldr r0, =0x2000"); // Point to top stack
asm volatile("ldr r0, [r0]");
asm volatile("mov sp, r0");

asm volatile("ldr r0, =0x2004"); // Point to Reset handler
asm volatile("ldr r0, [r0]");
asm volatile("mov pc, r0");

I've tried
__set_MSP(*(__IO uint32_t*)0x2000); and call 0x2004 instead, but same result

Any good hints as to what I'm missing here?

When compiling the primary firmware, the compiler is set to use start from address 0x2000.

Without the updated vector table, I keep getting a hardfault-error (0x13C). With the updated vector table it ends at 0x213C (same hardfault vector, just with the offset).

Re: Jump from bootloader to actual firmware

lpcware — Wed, 15 Jun 2016 17:12:15 GMT

Content originally posted in LPCWare by LabRat on Wed Sep 24 15:51:08 MST 2014
Obviously you don't know what's in that vector table :)

[u]M3 Vector table:[/u]
0x0000 Initial SP value
0x0004 Reset
0x0008 Hard fault
0x000C NMI
0x0010 Memory management fault
0x0014 Usage fault
0x0018 Bus fault
0x001C Checksum of word 0-6
0x0020 Reserved
0x0024 Reserved
0x0028 Reserved
0x002C SVCall
0x0030 PendSV
0x0034 Reserved for Debug
0x0038 Reserved
0x003C Systick
0x0040 IRQ0
0x0044 IRQ1
...
...

You problem is that you don't load the new stack pointer and then you don't jump to Reset :)

Your code is trying to jump to stack pointer...

Re: Jump from bootloader to actual firmware

lpcware — Wed, 15 Jun 2016 17:12:16 GMT

Content originally posted in LPCWare by DennisFrie on Wed Sep 24 16:26:27 MST 2014
Well I've tried pretty much everything in that regard, but get the same fault.

Setting main stack pointer to 0x2000:
__set_MSP(*(__IO uint32_t*)0x2000);

-and calling what I would expect to be reset:
void (*code_ptr)(void) = (void (*)(void))(startAddress+4);
code_ptr();

gives the same result.

Thanks for the quick answer.

Re: Jump from bootloader to actual firmware

lpcware — Wed, 15 Jun 2016 17:12:16 GMT

Content originally posted in LPCWare by LabRat on Wed Sep 24 16:33:58 MST 2014
Then check the vector table of application code...

Is it a working program? Does it include correct checksum?

Use 'Instruction Stepping Mode' to debug your bootloader...

Re: Jump from bootloader to actual firmware

lpcware — Wed, 15 Jun 2016 17:12:18 GMT

Content originally posted in LPCWare by starblue on Thu Sep 25 01:51:52 MST 2014
http://www.lpcware.com/content/forum/hardfault-when-lpc1788-bootloader-jumps-user-application

Re: Jump from bootloader to actual firmware

lpcware — Wed, 15 Jun 2016 17:12:19 GMT

Content originally posted in LPCWare by DennisFrie on Thu Sep 25 03:05:32 MST 2014

Quote: LabRat
Then check the vector table of application code...

Is it a working program? Does it include correct checksum?

Use 'Instruction Stepping Mode' to debug your bootloader...

I've really been trying to keep it as simple as possible.

To begin with, I've used the blinky example in LPCopen for LPC15xx. The memory is changed like seen below and simply compiled to a bin-file:
[img]https://dl.dropboxusercontent.com/u/3947315/CompilerChangedAddress.png[/img]

The bin-file is uploaded to 0x2000 using the program flash utility
[img]https://dl.dropboxusercontent.com/u/3947315/UploadTo0x2000.png[/img]

Another sketch is created, which only function at the moment is to call the program at 0x2000.

// Start by disabling interrupts, before changing interrupt vectors
__disable_irq();

// Set vector table offset
SCB->VTOR = 0x2000; // Note, can be anded with max allowed address, 0x3FFFFF80

// Create pointer to reset handler at new program address
void (*code_ptr)(void) = (void (*)(void))0x2004;

__set_MSP(*(__IO uint32_t*)0x2000); // Set top stack handler

code_ptr();

I was sitting with a friend for hours yesterday trying to get it figured out. We have tried pretty much everything, but I'm sure we're just missing or misunderstanding something fairly obvious

Re: Jump from bootloader to actual firmware

lpcware — Wed, 15 Jun 2016 17:12:20 GMT

Content originally posted in LPCWare by DennisFrie on Thu Sep 25 03:06:17 MST 2014

Quote: starblue
http://www.lpcware.com/content/forum/hardfault-when-lpc1788-bootloader-jumps-user-application

Thanks, we have been reading tons of LPC17xx examples and threads but haven't found the answer to our problem.

Re: Jump from bootloader to actual firmware

lpcware — Wed, 15 Jun 2016 17:12:20 GMT

Content originally posted in LPCWare by LabRat on Thu Sep 25 03:25:40 MST 2014
There's a typo in your Flash setup: 0x40000 - 0x2000 is not 0x38000 :bigsmile:

Is there a correct checksum in your application image?

Use Peripheral View->MFlash256 to check sector 2 (and post it...)...

Did you debug your code? Is it loading correct stack pointer and Reset address before it jumps?

Wild guess: your jump address is wrong :)

Re: Jump from bootloader to actual firmware

lpcware — Wed, 15 Jun 2016 17:12:21 GMT

Content originally posted in LPCWare by LabRat on Thu Sep 25 03:36:41 MST 2014
You are jumping to 0x2004 instead of address in 0x2004 :((

Use:

void (*code_ptr)(void) = (void (*)(void))(*(uint32_t*)0x2004);

and [color=#f00]debug[/color] it !!!!

Re: Jump from bootloader to actual firmware

lpcware — Wed, 15 Jun 2016 17:12:22 GMT

Content originally posted in LPCWare by DennisFrie on Thu Sep 25 06:50:02 MST 2014

Quote: LabRat
There's a typo in your Flash setup: 0x40000 - 0x2000 is not 0x38000 :bigsmile:

Wups 0:)

Quote: LabRat

Is there a correct checksum in your application image?

Use Peripheral View->MFlash256 to check sector 2 (and post it...)...

Did you debug your code? Is it loading correct stack pointer and Reset address before it jumps?

Wild guess: your jump address is wrong

Quote: LabRat
You are jumping to 0x2004 instead of address in 0x2004 :((

Use:

void (*code_ptr)(void) = (void (*)(void))(*(uint32_t*)0x2004);

and [color=#f00]debug[/color] it !!!!

Hmm, jumping to 0x2004 should get the new address from that register? When debugging the vector points to the address 0x2004, I got the impression it should jump to 0x2004 and use the address from that.

Uploading the blinky sketch to 0x2000 and the jumper-code/bootloader to 0x00, this is the initial memory in the flash
[img]https://dl.dropboxusercontent.com/u/3947315/bootloaderDebug/FirstMemory.png[/img]

The flash at 0x2000 should be updated correct too
[img]https://dl.dropboxusercontent.com/u/3947315/bootloaderDebug/SecondMemory.png[/img]

Debugging the initial code. Initially
[img]https://dl.dropboxusercontent.com/u/3947315/bootloaderDebug/StartUpState.png[/img]

Before the jump
[img]https://dl.dropboxusercontent.com/u/3947315/bootloaderDebug/RegisterBeforeCall.png[/img]

Fatal error when running that part.
[img]https://dl.dropboxusercontent.com/u/3947315/bootloaderDebug/steppingInto.png[/img]

I gotta admit, currently I'm not quite sure what I'm looking for.

Your help is much appreciated, thanks.

Re: Jump from bootloader to actual firmware

lpcware — Wed, 15 Jun 2016 17:12:22 GMT

Content originally posted in LPCWare by starblue on Thu Sep 25 07:02:50 MST 2014

Quote: LabRat

void (*code_ptr)(void) = (void (*)(void))(*(uint32_t*)0x2004);

Oh the horrors of C function type notation, better use a typedef. You should also be able to get rid of the redundant cast (untested):

typedef void (*f_ptr_t)(void);
f_ptr_t code_ptr = *(*f_ptr_t) 0x2004;

Without the typedef that would be written like this, I think:

void (*code_ptr)(void) = *(void (**)(void)) 0x2004;

Re: Jump from bootloader to actual firmware

lpcware — Wed, 15 Jun 2016 17:12:23 GMT

Content originally posted in LPCWare by starblue on Thu Sep 25 07:06:19 MST 2014

Quote: DennisFrie

Quote: starblue
http://www.lpcware.com/content/forum/hardfault-when-lpc1788-bootloader-jumps-user-application

Thanks, we have been reading tons of LPC17xx examples and threads but haven't found the answer to our problem.

Apparently you haven't read it carefully enough, then.

Specifically, you shouldn't jump to 0x2004, but to the address that is stored in 0x2004, which is explicitly discussed in the thread (the original poster also got it wrong at first, it seems to be somewhat hard to grasp.)

Re: Jump from bootloader to actual firmware

lpcware — Wed, 15 Jun 2016 17:12:24 GMT

Content originally posted in LPCWare by LabRat on Thu Sep 25 07:11:20 MST 2014

Quote: DennisFrie
I gotta admit, currently I'm not quite sure what I'm looking for.

[color=#f00]blx r2  [/color]

If your bootloader code is correct, Reset address of application (addresss in 0x2004) is now in r2.

0x2191 is the correct address and blx should jump to 0x2190 (LSB is thumb indicator).

Now it's important to use 'Instruction Stepping' (I-> Icon in Debug View) to see if this jump is executed...

See: http://www.lpcware.com/content/faq/lpcxpresso/disassembly-view

Re: Jump from bootloader to actual firmware

lpcware — Wed, 15 Jun 2016 17:12:24 GMT

Content originally posted in LPCWare by LabRat on Thu Sep 25 07:18:53 MST 2014

Quote: starblue

Quote: LabRat

void (*code_ptr)(void) = (void (*)(void))(*(uint32_t*)0x2004);

Oh the horrors of C function type notation, better use a typedef. You should also be able to get rid of the redundant cast (untested):

typedef void (*f_ptr_t)(void);
f_ptr_t code_ptr = *(*f_ptr_t) 0x2004;

Without the typedef that would be written like this, I think:

void (*code_ptr)(void) = *(void (**)(void)) 0x2004;

Would prefer to use a simple pointer (tested):

 void (*user_code_entry)(void);
 uint32_t *p;
....
 p = (uint32_t *)(sector * 0x1000);
  __set_MSP(*p);
 p++;
 user_code_entry = (void (*)(void))(*p);
 user_code_entry();

Re: Jump from bootloader to actual firmware

lpcware — Wed, 15 Jun 2016 17:12:25 GMT

Content originally posted in LPCWare by DennisFrie on Thu Sep 25 07:55:29 MST 2014
Hmm interesting..
It seems to jump just fine to the next part of the code, but fail in the next code

Before stepping in:
[img]https://dl.dropboxusercontent.com/u/3947315/bootloaderDebug/1StepIn.png[/img]

Stepping just fine into 0x2190
[img]https://dl.dropboxusercontent.com/u/3947315/bootloaderDebug/2FirstStep2190.png[/img]

R2 is still pointing to 0x2191 here
[img]https://dl.dropboxusercontent.com/u/3947315/bootloaderDebug/3R2NotChanged.png[/img]

Continuing in the code, R2 is being set to 0x00
[img]https://dl.dropboxusercontent.com/u/3947315/bootloaderDebug/4R2Changed.png[/img]

Looks like an initialization problem in the second code?

Re: Jump from bootloader to actual firmware

lpcware — Wed, 15 Jun 2016 17:12:25 GMT

Content originally posted in LPCWare by DennisFrie on Thu Sep 25 08:03:59 MST 2014

Quote: starblue

Quote: DennisFrie

Quote: starblue
http://www.lpcware.com/content/forum/hardfault-when-lpc1788-bootloader-jumps-user-application

Thanks, we have been reading tons of LPC17xx examples and threads but haven't found the answer to our problem.

Being fairly new to the specific stack-pointers on M3, it's not always quite obvious - my apologies if we missed something obvious already written somewhere else.

Re: Jump from bootloader to actual firmware

lpcware — Wed, 15 Jun 2016 17:12:26 GMT

Content originally posted in LPCWare by LabRat on Thu Sep 25 08:19:38 MST 2014

Quote: DennisFrie
Looks like an initialization problem in the second code?

That's not looking wrong...

It's jumping to 0x2190 and executing ResetISR from your application, I guess...

If you 'Resume' now, what's not working?

Re: Jump from bootloader to actual firmware

lpcware — Wed, 15 Jun 2016 17:12:27 GMT

Content originally posted in LPCWare by DennisFrie on Thu Sep 25 08:36:23 MST 2014
If I continue, it ends up in these lines (marked on the right)
[img]https://dl.dropboxusercontent.com/u/3947315/bootloaderDebug/stockHere.png[/img]

Re: Jump from bootloader to actual firmware

lpcware — Wed, 15 Jun 2016 17:12:27 GMT

Content originally posted in LPCWare by LabRat on Thu Sep 25 08:41:43 MST 2014

Quote: DennisFrie
If I continue, it ends up in these lines (marked on the right)

Looks like part of ResetISR (which includes several loops...).

After jumping into application you can try to debug your application with debug informations...

See: http://www.lpcware.com/content/faq/lpcxpresso/debugging-running-system

Re: Jump from bootloader to actual firmware

lpcware — Wed, 15 Jun 2016 17:12:28 GMT

Content originally posted in LPCWare by DennisFrie on Thu Sep 25 11:13:09 MST 2014
The only change done in the blinky-example, is the flash-address.

Unfortunately, after running the code, my debugger can't connect to the LPC15xx at all, hence debugging the system while running doesn't work (but neat trick otherwise)
I've had to clear the flash using the primary USB bootloader every-time, as the programmer can't connect afterwards. No idea why.
[img]https://dl.dropboxusercontent.com/u/3947315/bootloaderDebug/debugConnectProblem.png[/img]

I started over with a completely clean workspace, but no luck.
I've uploaded the workspace here if anyone can take a look it will be a great help.
https://dl.dropboxusercontent.com/u/3947315/Bootload_Test.zip

There's a .bin file called Blinky_0x2000 and Blinky_0x0000 - one compiled for 0x0000 address and the other one for 0x2000