Hi,
I'm trying to get an kboot exampe working on my twr-k65f180 board and facing the following problem:
The Bootloader reads its configuration from an address space belonging to the application (0x3C0). This area is called Bootloader Configuration Area (BCA).
The proposed offset is not large enough to leave enough to fill all the ISR vectors on a Cortex-M controller defined in the startup file. The NXP default linker scripts propose 0x400 bytes for the vector table.
what is the proposed doing here?
Hi Peter,
First of all,The pre-program Flashloader doesn't read the BCA, and you need to modify the linker files when you use the tower_bootloader example.
According to the example, it define the 0xa000 as the start address of the application code.
// The bootloader will check this address for the application vector table upon startup.
#if !defined(BL_APP_VECTOR_TABLE_ADDRESS)
#define BL_APP_VECTOR_TABLE_ADDRESS 0xa000
#endif
Hope it helps,
Have a great day,
Ping
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Ping,
did you read this part of my post:
The proposed offset is not large enough to leave enough to fill all the ISR vectors on a Cortex-M controller defined in thestartup file. The NXP default linker scripts propose 0x400 bytes for the vector table.
this has nothing to do with the application offset!
the problem is, that the BCA (0x3c0) is placed inside the vector table (occupies space until 0x400). this is not a problem if you:
sorry to have confused you, but I am not talking about a flash loader. if at all, then about a flash resident bootloader (kboot) for which the BCA structure is relevant.
so my question remains: what is the proposed solution?
the application linker script looks like this:
/* Specify the memory areas */
MEMORY
{
m_interrupts (RX) : ORIGIN = 0x00020000, LENGTH = 0x000003C0
m_bootloader_config (RX) : ORIGIN = 0x000203C0, LENGTH = 0x00000040
m_flash_config (RX) : ORIGIN = 0x00020400, LENGTH = 0x00000010
m_text (RX) : ORIGIN = 0x00020410, LENGTH = 0x001FFBF0
m_data (RW) : ORIGIN = 0x1FFF0000, LENGTH = 0x00010000
m_data_2 (RW) : ORIGIN = 0x20000000, LENGTH = 0x00030000
}
Hi Peter,
I'd highly recommend you to choose the reduce the size of the vector table, as the set of DefaultISR are null.
Have a great day,
Ping
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hi Peter,
After the linker file modification, the vector table will reside in the 0xa000~0xa3ff region instead of the 0x0000~0x03ff, however the BCA resides in the 0x3c0~0x3ff.
Hope it helps.
Have a great day,
Ping
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
sorry, this helps not at all. or I don't understand you :smileysad:
the bca is part of the application binary. and as such it located relative to the application offset.
I think your understand is, that the BCA is located in the bootloader space... this would also be possible but not very helpful as the bca also contains checksums of the application binary. this is not part of my problem.
let me try to rephrase this again...
the specified location of the BCA structure is 0x3C0 (dec:960) bytes. All the default linker files (grab an ksdk of any device and grep -r "m_interrupts (RX)"), specify that the ISR table has a length of 0x400 (dec:1024) bytes. see the conflict? the BCA location conflicts with the default ISR vector length.
is it possible without any danger to make the memory section intended for the vector table smaller to have the BCA placed at offset 0x3C0?
Hi Peter,
Will try to help.
My assumption is you are using the NXP_Kinetis_Bootloader_2_0_0 code base. Correct?
If yes, then the bootloader BCA (Bootloader Configuration Area) is contained within the 0x0-0x400 reserved vector table area.
If you look in the following file:
C:\NXP\NXP_Kinetis_Bootloader_2_0_0\targets\MK65F18\src\startup\gcc\startup_MK65F18.S
You will see that after the vector table is defined, the BCA is optionally enabled (if "BL_HAS_BOOTLOADER_CONFIG" is defined in application code and/or in the project Properties) starting at address 0x3C0.
Memory Map wise:
0x0000_0000 - 0x0000_03BF <--This is the vector table range
0x0000_03C0 - 0x0000_03FF <--BCA range with padding at end
0x0000_0400 - 0x0000_040F <-- Flash Configuration Field
0x0000_0410 - 0xENDofFLASH <--Application Code
Now when a bootloader is used then the above memory map has an offset added to such as 0xA000.
One of the best ways to get more fluent with the bootloader on your tower, then use the example LED application.
C:\NXP\NXP_Kinetis_Bootloader_2_0_0\targets\MK65F18\kds\tower_bootloader
C:\NXP\NXP_Kinetis_Bootloader_2_0_0\apps\led_demo\MK65F18\kds\led_demo_tower_a000
Regards,
David
thanks David.
using this method you would not need to define discrete m_bootloader_config memory section in the linker file like I did.
I was adding a dedicated memory section to the linker file because the bootloader_config.c generated by the KinetisFlashTools.
This file contains instructions to add a dedicated region to the flash address space. This lead to confusion on my side because the inital vector table length was 0x400.
to make a long story short: it seems okay to shorten / place the BCA struct into the vector table.