TMS320C6654 EMIF16 boot issue with NOR parallele Flash

For EMIF the bootloader just branch to 0x70000000. so just make sure you code c_int00 in 0x70000000. You can have a branch address in this location to your main code.

Do you have an IBL implementation on your board like we have for the EVM?

Regards,

Rahul

HI Rahul,

We do not have any IBL implementation on our board.

I'm trying to boot from an external 16-bit FLASH located at 0x7800_0000. On 6654 device, the boot addr is selected by boot_mode[6-7] pins. The settings of those pins are interpreted correctly by the DSP => the BOOT MAGIC ADDRESS @ 0x008FFFFC = 0x78000000.

At power up, the DSP fetches some data from the FLASH device but the code placed in the FLASH is not executed ( I just trying to switch some LED's ON). At same time, the same code loaded & executed by emulator does the right job.

So, my feeling is that the generated binary file is wrong. Could you check the procedure I'm using to get the binary from .out file?

Thank you

Tomas

Hi Zanzibar,

A couple of clarification fro EMIF16 boot:

1) In case of EMIF16 boot (not via I2C):

The RBL (ROM boot loader) does very little:
It first setup PLL and EMIF and it branchs to 0x70000000.
This means that you need to have your own code present at this address in flash as it will execute in place.

2) In case of EMIF16 boot (via I2C):
I2C boot will load the Boot parameter table that contains the next boot mode.
I2C boot will then revert back to the boot mode read from the Boot parameter that is EMIF16.
Then it behaves like in 1).

3) Try to use EMIF16 (not via I2C) to start with:
a) Use a custom 2nd level bootloader code. Enclosed is an 2nd level bootloader in assembly coming from the below app note:
         Creating a Second-Level Bootloader for FLASH Bootloading on C6000 - SPRA999A

b) Add this bootloader assembly file to the application project
c) build the project so that the boot table is generated in the image (see See section 7.8.6 of the C compiler v 7.3 user's guide - SPRU186w).
   Note that:
                    - SPRA999A is a quite old document but the assembly file should be ok.
                    - when it was written the compiler only supported COFF and not EABI/ELF. So one of the difference would be that the .binit might not be initialized.
                   If what is described in section 7.8.6 does not work you might want to have a look at section 7.8.4 instead.

d) use the hex6 to convert it to binary for the specific format required by the flash

- Since the RBL does not load the image you do not need to do endian conversion here.
You just need to build the image in the endian mode the board/processor supports as it will execute in place from flash.

- You do not need neither Romparse nor B2i2c tools (as long s you do not use I2C).

- Use a JTAG emulator to connect to the target. This way you will be able to:
            check the flash content if it matches the binary. It will tell if what is in flash are valid opcodes.

4) Then you can add the I2C boot portion:
You do not need to reflash the NOR as the same code is re-used.
I guess that the only extra step needed is to create a Boot Parameter Table to be placed in the I2C eeprom. This will be used to let the RBL know to revert to EMIF16 boot.

The Boot table is already present in the NOR flash so no need of it in the I2C eeprom. The Boot config table is not needed neither.

Hope it helps.

Anthony

Tomas,

Can you check the content of the flash via a JTAG emulator?

- C code is divided in sections (.text, .data, .etc). Even if it is a simple C application you need the section to be placed at specific location. CCS does that for you as the CCS loader does place the section at their RUN address. The RBL does not do that for you. You need some code to do it (see previous post).
What is located starting at 0x7800000? Is it code or data?

- The easiest is to have an assembly based while(1) loop as test application. It is all self contained in one single .text section. See enclosed. You can build it and burn it to flash.

Best regards,

A.

Hi Anthony,

Thank you for answer.

I'm trying to execute very simple code from the parallel FLASH (just LED's ON by single write on EMIF16 bus). Up to know, it does not work.

Before using utilities ROMPARSE & B2IC tools, I've tried just to translate the CCS .out file with hex6X utility with following options :

/* HEX6X convertion utility command file for STARC */
D:\Data\STAUBLI\C13000_CarteStarcD\13_Logiciel\DSP\bootloader\Debug\bootloader.out
/*--image        /* to generate continous file */
--ascii     /* ASCII output file */
-e _c_int00  /* Standart entry point */
/*--zero         /* Reset address origin to 0 */
-order L /* Little Endian */
--memwidth=32 /* 32-bit memory */
--map flash_boot.map
--boot         /* create boot table */
/*--bootorg=0x78000000 /* external memory boot */
/*--bootsection=.text 0x78000000 /* give boot section & addr */

ROMS
{
FLASH: org=0x40, len=0x20000, romwidth=32, files={flash_boot.btbl}
}

The obtained ASCII file, I'm converting to binary and programming to the external FLASH device using my own firmware :

1) load binary file to DDR3 memory by TI emulator

2) erase, programme & verify byte-by-byte the data

As I'm not very confident regarding the required byte ordering in the FLASH, each new binary I've tested 4 times by mixing byte order in the FLASH :

B0-B1-B2-B3 => B3-B2-B1-B0 => B1-B0-B3-B2 => B2-B3-B0-B1

Depending on the bytes ordering, the DSP reacts little different(reads 8-10-13 words of Flash and stops, or reads the entire CS space during 10s) , but my LED is never ON.

Tomas,

- Since you can connect to CCS can you compare what you read from EMIF16 with what was loaded in RAM by CCS?
You can get the opcode from the disassembly windows when it is in RAM and compare with what is in flash.

- Can you copy the .map file generated by the linker to this thread?
This should tell what is located at 0x78000000.

- Can you copy the .map file generated by the hex utility as well?

- Can you try an even simplier code (ie the ASM loop I posted before)?

I think that EMIF is 16bit wide. I am not sure what --memwidth=32 does exactly. Have you check in the Assembly guide - SPRU187?

BR,

A.

Hi,

Yes i've compared many times the code loaded by CCS & the data in the FLASH. What it was the reason to play with byte ordering.

regarding to memwidth, I've also tried with 16.

By reading the SPRUGYB (KEYSTONE ARCHITECTURE BOOTLOADER USER GUIDE), I've got some different understanding => the RBL should copy the boottables to internal RAM and jump to the entry point. So I'm don't really understanding how to tell to the RBL to execute the code in place? Could you explain it?

Attached map files and generated ascii file

http://e2e.ti.com/cfs-file.ashx/__key/communityserver-discussions-components-files/639/3821.map_5F00_files.7z

I'm going to try the ASM loop ..

Best reagards

Tomas

Tomas,

Tomas Kajackas said:

By reading the SPRUGYB (KEYSTONE ARCHITECTURE BOOTLOADER USER GUIDE), I've got some different understanding => the RBL should copy the boottables to internal RAM and jump to the entry point

What section of the SPRUGYB  do you refer to?

Tomas Kajackas said:

So I'm don't really understanding how to tell to the RBL to execute the code in place? Could you explain it?

- There is nothing to tell to the RBL. RBL will just detect that it is a EMIF16 boot so it just does what I listed in my previous post under 1).
Since RBL will branch to EMIF16 base address you need to have executable code there. So you need to build the application so that you have valid instructions there.

For a C application you need to ensure that at the address the RBL branch to will contain some valid instruction (otherwise the CPU will jump to an exception). Typically a branch to c_int00.

For the complete boot to work you will need to burn in flash an image that contains:
- a 2nd level bootloader (responsible to copy the different section from LOAD to RUN address and that will branch to c_int00 at the end)
- the boot table (that will be read by the 2nd level bootloader)
- the application (ie the different section at their LOAD address)

I think that there is no need of other tools than CGTools and he6x to create an image for the EMIF16 boot.

Tomas Kajackas said:

I'm going to try the ASM loop ..

Since the ASM code is just made of a .text section it will link it at the beginning of the memory area you defined so in any case you will have an executable code in flash.

Looking at your .map file I do not see any definition of the NOR flash made. You need to have the NOR flash defined you need to build the code so that it executes from NOR flash.
In the ASM code only IRAM is defined. You need to had definition for NOR and located the .text there.

Best regards,
Anthony

Hi,

I've been on totaly wrong way. My understanding was that the RBL is expecting to find the data in boot table format. Now, once I've removed the "-boot" option from hex6x command file, its works better.

Best regards,

Tomas