Hello,
I would like to configure the embedded application codes to have different starting address for text and interrupt vectors. For debug mode, i would like to set the vector address start out at 0x0 so i can generate the codes and download directly to the board for interactive debug mode, but for release mode, i would like to set the vector address to start out at e.g. 0x40000. Setting this information is done in CPU Build Options tab in KDS.
The reason is that in release mode, we have a boot loader starts out at 0x0 and then load the application codes to address 0x40000 and then jumps there once the CRC check is good.
In Keil uVision, we can set different starting point for interrupt vectors / codes depending on configuration. i can not find it in KDS 3.0.
can you please advise on how to go about this?
Thanks,
Henry
Hi Erich,
i think the above link which update the additional line m_cfmprotrom (RX) on .ld file actually fixed all the issue i have.
i used the above function (got it from Mark Butcher's thread) start_application(0x40000); works fine. Now, i can download application codes through boot loader and executes without any issue.
Thank you so much for all your help.
Henry
Hi Erich,
Attachment is my project which include the default .ld.
i think i figure out why it append 0x00 after i read the content on this link:
Configuring the Vector Table offset when using ... | element14 | Freedom development platform
i change the .ld by changing the m_cfmprotrom line from
MEMORY {
m_interrupts (RX) : ORIGIN = 0x00040000, LENGTH = 0x000001E8
m_text (RX) : ORIGIN = 0x00040410, LENGTH = 0x0003FBF0
m_data (RW) : ORIGIN = 0x1FFF0000, LENGTH = 0x00010000
m_data_20000000 (RW) : ORIGIN = 0x20000000, LENGTH = 0x00010000
m_cfmprotrom (RX) : ORIGIN = 0x00000400, LENGTH = 0x00000010
}
to:
MEMORY {
m_interrupts (RX) : ORIGIN = 0x00040000, LENGTH = 0x000001E8
m_text (RX) : ORIGIN = 0x00040410, LENGTH = 0x0003FBF0
m_data (RW) : ORIGIN = 0x1FFF0000, LENGTH = 0x00010000
m_data_20000000 (RW) : ORIGIN = 0x20000000, LENGTH = 0x00010000
m_cfmprotrom (RX) : ORIGIN = 0x00040400, LENGTH = 0x00000010
}
with this change, i am able to see the binary without padding.
i load this binary to the flash by the boot loader, but then, it seems to brick my board now :smileysad:
I used segger IDE to erase all content, and such, but still not able to download code to it yet.
Henry
Hi Erich,
just an update, after i try to erase / program the proper .elf file using Segger IDE, the board seems to be working again now... Pheeee. i am still not able to know if the attached application project that i intend to be loaded by boot loader to 0x40000 is properly compiled or not. i check the CRC starting from 0x40000 until the length of the bin, the 32-bit CRC matches.
i used this to jump to 0x40000
void start_application(unsigned long app_link_location)
{
__asm(" ldr sp, [r0,#0]");
__asm(" ldr pc, [r0,#4]");
}
... then later in the main file, after checking CRC matches, i proceed to jump to 0x40000 as:
if(Firmware_CheckIntegrity())
{
TRACE_INFO("Run tool firmware...\r\n\r\n");
start_application(0x40000);
...
}
do you see any potential issue in my tested application codes (compiled for 0x40000) and the way to jump to 0x40000 after CRC check is correct?
Thanks,
Henry
Hi Henry,
in Eclipse, you can use build configurations for this (see Build Configurations in Eclipse | MCU on Eclipse). Each build configuration can have different options and linker files. So you can have a #define (see -D option in the compiler settings) which you can check in your code if you want to do things differently. And assign differnt linker .ld files (as Alice pointed out) for each configuration.
I hope this helps,
Erich
Hi Erich, Alice,
thank you for your reply. So, user has to set the correct .ld file for each configuration. I was hoping that the CPU component in PEx linker file in build-options can be changed for each configuration, but it seems that it is not. No problem i can have custom .ld for each configuration and called them appropriately.
About the case that i defined the application starting address at 0x40000, i use generated raw binary file option in the property setting and it generated the binary, but it appended 0x0 all the way to 0x3FC00. Please see the 3 attached files.
I wonder if there is anyway we can skip the appending of 0x0 because when i load this .bin by the boot loader, the value at physical address 0x40000 is not the beginning of the application codes. when we use Keil uVision to convert the .axf to .bin, there is no appending of 0x0.
- top of the application .bin file, it has 0xFF and then bunch of 0x00
it fills 0x00 until 0x3FC00 where it seems to have the vectors for application codes.
I am not sure why the vectors are mapped to 0x3FC00 like this. if you see my linker configuration setup below, it should start at 0x40000.
Linker setting for this binary file.
can you please advise if i am doing anything wrong? what i like to do is to have the binary codes to be loaded at 0x40000 by boot loader and start from there. I can get the boot loader to save the .bin there correctly because i have done the CRC-32 bit check. but the image starting at 0x40000 is exactly what i have shown in the binary above.
Thanks,
Henry
Hi Henry,
can you share/post your actual linker file here?
Erich
Hi Henry,
you can have different linker files or CPU settings, this is called 'Processor Expert configurations', see Configurations with Processor Expert | MCU on Eclipse . Only keep in mind that this is independent of the Eclipse CDT configurations, and it is about a 'Component included or not' way of doing things. So if you have two different CPU settings, have two CPU components in your project, one enabled for each configuration.
I hope this helps,
Erich
Hello,
Please open linker file (.ld), then configure the MEMORY part , for example like this :
Hope it helps
Have a great day,
TIC
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------