This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
I want to write a bootloader for Tiva c series(TM4C123GH6PM) evaluation board. I read a few documents by TI like the ARM assembly language tools user guide and TivaWare Bootloader user guide.
I have a few questions regarding the concept and the specifics and I hope someone would help me out with these.
Evaluation kit: EK-TM4C123GXL
CCS Version: 7.4.0.00015
1. How can I get to know the program flow from the point the PC gets the reset vector address till the execution of the main().
I want to know what all settings and processes happen before the main function executes.
I tried to add a breakpoint in the tm4c123gh6pm_startup_ccs.c file which has the _c_int00 function and this is the function called in the ResetISR.
But the control didnt stop at the breakpoint, it entered main directly.
2. From what I understand, the vector table of the Cortex-M4 microprocessor contains four required entries starting form address 0: the initial stack
pointer, the reset handler address, the NMI handler address, and the hard fault handler address. When the processor is reset, it jumps to the reset vector
address which will be the starting point for the boot loader. The bootloader then copies itself and the vector table to the SRAM and then executes from there.
Where can I find the code for this operation, so that I can implement this in my boot loader.
3. I created a test project in CCS where I changed the ResetISR function in the tm4c123gh6pm_startup_ccs.c file and made it to jump to my function(test function) instead of the _c_int00 function.
When I ran the program, the control entered main without going to the test function, why is this happening.
This is my ResetISR function
void
ResetISR(void)
{
__asm(" .global testFunc\n"
" b.w testFunc");
}
4. The TivaWare bootloader user guide says that the startup code for CCS will be in the file bl_startup_ccs.s, where can I find this file?
Please let me know if there are any mistakes in my understanding.
Thanks in advance.
Hello Naveen,
The documentation you read is a good basis to create a foundation for your knowledge, but I think you need to also spend time reviewing our code examples for the boot_loader. I am not even sure initially why you want to create your own from scratch when we have a lot of collateral for that in our TivaWare software package. Were you perhaps not aware of that?
The 'boot_loader' folder in TivaWare has the bl_startup_ccs.s file which is also where the code which handles question 2 from you is located. The folder also contains many boot loader files for running various boot loader applications. I would advise you not only review some of these code files, but also go into the [Install Path]\TivaWare_C_Series-2.1.4.178\examples\boards\dk-tm4c123g examples folder and review our boot loader examples for the DK kit which you can apply to the project for your LaunchPad. Re-using TivaWare collateral would be the best path for you to put together a boot loader for your device.
TivaWare download link in case you need it: http://www.ti.com/tool/SW-TM4C
Hey Ralph,
Thanks for helping me out with the files. I wanted to have a complete understanding of the booting process, so though I would write it from scratch. I am going through the examples, in the meantime I have another couple questions.
1. I believe that whenever any code is run on the board, the ROM boot loader is the first thing to execute, where can I find the ROM boot loader
source code? Is it the one in the boot loader folder that you mentioned? Also which is the first file to be executed when I run the code, I am
looking for the specific file name.
2. The linker command file has the following code
SECTIONS
{
.intvecs: > 0x00000000
.text : > FLASH
.const : > FLASH
.cinit : > FLASH
.pinit : > FLASH
.init_array : > FLASH
.vtable : > 0x20000000
.data : > SRAM
.bss : > SRAM
.sysmem : > SRAM
.stack : > SRAM
}
But when I check in the memory browser, the data at 0x20000000 is __stack and not .vtable, why is that?
3. In which files are .vtable and bss_run symbols defined?
I really appreciate any help.
Hello Naveen,
Naveen Bhimappa Kori said:1. I believe that whenever any code is run on the board, the ROM boot loader is the first thing to execute, where can I find the ROM boot loader source code? Is it the one in the boot loader folder that you mentioned? Also which is the first file to be executed when I run the code, I am looking for the specific file name.
The ROM Boot Loader is usually invoked when the device boots up with nothing programmed in Flash. I.E. a fresh, clean device OR something that has been Flash-erased. More details here on the exact condition: https://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/p/659316/2437757#2437757
We do not provide source code for the ROM boot loader.
Naveen Bhimappa Kori said:2. The linker command file has the following code
Which example? Don't know which file to even look at on my end.
Greetings - as you & I have (earlier today) conspired upon a successful, "post resolution" - may I ask that you grant the following - (some) consideration?
You clearly are "detail oriented" - and persistent - yet (neither) you nor (most others) ever present ANY reasons whatsoever - for the (apparent) "Appeal/Draw" of the "bootloader." And - many here have observed - that, "Just as Mermaids exude great appeal" - their "pursuit" comes at "high cost" and more often than not - such does not "end well" - for (most) sailors. (of which - I am one)
There IS a consequence - especially when one "so new" - immerses (very early) in the highly complex. Might this unjustified (pursuit) of bootloader - "divert" - from your, "Far more central," MCU Learning (and Mastery) tasks? And - if so - for what (credible) reason?
Many have succeeded - for years - never having deployed any, "bootloader."
"KISS" dictates that you build your knowledge base carefully, systematically - and measurably - always in (relatively) small & tightly restricted, "chunks." The bootloader cannot meet (any) of those guidelines - and I "very much doubt" - will best serve your "Learning Objectives." (Again - while "diverting" you from "More Necessary - Learning Tasks.)
Hey cb1_mobile,
The reason I am trying to learn boot loader is that I want to know what code is being executed from the point we power up the MCU up until
the application starts its tasks. As you mentioned, I understand this might be a highly complex task and people could even succeed without having to deploy this, but this doesn't deter me from learning about the boot loader, this is purely my desire to understand it.
As I started reading on boot loaders I realized how challenging this stuff is and that got me even more excited about it. I understand that for someone just venturing into the microcontrollers field this could take up tremendous time and unwavering persistence, but to know what is happening at the core that lies beneath the application program is equally rewarding and I think you would agree with me on this one. Moreover, this would give us a better idea of the underlying hardware which helps us to build more efficient programs.
I am very eager to learn and just need some help from you guys, I hope you would appreciate my willingness to learn. Could you guys please guide me on this one?
Thanks
May we review two of your key points - from your post (above) and see if the "Mermaid's Call" - comes with some cost? (are her "boots" not (somewhat) water-logged?)
Naveen Bhimappa Kori said:but to know what is happening at the core that lies beneath the application program is equally rewarding
Why (this and only this) Application Program, then? Is any bootloader - sufficently, "broad, expandable & fundamental" in scope - to justify your, "Tossing more systematic MCU Study - Aside?"
And - if the "bootloader" is so powerful - so valued - why is it NOT featured (prominently) w/in the MCU Manual? Your "search" will reveal, "sporadic, often only far-flung mention" (i.e. NOT EVEN one single page - devoted to the bootloader - HIGHLY TELLING!) - while the "Much MORE VITAL - M4F Core and Peripherals - consume over 1,000 pages - with "323 pages" alone - devoted to the MCU's System Control!
Naveen Bhimappa Kori said:this would give us a better idea of the underlying hardware
Not (even) remotely true - according to the MCU Manual - and its team of authors! What justification beyond (pardon) "likely misplaced curiosity" - can support this claim of, "better idea?" And - are you not - rather clearly - offering up - notably & ONLY - your, (Unvarnished Hope) "better idea" as justification - for your (claim) of "better idea?" Such defines, "circular thinking" - not believed compelling...
Is it not FAR more reasonable - that your, "Proper Study of MCU Fundamentals" (as highlighted w/in the MCU Manual) proves far preferable to your, "Chase of an illusion" - however attractive?
Note that I've made "No comment" as to the relative "Ease & Success" of "Client-Users" attempting to "tame" the bootloader. Your use of the "Forum Search Box" - atop this page - will reveal the "ease" (or more likely) "lack of same" - resulting from "so many" bootload attempts...
Are you not enabling the (unjustified) "Bootloader Intrigue" to "HOLD HOSTAGE" your (real/certifiable) "MCU Learning" process? That "choice" exerts a (very) high price - and risk - does it not? (and for what?)
Naveen Bhimappa Kori said:Could you please confirm if my understanding of the booting process is correct.
1. If we do use a flash based boot loader, the project would include the boot loader code and the application source code.
When setup correctly, yes, the boot loader would exist in a portion of Flash and your application source code should be mapped to not use that area of Flash to not corrupt the boot loader
Naveen Bhimappa Kori said:2. The boot loader and the application code would be placed in the flash intially.
Yes.
Naveen Bhimappa Kori said:3. The boot loader would then copy the vector table, boot loader code and the application code to SRAM and then pass the control to the application code.
Not quite. The boot loader does copy into SRAM, but not the application code. The boot loader just runs from SRAM so the Flash can be updated with new application code, but neither new nor old application code is copied into SRAM, only the boot loader. Once the boot loading process is finished, then the boot loader should set the PC to point to the beginning of the newly downloaded application so it may begin running.