Tranferring execution from custom bootloader to system code - LPC1853

[lpcware]

Content originally posted in LPCWare by dodge55 on Sat Mar 21 08:53:19 MST 2015
I have an older project using a LPC2148 that has a custom bootloader and if certain criteria are met, transfers execution to the system code located at a different location.  However, the same syntax isn't working for the LPC1853. 

The bootloader is placed at 1A000000.  The system code is placed at 1A006010.  The bootloader code runs fine until the system code transfer call is executed.

In debug (using Keil), I placed a breakpoint on the transfer call.  The assembly statement is BLX r4.  'r4' holds 0x1A006010, as I would expect.  When the statement is executed, I get a HardFault.

Here are the items of interest for the call.

#define SYSTEMBEGIN  (volatile unsigned char *) 0x1A006010
typedef void (*SYSTEM_APP)(void);

SYSTEM_APP system_app = (SYSTEM_APP)SYSTEMBEGIN;

system_app();

This syntax works perfect for the LPC2148, but not for the LPC1853, unless I'm missing something else.

Any help.

Thanks,

Sutton

[lpcware]

Content originally posted in LPCWare by dodge55 on Sat Mar 21 10:35:17 MST 2015
Thanks.  Let me do some reading up on those links and see if I can figure out the problem.

[lpcware]

Content originally posted in LPCWare by R2D2 on Sat Mar 21 10:18:39 MST 2015

---

Quote: dodge55
Nor have I found any example code that shows how to transfer execution for the Cortex M3/M4 in this manner.

---

http://www.lpcware.com/content/forum/help-needed-lpc1850-bootloader-fails-jump-application-around-50...

Vector table address description:

http://www.lpcware.com/content/forum/jump-bootloader-actual-firmware

[lpcware]

Content originally posted in LPCWare by dodge55 on Sat Mar 21 10:13:11 MST 2015
0x1A006010 is real code.  If I program the user code to 0x1A000000, it works fine.  The code looks correct, in that whether it is located at 0x00000000 or 0x1A006010, the bytes look correct.  The PC looks good.  It has the correct value before the transfer call (0x1A002B83).  Upon execution of transfer call, the value becomes 0x1A00031E (HardFault Handler).  The SP is 0x10003780, which appears to be OK.  I read that you have to dereference the transfer call, unlike the ARM7, so I'm trying to see if that will work.

Sutton

[lpcware]

Content originally posted in LPCWare by capiman on Sat Mar 21 09:38:46 MST 2015
What is there at 0x1a006010? Is there the vector table or already real code?
What about stack pointer (SP)? What about program counter (PC)?

[lpcware]

Content originally posted in LPCWare by dodge55 on Sat Mar 21 09:31:47 MST 2015
Good idea, but still same result. 0x1A006011 also invokes the HardFault Handler.  'r4' now holds 0x1A006011, as expected.

I also have to Cortex M3/M4 book by Yiu.  I haven't found anything in there as of yet that shows any differences in this particular execution transfer.  Nor have I found any example code that shows how to transfer execution for the Cortex M3/M4 in this manner.

[lpcware]

Content originally posted in LPCWare by wmues on Sat Mar 21 09:13:39 MST 2015
try 0x1A006011.

Bit 0 should be 1. It's a marker of the THUMB execution codeset.

regards
Wolfgang

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Sat Mar 21 09:07:11 MST 2015
Cortex-m3 startup is different to arm7 startup, so it won't work the same way. Get yourself a good book on cortex-m3 or find an m3 boot loader example.