Important changes to forums

We’re making some changes to the Mbed forums. From 10th December 2019 all new discussions will take place on our new forum site. You can continue to reply to existing threads for the next two weeks. After that we will archive this forum so you can return to useful posts in the future.

Secondary bootloader problem with mbed compiler.

27 Jul 2011

Hi,

I had modify example secondary USB bootloader of LPC1700 series from NXP website to secondary serial bootloader. When I create a user application with CMSIS library and change the starting address at 0x3000. It's work well but I create with mbed library and change the starting address at 0x3000 (create using offline comlplier). It's can't work. How to create the user application with mbed library and change the starting address? Oh, I am sorry about my english language if you can't understand.

28 Jul 2011

I have my problem closed to the above question. I try with off line compiler uVision.

I used uVision from Keil with cmsis library. I wrote bootloader and point the start application address to 0x2000. After test with bootloader and update a new application. The new updated application work fine.

But when I used mbed library instead of using cmsis with bootloader and point to start application address to 0x2000. The new updated application is not work.

Q: 1. How I can change the start application address to 0x2000?

Q: 2. Is need to change at linker script ? since with cmsis lib it success but with mbed lib it fail?

11 Jun 2012

you can edit the scatter file so that offline mbed binary is compiled to 0x2000, but even then it does not start properly.. :( not sure why

03 Jan 2013

Could someone from mBed please comment on this.

Is there a solution to this problem with the mBed .bin not able load via a secondary USB bootloader (ala NXP's app note AN10866) ?

21 Mar 2013

bump. same issue. mbed people help!

21 Mar 2013

re bump.

13 May 2015

bump

05 Sep 2015

bump

05 Sep 2015

This should work for the LPC1768, but seems you have a K64F. The most likely cause of this, is the flash interrupt vector locations (and that they don't simply put bootloader in the end of the flash, which is possible with ARM MCUs, but this is less work for them, and more work for the user, so they prefer it I guess).

This is LPC1768 interrupt vector table relocation code: https://developer.mbed.org/users/mbed_official/code/mbed-src/file/034e698bc035/targets/cmsis/TARGET_NXP/TARGET_LPC176X/cmsis_nvic.c

This is for K64F: https://developer.mbed.org/users/mbed_official/code/mbed-src/file/034e698bc035/targets/cmsis/TARGET_Freescale/TARGET_MCU_K64F/cmsis_nvic.c

Difference is that LPC1768 does the first run check by looking if it is currently located in RAM or not. (This wasn't the case originally, it has been modified for this reason). The K64F only checks if it is equal to the normal location, and then moves it. But if the normal location is not where it is, it will never be moved and go horribly wrong.

So you need to modify that check in mbed-src: either you can do the same as LPC1768 does (with correct address for K64F), or alternatively you can simply check if it is not equal to the RAM address. If it then works properly you can submit pull request on mbed github.

You need to log in to post a reply