- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Tool/software: Code Composer Studio
Hello,
we are developing a custom boot loader to load application codes on CAN bus.
The boot loader concept is simple and we would like to keep this way so that the F2812 can be boot loaded the same as other boards using ARM processor.
Our boot loader firmware boots up and has 1 second to wait for commands from surface software for application firmware download initiation.
If there is not surface software command, then, it will check application code CRC and if the CRC passed, it will branch to that location and starts execution.
If boot loader detects surface command to transfer in application codes, then it will erase the appropriate sectors, then take each 256 byte chunk on CAN bus and flash it to the application code sectors until completion.
we have the boot loader codes working fine where it can transfer sectors of data and check the CRC to make sure the transfer sector is correctly received and programmed.
The problem we have is in the definition and generation of application binary codes from CCS (we are using CCS v6.1).
The boot loader firmware and application firmware are two separate projects and each of them runs ok on their own direct download using their individual .out file and XDS100v3.
I have been reading the following threads on boot loader and totally confused on what F2812 can do.
However, none of them address my confusion and gives me a clear answer on definition and generation of application bin file.
so, i start my question in the logical way.
here is my .cmd file that partition both boot loader and application sectors:
PAGE 0: FLASHJ : origin = 0x3D8000, len = 0x002000, fill =0xFFFF /* on-chip FLASH */ // do not use this
PAGE 0: FLASHI : origin = 0x3DA000, len = 0x002000 /* on-chip FLASH */ // do not use this as this is reserved for coefficience
PAGE 0: FLASHH : origin = 0x3DC000, len = 0x004000 /* on-chip FLASH */ // do not use this as this is reserved for coefficience
PAGE 0: FLASH_BL : origin = 0x3E0000, len = 0x004000 , fill =0xFFFF /*Space to hold downloaded Firmware in FLASH G*/
//PAGE 0: FLASHF : origin = 0x3E4000, len = 0x004000, fill =0xFFFF /* on-chip FLASH F */
//PAGE 0: FLASHE : origin = 0x3E8000, len = 0x004000, fill =0xFFFF /* on-chip FLASH E */
// combine flash F and E to 32K
// used for application codes
PAGE 0: FLASH_CODE : origin = 0x3E4000, len = 0x008000, fill =0xFFFF /* on-chip FLASH */
//PAGE 0: FLASHFE : origin = 0x3E4000, len = 0x008000/*, fill =0xFFFF on-chip FLASH */
PAGE 0: FLASH_API : origin = 0x3EC000, len = 0x004000, fill =0xFFFF /* Space for FLASH API library (resident) in FLASHD */
PAGE 0: FLASH_RTS : origin = 0x3F0000, len = 0x004000, fill =0xFFFF /* Space for FLASH rts2800_ml library in FLASHC */
PAGE 0: FLASHB : origin = 0x3F4000, len = 0x002000, fill =0xFFFF /* on-chip FLASH B*/
PAGE 0: FLASH_BOOT : origin = 0x3F6000, len = 0x001F80, fill =0xFFFF /* Resident Code in FLASHA */
PAGE 0: CSM_RSVD : origin = 0x3F7F80, len = 0x000076 /* Part of FLASHA. Program with all 0x0000 when CSM is in use. */
PAGE 0: BEGIN_APP : origin = 0x3f7ff6, len = 0x2 /* FLASH ENTRY ADDRESS (conditional Branch)*/
PAGE 0: PASSWORDS : origin = 0x3f7ff8, len = 0x8
PAGE 0: ROM : origin = 0x3FF000, len = 0x000FC0 /* Boot ROM available if MP/MCn=0 */
PAGE 0: RESET : origin = 0x3FFFC0, len = 0x000002 /* part of boot ROM (MP/MCn=0) or XINTF zone 7 (MP/MCn=1) */
PAGE 0: VECTORS : origin = 0x3FFFC2, len = 0x00003E /* part of boot ROM (MP/MCn=0) or XINTF zone 7 (MP/MCn=1) */
PAGE 0: RAM_FOR_CODE : origin = 0x8000, len = 0x2000 /* RUN location of the Flash Init */
When running either boot loader firmware or application firmware by itself, the code start address is always 0x3f7ff6 which has the branch instruction to _c_int00 which is in the c28x boot up assembly ( i can view).
1- Do both boot loader and application firmware have the same code start address like: 0x3f7ff6 and share the same _c_int00 routine? if they share the same _c_int00 routine, how does it know which _main() to call at the end of the routine.
2- in our case, we would like the application including code start address, to start from 0x3E4000. If we change our application Code Start Address to 0x3E4000, it seems that it does have the proper starting instruction there.
3- we used C2000 Hex Utility in CCS to generate .bin file. We noticed that the bin file follow a certain convention that is used with CKFA codes from TI. The first two bytes of the application binary stream is 0xAA and 0x08, etc. How can we generate the real application code binary stream that has all proper codes at the starting codes at 0x3E4000? This is critical for us as we down load the application binary stream with proper CRC and the boot loader needs to check the CRC correctness prior to jump to application codes.
4- what is the high level boot loader scheme that F2812 support? does it boot load the application stream that covers the entire flash again or just the sectors assigned to application codes?
Thank you so much for your help and i have to admit this is very confusing.
Henry
Hi Krishna,
Thanks.
The embedded boot loader dev is not the issue as i have done it for ARM fitting into our group infrastructure in term of tool and CAN stack / packet definition.
It is the application bin file generation process that is not clearly document and no good example from TI.
I talked to the contact (name K. W.) on embedded side to understand what's going on there and I think that the infrastructure there is different with infrastructure in our group and the CAN packet definition and CAN stack are quite different. Anyway, I found was that the Motorolla Srec format was the way to go to translate from .out to .srec using hex2000.exe from TI. The embedded group take the .srec and their surface tool platform (*scope*) handles it directly from there. Other method of generating .bin from CCS produced the other format that seems to work with TI CKFA binary which is not what we wanted for custom boot loader.
The next step I used TI utility FileIOShell.exe which supposes to translate from .srec to binary and did not work correctly. The reason is that the .srec has gap (see attachment) and other RAM addresses that the FileIOShell.exe did not take care of . The generated bin file crashed after loading.
I looked up the srec format and wrote my own parser to auto fill the "word" addressable "gap" from srec line by line and eliminate any RAM address references. The generated bin file worked fine. I have the standalone srec to bin that works with generic .srec input, .bin output, application starting address and its sector size.
I can share this parser as a reference to anyone who struggles to generate the correct bin file like i did. The snap shot showed the post-process steps i used in CCS to call the hex2000.exe to generate .srec and our custom srec2bin.exe to generate final bin.
During this process, i managed to answer myself the questions above, so i am good for now.
Henry
