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?
已解决! 转到解答。
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
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
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.