• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 83 subscribers
  • Views 2875 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CCS/F28M35H52C: Generate application .bin file and load it into flash

Ril Dank
Intellectual 455 points
Part Number: F28M35H52C
Other Parts Discussed in Thread: CONTROLSUITE

Tool/software: Code Composer Studio

Hello,

In order to load it later with a bootloader, I need to generate a .bin file instead of the .out. This is for the M3 part.

In CCS 6.2, in the project properties, I added in the post-build step box :

"${CCE_INSTALL_ROOT}/utils/tiobj2bin/tiobj2bin" "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.bin" "${CG_TOOL_ROOT}/bin/armofd" "${CG_TOOL_ROOT}/bin/armhex" "${CCE_INSTALL_ROOT}/utils/tiobj2bin/mkhex4bin"

as suggested in e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/411296

The .bin is generated, but its size is 524 kB, which is larger than the total M3 flash size (512 kB) and obviously won't fit.

Could anyone tell me what I'm doing wrong?

Thanks,

Ril

  • 0
    TI__Guru 55700 points
    Ril,

    I don't think there is anything wrong with your command. Generally .out file is much smaller than .bin file.

    Did you already try programming the .bin file? I understand .bin size is 524KB. But it should like contain checksum, data length and other information which doesn't get programmed in flash.

    Regards,
    Manoj
  • 0 in reply to Manoj Santha Mohan
    Intellectual 455 points

    Hello Manoj, thanks for your answer.

    My goal is first to program it using "Tools/Load memory" in CCS 6.2, using binary type. It seems to me that all 524KB would be written using this method. And I'm scared that if I'm unlucky, I will write all zeros in CSM password sections (sectors A and N) and permanently lock the device, which happened to me once!

    Ultimately, I want to program it using flash API from a bootloader. In this situation, there is nothing that will tell me how not to write all 524KB.

    I want  the binary to reside in flash from address 0x00220000 to 0x0027FF00 (392956 Bytes). The bootloader will be at 0x00200030 to 0x00220000.

    Maybe there is something wrong in my linker file?

    FYI, the booloader linker file looks like :

    ...
BOOTROM (RX)     : origin = 0x00000000, length = 0x10000

CSM_ECSL_Z1      : origin = 0x00200000, length = 0x00000024 // Reserved to avoid permanent board lock
CSM_RSVD_Z1      : origin = 0x00200024, length = 0x0000000C // Reserved to avoid permanent board lock
FLASH_BOOT (RWX) : origin = 0x00200030, length = 0x00000004 // Not exactly sure what is put in this section, but I guess this one is key.. ?
FLASH (RWX)      : origin = 0x00200034, length = 0x0001FFCC // Bootloader code (I know, it's a big section for bootloader..)
RSVD_FIRMWARE    : origin = 0x00220000, length = 0x0005FF00 // Reserved for application and main function address
CSM_RSVD_Z2      : origin = 0x0027FF00, length = 0x000000DC // Reserved to avoid permanent board lock
CSM_ECSL_Z2      : origin = 0x0027FFDC, length = 0x00000024 // Reserved to avoid permanent board lock

...
.text       : > FLASH
.binit      : > FLASH
.cinit      : > FLASH
.pinit      : > FLASH
.const      : > FLASH
...

    And the application linker file:

    ...

BOOTROM (RX)     : origin = 0x00000000, length = 0x10000

CSM_ECSL_Z1      : origin = 0x00200000, length = 0x00000024 // Reserved to avoid permanent board lock
CSM_RSVD_Z1      : origin = 0x00200024, length = 0x0000000C // Reserved to avoid permanent board lock
RSVD_BOOTLOADER  : origin = 0x00200030, length = 0x0001FFD0
FLASH_BOOT (RWX) : origin = 0x00220000, length = 0x00000004 // Not exactly sure what is put in this section
FLASH (RWX)      : origin = 0x00220004, length = 0x0005FEF8 // Application code
MAIN_ADDR (RWX)  : origin = 0x0027FEFC, length = 0x00000004 // Stores the main function address of application
CSM_RSVD_Z2      : origin = 0x0027FF00, length = 0x000000DC // Reserved to avoid permanent board lock
CSM_ECSL_Z2      : origin = 0x0027FFDC, length = 0x00000024 // Reserved to avoid permanent board lock
...

.text       : > FLASH
.binit      : > FLASH
.cinit      : > FLASH
.pinit      : > FLASH
.const      : > FLASH

...

    Do you see something wrong there?

    Thanks again for your support.

    Ril

  • 0 in reply to Ril Dank
    TI__Guru 55700 points
    Ril,

    I have never tried programming .bin file directly. I can't answer with conviction. Only way to check this is load a smaller example project in controlSuite in .bin format.

    How are you loading .bin code into Flash? CCS On-chip flash tool cannot program .bin file format.

    Regards,
    Manoj
  • 0 in reply to Manoj Santha Mohan
    Intellectual 455 points

    Hello,

    Manoj Santha Mohan said:


    How are you loading .bin code into Flash? CCS On-chip flash tool cannot program .bin file format.

    In CCS 6.2 debug perspective, once connected to the target, I can do "Tools/Load Memory", then select binary as format, and select an address (0x220000 in my case).  Ultimately, I want to do it via the Flash API from a secondary bootloader.

    Is there anybody that knows more about that ? Maybe there is a command option to format the .bin differently ?

    Thanks for your help.

    Ril

  • 0 in reply to Ril Dank
    TI__Guru 55700 points
    Ril,

    Can you confirm whether you are able to load .out file into flash without any problem?

    I'm wondering whether your code size is too big to fit into flash memory of this device.

    Regards,
    Manoj
  • 0
    TI__Guru**** 250260 points

    Ril Dank said:

    The .bin is generated, but its size is 524 kB, which is larger than the total M3 flash size (512 kB) and obviously won't fit.

    Could anyone tell me what I'm doing wrong?

    I can shed some light.  You almost certainly have some large holes in your memory map.  This post explains how that leads to the .bin file being so large.  Unfortunately, I cannot tell you how to fix it.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 455 points
    Hi guys,

    Sorry I took some much time to respond, I had other priorities I had to focus on.

    I don't know what happened, but now the size of the .bin file is ok, around 230kB. There were no particular changes in the project. Even if I go back to the exact same project state (git commit) when I opened this post, the size is now coherent (200-300kB) and I can load it to memory and start the program. Very weird, but good news.

    Now I'm trying to do the same for the C28 firmware. I use the same command but I replaced 'armofd' with 'ofd2000' and 'armhex' with 'hex2000', like so:

    "${CCE_INSTALL_ROOT}/utils/tiobj2bin/tiobj2bin" "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.bin" "${CG_TOOL_ROOT}/bin/ofd2000" "${CG_TOOL_ROOT}/bin/hex2000" "${CCE_INSTALL_ROOT}/utils/tiobj2bin/mkhex4bin"

    And I'm having the exact same problem I had with the M3 binary. It is 524kB, like the M3 bin was when I had the problem!

    I had several colleagues try the same post-build step on their workstation and the result is the same, a 524kB .bin file.

    Shall I open a new post to ask this quesiton ? Maybe on another forum ?

    Any idea where this '524kB' size comes from ? What could I do to have a proper size binary, that will actually fit into flash ?

    Thanks for your support.
    Ril
  • 0 in reply to Ril Dank
    TI__Guru**** 250260 points

    The explanation is the same as the one I gave for the ARM case.  You must have a large hole in memory.  Keep in mind there can be 2 causes of such of a hole.  One is a range of memory that is not used for anything.  The other is a range of memory used by uninitialized sections.  You need to arrange things so that such holes never appear in between initialized sections.  Another way to think about it: The initialized sections must be all be next to each other.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 455 points

    Hi George, thanks for answering.

    I understand what you are saying but I'm not sure how I could fix it or even point exactly where the problem is in my project.

    I have setup a very minimal project with a couple of lines of code and the result is still the same.

    I've attached the linker cmd file and the resulting .out and .map files. Could you have a look at it and let me know if you see anything wrong? 

    Any clue would be greatly appreciated.

    Thanks for your support.

    Ril

    Fullscreen C28.cmd.txt Download 
    MEMORY
{
PAGE 0:    /* Program Memory */

    FLASH       : origin = 0x100000, length = 0x3F000
    FPUTABLES	: origin = 0x13F000, length = 0x00FF0
    BEGIN       : origin = 0x13FFF0, length = 0x2
    RSVD        : origin = 0x13FFF2, length = 0xD
PAGE 1 :   /* Data Memory */

    M01SARAM    : origin = 0x0,      length = 0x800     /* on-chip RAM block M0, M1 */
    PIEVECT     : origin = 0xD00,    length = 0x100
    L03SARAM    : origin = 0x8000,   length = 0x4000    /* on-chip RAM block L0-L3 */

    /* S07SHRAM    	: origin = 0xC000,   	length = 0x8000 */
    S05SHRAM		: origin = 0x0000C000,  length = 0x6000
    S6SHRAM			: origin = 0x00012000,	length = 0x1000
    S7SHRAM			: origin = 0x00013000,  length = 0x1000
}

SECTIONS
{
    /* Allocate program areas: */
    .text       : > FLASH   PAGE = 0
    .cinit      : > FLASH   PAGE = 0
    .pinit      : > FLASH   PAGE = 0
    .binit      : > FLASH   PAGE = 0
    dclfuncs	: > FLASH   PAGE = 0, ALIGN(4)

    ramfuncs    : LOAD = FLASH      PAGE = 0,
                  RUN  = L03SARAM   PAGE = 1,
                  LOAD_START(_RamfuncsLoadStart),
                  LOAD_SIZE(_RamfuncsLoadSize),
                  LOAD_END(_RamfuncsLoadEnd),
                  RUN_START(_RamfuncsRunStart)

	FPUmathTables 	: > FPUTABLES, PAGE = 0

    /* Initalized sections go in Flash */
    .econst     : > FLASH   PAGE = 0
    .switch     : > FLASH   PAGE = 0
    .args       : > FLASH   PAGE = 0

    /* Allocate uninitalized data sections: */
    .stack      	: > M01SARAM | L03SARAM PAGE = 1
    .ebss       	: > M01SARAM | L03SARAM PAGE = 1
    .esysmem    	: > L03SARAM | M01SARAM PAGE = 1
    .cio        	: > L03SARAM | M01SARAM PAGE = 1
}
    C28.out.txtC28.map.txt

    EDIT:

    I'm also adding the report from the command:

    ofd2000 -x C28.out | sectti.pl

    From what I can tell, there are some minor holes between initialized sections, but nothing that justifies the bin file size, as it was the case in the post you mentioned.

    Thanks, 

    Ril

    Fullscreen C28.out.report.txt Download 
    ************************************************************
REPORT FOR FILE: C28/Release/C28.out
************************************************************
                Name : Size (dec)  Size (hex)  Type   Load Addr   Run Addr
-------------------- : ----------  ----------  ----   ----------  ----------
               .text :      60832  0x0000eda0  CODE   0x00100000  0x00100000
              .cinit :       2688  0x00000a80  DATA   0x00109d08  0x00109d08
              .binit :         20  0x00000014  DATA   0x0010a334  0x0010a334
            dclfuncs :        358  0x00000166  CODE   0x0010a264  0x0010a264
            ramfuncs :        742  0x000002e6  CODE   0x001076d0  0x0000a3c6
       FPUmathTables :       3392  0x00000d40  DATA   0x0013f000  0x0013f000
             .econst :      18824  0x00004988  DATA   0x00107844  0x00107844
             .switch :         56  0x00000038  DATA   0x0010a318  0x0010a318
              .stack :       4096  0x00001000  UDATA  0x00000000  0x00000000
               .ebss :      18316  0x0000478c  UDATA  0x00008000  0x00008000
                .cio :        576  0x00000240  UDATA  0x0000a580  0x0000a580
         .MtoCshared :       1856  0x00000740  UDATA  0x00012000  0x00012000
         .CtoMshared :       5304  0x000014b8  UDATA  0x00013000  0x00013000
    PieVectTableFile :        512  0x00000200  UDATA  0x00000d00  0x00000d00
      DevEmuRegsFile :        132  0x00000084  UDATA  0x00000880  0x00000880
         CsmRegsFile :         44  0x0000002c  UDATA  0x00000ae0  0x00000ae0
       AdcResultFile :         32  0x00000020  UDATA  0x00000b00  0x00000b00
      Adc1ResultFile :         32  0x00000020  UDATA  0x00000b00  0x00000b00
      Adc2ResultFile :         32  0x00000020  UDATA  0x00000b40  0x00000b40
   CpuTimer0RegsFile :         16  0x00000010  UDATA  0x00000c00  0x00000c00
   CpuTimer1RegsFile :         16  0x00000010  UDATA  0x00000c08  0x00000c08
   CpuTimer2RegsFile :         16  0x00000010  UDATA  0x00000c10  0x00000c10
     PieCtrlRegsFile :         52  0x00000034  UDATA  0x00000ce0  0x00000ce0
PieVectTableCopyFile :        512  0x00000200  UDATA  0x00000e00  0x00000e00
         DmaRegsFile :        448  0x000001c0  UDATA  0x00001000  0x00001000
AnalogSysctrlRegsFile :        240  0x000000f0  UDATA  0x00001700  0x00001700
   FlashCtrlRegsFile :        772  0x00000304  UDATA  0x00004000  0x00004000
    FlashEccRegsFile :         72  0x00000048  UDATA  0x00004300  0x00004300
       M3PllRegsFile :         16  0x00000010  UDATA  0x00004400  0x00004400
         EpiRegsFile :         24  0x00000018  UDATA  0x00004430  0x00004430
         RAMRegsFile :        124  0x0000007c  UDATA  0x00004900  0x00004900
      RAMErrRegsFile :        124  0x0000007c  UDATA  0x00004a00  0x00004a00
     CtoMIpcRegsFile :        128  0x00000080  UDATA  0x00004e00  0x00004e00
     SysCtrlRegsFile :         58  0x0000003a  UDATA  0x00007010  0x00007010
        SpiaRegsFile :         32  0x00000020  UDATA  0x00007040  0x00007040
        SciaRegsFile :         32  0x00000020  UDATA  0x00007050  0x00007050
  NmiIntruptRegsFile :         12  0x0000000c  UDATA  0x00007060  0x00007060
    XIntruptRegsFile :         32  0x00000020  UDATA  0x00007070  0x00007070
         AdcRegsFile :        160  0x000000a0  UDATA  0x00007100  0x00007100
        Adc1RegsFile :        160  0x000000a0  UDATA  0x00007100  0x00007100
        Adc2RegsFile :        160  0x000000a0  UDATA  0x00007180  0x00007180
        I2caRegsFile :         68  0x00000044  UDATA  0x00007900  0x00007900
      McbspaRegsFile :         72  0x00000048  UDATA  0x00005000  0x00005000
       EPwm1RegsFile :        256  0x00000100  UDATA  0x00005100  0x00005100
       EPwm2RegsFile :        256  0x00000100  UDATA  0x00005180  0x00005180
       EPwm3RegsFile :        256  0x00000100  UDATA  0x00005200  0x00005200
       EPwm4RegsFile :        256  0x00000100  UDATA  0x00005280  0x00005280
       EPwm5RegsFile :        256  0x00000100  UDATA  0x00005300  0x00005300
       EPwm6RegsFile :        256  0x00000100  UDATA  0x00005380  0x00005380
       EPwm7RegsFile :        256  0x00000100  UDATA  0x00005400  0x00005400
       EPwm8RegsFile :        256  0x00000100  UDATA  0x00005480  0x00005480
       EPwm9RegsFile :        256  0x00000100  UDATA  0x00005500  0x00005500
       ECap1RegsFile :         64  0x00000040  UDATA  0x00005a00  0x00005a00
       ECap2RegsFile :         64  0x00000040  UDATA  0x00005a20  0x00005a20
       ECap3RegsFile :         64  0x00000040  UDATA  0x00005a40  0x00005a40
       ECap4RegsFile :         64  0x00000040  UDATA  0x00005a60  0x00005a60
       ECap5RegsFile :         64  0x00000040  UDATA  0x00005a80  0x00005a80
       ECap6RegsFile :         64  0x00000040  UDATA  0x00005aa0  0x00005aa0
       EQep1RegsFile :         68  0x00000044  UDATA  0x00005b00  0x00005b00
       EQep2RegsFile :         68  0x00000044  UDATA  0x00005b40  0x00005b40
       EQep3RegsFile :         68  0x00000044  UDATA  0x00005b80  0x00005b80
    GpioCtrlRegsFile :        128  0x00000080  UDATA  0x00005f80  0x00005f80
  GpioG1CtrlRegsFile :        128  0x00000080  UDATA  0x00005f80  0x00005f80
    GpioDataRegsFile :         64  0x00000040  UDATA  0x00005fc0  0x00005fc0
  GpioG1DataRegsFile :         64  0x00000040  UDATA  0x00005fc0  0x00005fc0
    GpioTripRegsFile :         64  0x00000040  UDATA  0x00005fe0  0x00005fe0
  GpioG1TripRegsFile :         64  0x00000040  UDATA  0x00005fe0  0x00005fe0
       Comp1RegsFile :         14  0x0000000e  UDATA  0x00006400  0x00006400
       Comp2RegsFile :         14  0x0000000e  UDATA  0x00006420  0x00006420
       Comp3RegsFile :         14  0x0000000e  UDATA  0x00006440  0x00006440
       Comp4RegsFile :         14  0x0000000e  UDATA  0x00006460  0x00006460
       Comp5RegsFile :         14  0x0000000e  UDATA  0x00006480  0x00006480
       Comp6RegsFile :         14  0x0000000e  UDATA  0x000064a0  0x000064a0
  GpioG2CtrlRegsFile :        120  0x00000078  UDATA  0x00006f80  0x00006f80
  GpioG2DataRegsFile :         64  0x00000040  UDATA  0x00006fc0  0x00006fc0
    FlashExeOnlyFile :          4  0x00000004  UDATA  0x0013fff2  0x0013fff2
         EcslPwlFile :          8  0x00000008  UDATA  0x0013fff4  0x0013fff4
          CsmPwlFile :         16  0x00000010  UDATA  0x0013fff8  0x0013fff8
.ti_catalog_c2800_concertoInit_flashfuncs :         52  0x00000034  CODE   0x0010a248  0x0000a53a
.ti_catalog_c2800_concertoInit_begin :          4  0x00000004  CODE   0x0013fff0  0x0013fff0

------------------------------------------------------------
Totals by section type
------------------------------------------------------------
  Uninitialized Data :      37978  0x0000945a
    Initialized Data :      24980  0x00006194
                Code :      61988  0x0000f224

  • 0 in reply to Ril Dank
    TI__Guru**** 250260 points

    The size of the binary file is given by the equation ...

    highest initialized address - lowest initialized address

    In this case, the highest initialized address is from the section .ti_catalog_c2800_concertoInit_begin, which is 0x13fff2.  The lowest initialized address is from the section .text, which is 0x100000.  Subtract and get 0x3fff2.  But keep in mind that addresses on C28x are for 16-bit words.  So, all this math counts 16-bit words.  To get 8-bit bytes, you have to multiply by 2.  So 0x3fff2 * 2 = 0x7fffe4 bytes.  That is just a bit less than 512K bytes.  

    The biggest gap between initialized sections appears to be between .binit and FPUmathTables.  There is another large gap between FPUmathTables and .ti_catalog_c2800_concertoInit_begin .  You need to re-arrange things to avoid these gaps.  To know what changes are valid requires knowledge of the system that, unfortunately, I don't have.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 455 points
    Hi George,

    Well.... it turns out that the file size was correct all along... !
    I was looking at the file size in Nautilus explorer (Ubuntu 16.04), and it was showing 524.3kB. Apparently, in this explorer, 1kB = 1000 Bytes, and NOT 1024 Bytes, which is crazy to me.... So the size is actually 512kB (524'260 BYtes) which is correct!

    Sorry for wasting your time, I would have never guess that 1kB was 1000 Bytes in Ubuntu.

    Thanks a lot for your support, I still learnt a few interesting things!


    Regards,
    Ril