Determining the minimum value for BL_APP_VECTOR_TABLE_ADDRESS

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Determining the minimum value for BL_APP_VECTOR_TABLE_ADDRESS

Jump to solution
687 Views
robertpoor
Senior Contributor I

I've compiled and loaded the flash-resident bootloader for the FRDM-KL25Z.  Now I'm adapting my application code to be loaded via the bootloader.  Naturally, I have to relocate my application to sit just above the end of the flash-resident bootloader itself, which requires me to choose a value for BL_APP_VECTOR_TABLE_ADDRESS in bootloader_config.h.

My question: What's a reliable way to determine the minimum value for BL_APP_VECTOR_TABLE_ADDRESS?

My first thought was to look in the memory map for the bootloader itself, where I found this:

Memory Configuration

Name Origin Length Attributes
m_interrupts 0x0000000000000000 0x0000000000000100 xr
m_bootloader_config 0x00000000000003c0 0x0000000000000040 xr
m_flash_config 0x0000000000000400 0x0000000000000010 xr
m_text 0x0000000000000410 0x000000000001fbf0 xr
m_data 0x000000001ffff000 0x0000000000004000 rw

The m_text section ends at 0x1fbf0, which suggests that BL_APP_VECTOR_TABLE_ADDRESS should be just above that, i.e. at 0x20000.  But unless I'm mistaken, that's the end of flash memory in the KL25Z.

But when I run blhost and ask the bootloader for the reserved regions of memory, I get something much more reasonable:

$ blhost --port /dev/cu.usbmodem246,19200 -- get-property 12
Ping responded in 1 attempt(s)
Inject command 'get-property'
Response status = 0 (0x0) Success.
Response word 1 = 0 (0x0)
Response word 2 = 14335 (0x37ff)
Response word 3 = 536866816 (0x1ffff000)
Response word 4 = 536872447 (0x200005ff)
Reserved Regions = Flash: 0x0-0x37FF (14 KB), RAM: 0x1FFFF000-0x200005FF (5.500 KB)

From this, it appears that I could set  BL_APP_VECTOR_TABLE_ADDRESS to be 0x4000 (much better!).

So my question: is blhost ... -- get-property 12 the approved way to determine the best value for BL_APP_VECTOR_TABLE_ADDRESS?

0 Kudos
1 Solution
468 Views
jingpan
NXP TechSupport
NXP TechSupport

Hi Robert,

The full function of bootloader should less than 30k byte. If you only use UART to download user application, the size can shrink to around 14k or less. If you use IAR, you can see it from MAP file. If you use Keil or KDS, this message can be seen at the end of compile.

blhost --get-property 12       List of memory regions reserved by the bootloader. So... yes, it can determine the best value of BL_APP_VECTOR_TABLE_ADDRESS

Regards

Jing

View solution in original post

0 Kudos
2 Replies
469 Views
jingpan
NXP TechSupport
NXP TechSupport

Hi Robert,

The full function of bootloader should less than 30k byte. If you only use UART to download user application, the size can shrink to around 14k or less. If you use IAR, you can see it from MAP file. If you use Keil or KDS, this message can be seen at the end of compile.

blhost --get-property 12       List of memory regions reserved by the bootloader. So... yes, it can determine the best value of BL_APP_VECTOR_TABLE_ADDRESS

Regards

Jing

0 Kudos
468 Views
robertpoor
Senior Contributor I

Just as a side note, I've created a version of the Flash-Resident bootloader that uses the SDK 2.x library.  It works, but I had to go to extra lengths to prevent DbgConsole methods (e.g. PRINTF and PUTCHAR) from sneaking into the build, since these caused the bootloader .etext to exceed 0x8000 (compiled in debug mode).

But Jing is correct: blhost --get-property 12 is one way to find how much space the flash-resident bootloader occupies.  I believe that looking at __etext in the .map file also works.

0 Kudos