TMS320C6672: RBL Stuck in Infinite Loop during SPI Boot

Hi Edward,

I will check on this and get back to you.

Regards,

Betsy Varughese

Hi Edward,

Could you please verify that the boot parameter table is correct and properly aligned at the correct address using "romparse"?

Regards,

Betsy Varughese

I believe the boot table is aligned correctly, based on my understanding.
Looking at the binary file/flash memory, the first 40 bytes are:
00 50 00 00 00 32 00 00 00 27 00 01 00 00 00 18
00 04 00 02 00 00 00 01 03 E8 00 0A 00 00 00 00
04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

The remaining bytes up to 0x400 are all 00.

This should equate to:

I've tried a few times with different configurations for SW PLL MSW, SW PLL LSW, CPU Freq MHz, Bus Freq. MHz, and Bus Freq KHz. 

The Boot Parameter Table seems to be formatted correctly, but the Boot Table that follows seems to have additional data that is not called out in SPRUGY5C 3.2.2 Boot Table.

Per SPRUGY5C 3.2.2 Boot Table:
The boot table format is as follows:
• 32-bit header record indicating where the bootloader should branch after it has completed copying the data
• For each initialized section:
– 32-bit section byte count
– 32-bit section address (destination address for the copy)
– The data to be copied
• A 32-bit termination record (0x00000000)

The Boot Table starts at offset 0x400 and begins with the following data:
00 80 0B 9F 0C 00 B1 60 00 00 BA A0 0C 00 00 00

If I understand SPRUGY5C correctly, the first 32-bit record indicates the address where the bootloader should branch after copying is complete. 
The first 32-bit record is 0x00800B9F. 
However, the address should be 0x0C00B160, which is actually the second 32-bit record.
The 3rd and 4th 32-bit records are:
0x0000BAA0   32-bit section byte count
0x0C000000    32-bit section address

It looks to me like there is an additional 32-bit value in the boot table header that I cannot explain.
Additionally, starting at offset 0x480 and continuing every 0x80 bytes there is another 32-bit value that is changing:
0x008085EC
0x00806F03
0x00805DCE
0x0080D402
0x0080EB26

Are these additional values meant to be there? If so, what do they mean?

Hi Edward,

I will check internally and get back to you.

Regards,

Betsy Varughese

Hi Edward,

Thanks for the details.

Regards,

Betsy Varughese

Hi Edward,

Just to clarify are you facing same issue without IBL?

Regards,

Betsy Varughese

Hi Betsy,

It does not seem to matter what I put into Flash (IBL or some other application), the RBL stays in its loop and never branches to the application.

Hi Edward,

Could please confirm the following;

What is the entry point (first 4 bytes at 0x400)? Is it within L2SRAM or DDR?

Have you tried loading a minimal app (e.g., one that loops forever in L2 memory)? If this doesn’t boot either, the problem is likely with SPI image format or RBL setup.

Could you please share the .map and linker file used for this?

Regards,

Betsy Varughese

Edward Eisenberger said:

Are these additional values meant to be there? If so, what do they mean?

I don't think so. But I will check with team and update you within a day.

Regards,

Betsy Varughese

The entry point is in MSM and should be located at 0x0c00b160 according to IBL_SPI.map.
boot.c.obj (.text:_c_int00) is located at 0x0c00b160.

However, the value at offset 0x400 in the binary file/flash is 0x00800B9F. 
It looks to me like 0x0080 is a length and 0x0B9F is a checksum.
This value (and the values at every other 0x0080 offset) is added by the hex6x utility and follows the same format.

I have just tried a minimal app (One that loops forever in L2) and the results were the same. The RBL loops forever and never branches to the application.

Here is the linker file, C66x.cmd:

/**
 * C66x.cmd
 */

-c
-heap  0x4000
-stack 0x4000

MEMORY
{
   LocalL2SRAM:      o = 0x00800000 l = 0x00080000    /* Local L2  SRAM - Minus Vector region*/
   LocalL1PSRAM:     o = 0x00E00000 l = 0x00008000    /* Local L1P SRAM */
   LocalL1DSRAM:     o = 0x00F00000 l = 0x00008000    /* Local L1D SRAM */
   MSMLower:         o = 0x0C000000 l = 0x00200000    /* 2MB Multicore shared memory - Lower half */
   MSMUpper:         o = 0x0E000000 l = 0x00200000    /* 2MB Multicore shared memory - Upper half */
}
 
SECTIONS
{
   .csl_vect      >  MSMLower
   .text          >  MSMLower
   .stack         >  MSMLower
   .bss           >  MSMLower
   .cio           >  MSMLower
   .const         >  MSMLower
   .data          >  MSMLower
   .switch        >  MSMLower
   .sysmem        >  MSMLower
   .far           >  MSMLower
   .args          >  MSMLower
   .ppinfo        >  MSMLower
   .ppdata        >  MSMLower

   /* COFF sections */
   .pinit         >  MSMLower
   .cinit         >  MSMLower

   /* EABI sections */
   .binit         >  MSMLower
   .init_array    >  MSMLower
   .neardata      >  MSMLower
   .fardata       >  MSMLower
   .rodata        >  MSMLower
   .c6xabi.exidx  >  MSMLower
   .c6xabi.extab  >  MSMLower
}

Here is the map file, IBL_SPI.map:

IBL_SPI.map.txt

Some additional odd behavior: 
SPRS708E Table 2-3 indicates the boot parameter table used by the RBL is located at 0x00873680. At startup, the default values seem appropriate.
After the RBL runs to the infinite loop, it appears the RBL copies the data between offsets 0x400 and 0x480 from Flash memory into the boot parameter table located at 0x00873680 then copies the same data again to 0x00873700:

0x00873680    0080	0B9F	0C00	B160	0000	BAA0	0C00	0000
0x00873690    07BF	005B	AC45	11C6	DC45	0627	9247	DC5D
0x008736A0    0313	882A	0210	C802	AE49	4C6E	E9C0	00C0
0x008736B0    3010	A120	6C6E	DC4D	DC45	2641	9247	DC5D
0x008736C0    0210	C802	AE49	4C6E	2002	A120	E5C0	0040
0x008736D0    0080	9362	07BD	005A	01BC	D4F6	019D	5028
0x008736E0    0186	00E8	1014	8013	0627	AC35	E800	0000
0x008736F0    0240	006A	023C	62F6	0280	C82A	02C0	006A
0x00873700    0080	0B9F	0C00	B160	0000	BAA0	0C00	0000
0x00873710    07BF	005B	AC45	11C6	DC45	0627	9247	DC5D
0x00873720    0313	882A	0210	C802	AE49	4C6E	E9C0	00C0
0x00873730    3010	A120	6C6E	DC4D	DC45	2641	9247	DC5D
0x00873740    0210	C802	AE49	4C6E	2002	A120	E5C0	0040
0x00873750    0080	9362	07BD	005A	01BC	D4F6	019D	5028
0x00873760    0186	00E8	1014	8013	0627	AC35	E800	0000
0x00873770    0240	006A	023C	62F6	0280	C82A	02C0	006A

Hi Edward,

I understand your concern. The most likely reason for the SPI boot failure on this device is incorrect byte ordering of the boot image. This issue typically arises from how the boot image creation utilities generate the image and how the flashing tools write it to the flash memory.

Thank you for sharing the .map file and linker script. Could you also please share the i2crom.ccs file? It would help me investigate further.

I'll check on the remaining questions internally and get back to you.

Regards,

Betsy Varughese

Here is the i2crom.ccs file:
i2crom.ccs

Hi Edward,

Thanks for sharing the details.

The i2crom.ccs file seems correct. I'm looking into further possibilities related to this issue and update you within two days.

Regards,

Betsy Varughese

Hi Edward,

Could you please regenerate the image without -swap option? and try?

Regards,

Betsy Varughese

I believe I found the issue. I needed to change the option field in ibl_spi_rom.map.pp from 0 to 1

ibl_spi_rom.map.pp:

section
{
param_index = 0
boot_mode = 50
sw_pll_prediv = 1
sw_pll_mult = 39
sw_pll_postdiv = 1
sw_pll_flags = 0

options = 1

core_freq_mhz = 1000

bus_freq_mhz = 10
bus_freq_khz = 0

addr_width = 24
n_pins = 4
mode = 0
csel = 2
c2t_delay = 1

exe_file = "ibl.spi.ccs"
}

I regenerated the image without the -swap option and programmed flash with it.

With this image, the boot log (0x00873200) fills with: 20B0F7D8 000000C8 00000066

Which I believe is a BOOT_SPI_CHECKSUM_FAIL (102)

Hi,

The engineer responsible is currently out of office. Please expect 2 day delay in response.

Regards,
Sivadeep

Hi Edward,

Apologies for the delay. I was on sick leave.

Edward Eisenberger said:

I needed to change the option field in ibl_spi_rom.map.pp from 0 to 1

May I know if you've had a chance to check this after updating the options to "1"? if we want the IBL to configure PLL , then we have to use "options = 1".

Kindly let me know if the issue is still occurring.

Regards,

Betsy Varughese