*.out to *.bin conversion

jean-christophe peltier said:

How to convert a *.out into a *.bin file for a C6678 by using CCSV5 ?

Regarding your other comments, I believe the folks in the C66x device forum are better equipped to answer, so I will move this thread there.

As for the documentation, the procedure is mentioned in the post folder, where we convert the .out file to the .bin.

Thanks,

Arun.

Why the size of bin file is so big?   The size of the .out file is 6.16MB, and the size of the bin file is  2.03GB

Hi,

I assume you are trying to boot NOR from EEPROM (i.e., ROM->IBL->NOR image).

The board should be booting HUA from NOR when it is shipped and you are trying to replace HUA with your *.out file.

Otherwise please disregard this post.

The readme.txt have following text

“2. Copy the binary file to writer\nor\evmc66xxl\bin directory, and rename it to app.bin.”

The binary file includes *.out file, so please rename the *.out file to *.bin.

Regards

Sajesh

Hello, and Happy New Year,

I have tried to use tiobj2bin.bat file coming with gc_xml, as it had been suggested.

In a DOS command window, I have written :

          " tiobj2bin.bat  MYAPP.out  MYAPP.bin  ofd6x.exe  hex6x.exe  mkhex4bin.exe" ,

with the following "*.exe" files :

           - mkhex4bin.exe coming from cg_xml / bin,

           - hex6x.exe coming from C6000 Code Generation Tools 7.3.1 / bin,

           - ofd6x.exe coming from cg_xml / utils.

The result is the following : while the MYAPP.out input file has a size of 3 321 Ko only, the MYAPP.bin output file has a size of more than  Go (2 367 923 Ko exactly).

What's hapenned ?

The MYAPP.out file does work with CCSV5 and the XDS560 probe.

While executing the tiobj2bin batch file, the following warnings were printed :

             " section MYAPP.out (.switch.1) at 085a2a8h overlaps ",

             " MYAPP.out (.text.1) (MYAPP.out (.switch.1) incomplete or skipped) ".

Does it help to understand what's hapenned ?

Thank's

Jean-Christophe Peltier

Apologize-me, I have forgotten to write that renaming my *.out file in *.bin file does not work.

That's why tools such as tiobj2bin and hex6x exist.

How to make make they work ?

Jean-Christophe Peltier

I experienced same situations like you did.

So, I'm suggesting you to upgrade your IBL first with newest version.

After that I could use that ELF format (*.out) directly (just rename it to *.bin).

It seems that was some bugs or elf format was not implemented.

And It seems that your bin file size was so big because your design was devided into several sections.

If offset in cmd file .vect section was assigned in 0x00800000 and .text section was assigned in 0x8000000

then you will get minimum 0x7F800000(2,139,095,040) of file size because address space is linear.

So, I recommend you to use elf format loader like IBL (dynamic section loading supported) to reduce your memory size.

1. Upgrade your IBL newest version first

   (refer to BIOSMCSDK User GUIDE.)

2. Power on your EVM

   * Remember that You have to change boot mode to NOBOOT/EMIF16 mode when you write to NAND Flash.

3. Open CCS with NOR Writer (refer to readme.txt in docs directory)

Well,

Thank's to the suggestions of Kyoung Sup Chang, I have found how to solve my problem. The solution is different that thoses suggested :

I put every things (code, data, stacks, .text, .bss, .cio and so on) in DDR3 and then I download the resulting *.out file.

It does work, even if the use of the L2 SRAM memory is not optimized (used only in cache mode).

From this step, it is possible to test which sections may be moved to L2 SRAM.

First result : the stacks may be moved to L2 SRAM.

We may notice that the differents examples coming with le board are little enough to be completely downloaded in the L2 SRAM,

without using the DDR3.

The problem is not so simple than it seems...

Step 1:

I have an application ("all in DDR3") which works with the XDS560 probe and in the NOR memory.

Step 2 :

I add in it some dead code.

Result : It doesn't work any more, either with the XDS560 probe or in NOR memory.

With the XDS560 probe, I may see that an exception is raised :

                     [C66xx_0] =0x5bf5

                     A2=0x2310100 A3=0x890000

                     A4=0x2310138 A5=0x2310110

                     A6=0x2310164 A7=0x2310108

                     A8=0x2620038 A9=0x2310100

                     A10=0x1 A11=0x8d0ef924

                     A12=0x0 A13=0x0

                     A14=0x0 A15=0x0

                     A16=0x262003c A17=0x0

                     A18=0x80fef4 A19=0x10

                     A20=0xf3333337 A21=0xccccccdc

                     A22=0x102530 A23[C66xx_0] =0x2800

                     A24=0x400 A25=0x20000000

                     A26=0x22002000 A27=0x0

                     A28=0x400 A29=0x0

                     A30=0x8d0feda0 A31=0x1

                     B0=0x1 B1=0xffffffff

                     B2=0x1 B3=0x8d0f2278

                     B4=0x262032c B5=0x8d0f2278

                     B6=0x80ff90 B7=0x2620328

                     B8=0x8b3608 B9=0x0

                     B10=0x15000103 B11=0x8d0a6328

                     B12=0x0 B13=0x0

                     [C66xx_0] B14=0x8d104ed8 B15=0x80fea8

                     B16=0xfa0000 B17=0x0

                     B18=0x0 B19=0x3ff00000

                     B20=0xace19d3c B21=0x400

                     B22=0xace19d3c B23=0xace19d3c

                     B24=0xd6c16666 B25=0x200280

                     B26=0xeaec19 B27=0x0

                     B28=0x0 B29=0x1

                     B30=0x0 B31=0x8d0d5ed8

                     NTSR=0x1000c

                     ITSR=0x0

                     IRP=0x0

                     SSR=0x0

                     AMR[C66xx_0] =0x0

                     RILC=0x0

                     ILC=0x0

                     Exception at 0x8d0d608c

                     EFR=0x2 NRP=0x8d0d608c

                     Internal exception: IERR=0x8

                     Opcode exception

                     ti.sysbios.family.c64p.Exception: line 248: E_exceptionMin: pc = 0x00000000, sp = 0x0080fea8.

                     xdc.runtime.Error.raise: terminatin[C66xx_0] g execution

The value 8d0d5ed8 contained in the B31 register may be found in the *.map file :

                     8d0d5940   xmc_setup

                     8d0d5958   SetPaPllConfig

                     8d0d5ad4   SetDDR3PllConfig

                     8d0d5b30   PowerUpDomains

                     8d0d5c44   DDR3Init

                     8d0d5ed8   CorePllcHwSetup

                     8d0d618c   CorePllcGetHwSetup

                     8d0d6240   bmo_ResetAcq

                     8d0d6274   bmo_AcqTrigger

                     8d0d6704   BMO_AcqCyc

This fact seems to indicate that the exception is raised while running the CorePllcHwSetup() function, before the main() of my application then.

3) Step 3 : The problem disappears if the ".text" section is moved from DDR3 to L2SRAM or MSMCSRAM.

What should I do to have an application which works with the ".text" section in DDR3 ?

Does the platform_lib should be corrected ?

Thank's

Jean-Christohpe Peltier

Problem seems to come from the DDR3 : a software "all in DDR3" does not work while the same software "all in MSMCSRAM" does.

It may be not recommanded to put the ".text" section in the DDR3 because of the need of hardware initialisation before using it.

Jean-Christophe Peltier