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.

TMS320C5505: Programming and bootloading from a SPI Serial Flash on C5505

Part Number: TMS320C5505
Other Parts Discussed in Thread: TMS320C5515,

Hi,

I know this subject has been touched upon previously, but my issue currently persists and I have no solid leads to how to get it working.

So I'm using a new prototype custom board based on a previous TMS320C5515 design that works perfectly both under JTAG emulation and flashing of the 24-bit FLASH memory using the available tools etc.

My new board is based on a TMS320C5505 instead of the TMS320C5515 as we are considering a higher clock speed on this new custom board.

This TMS320C5505 custom board runs under JTAG emulation the development board test code that we have adapted from a previous design to test the new design.

However when I program the FLASH memory using programmer.out with the usual 71 device option and restart the module, it does NOT boot the flashed .bin code.

All this time we have been using the C55BootImage Utility with a customized register file boot option (this is a .dat file that is generated for the purpose of using the application .out file to create a .bin file for flashing on to the FLASH). We have been using this procedure for many years now on the existing C5515 boards in production, with "secure encrypt" possibility as and when required.

With the new C5505 based custom board, the flashed application code does not seem to boot, even with GEL file removed, with register file removed etc. Its almost as if the entry point address to which the DSP should be going to after a boot is wrong or not correctly flashed.

Here is a log of the programmer.out execution showing the .bin file being correctly flashed :

Choose the device...
0XX - CPLD setup only
1x - NAND Flash [CSx: 2,3,4,5]
2x - NOR Flash [CSx: 2,3,4,5]
3 - SPI EEPROM
4 - IIC EEPROM
5 - MMC;  6 - SD
7x - SPI Flash [PinMap x: 1=EVM,2=FDK]
71
Operation to perform...
0 - CPLD setup for this device
1<file> - Program device with <file>
2<file> - Read device data to output <file>
1C:\TEST_CODE_APPI_MAX_R3_B.bin
SPI Flash...
Writing data to device...
Opening C:\TEST_CODE_APPI_MAX_R3_B.bin...
Input file opened
Erasing chip, this may take a while...
Chip erase done.
Programming Complete

So the FLASH memory appears to be correctly programmed with the .bin file

Looking at the .bin file I can see the first word, 0x09AA boot signature, followed by the application execution entry point 0x0001F501 which appears to be correct as in the .map output file.

And the output .map file :

So when I power up the board the code does NOT execute from the programmed FLASH memory. I have included in the main() an infinite loop at the start to toggle some of the GPIOs so that I can measure on the oscilloscope any program activity after initial boot, but no such activity is observed. When I run the exact same application code with the infinite loop under emulation, all is fine. and the oscilloscope shows me the correct GPIO pin toggling.

So in summary :

  • Previous custom board based on the C5515, programs correctly and the application test code is booted and executed as expected with or without a register file, with our without a GEL file in CCS.
  • New C5505 based board with same test infinite loop to toggle the GPIO pins does run under emulation no problems, but when flashed with the same tools already used, I get not apparent execution of the booted code, with or without register file or GEL file loaded. No toggling of the GPIOs is observed etc....

So I would like if possible some kind of explanation to why this might be happening, what makes the execution of the code under emulation with JTAG apparently different when flashed on the same type of memory we've been using for a while on the C5515 based boards, but on the new C5505 custom board there is an apparent problem with the booting and execution of the infinite loop at the start of the main(). How do I know to what point the boot occurs and at what point it might hang-up the code so that it does not continue correct execution as when emulated ?

Would appreciate any suggestions how to get further and beyond this issue. Many thanks in advance.

Regards, Mike

  • Mike,

    Looking at http://www.ti.com/lit/an/sprabd7c/sprabd7c.pdf  section 1.2

    Boot both encrypted and unencrypted images from NOR, NAND, 16-bit SPI EEPROM, Flash, and I2C EEPROM, except for 24 bit SPI serial flash which supports only unencrypted images.

    Please also see e2e.ti.com/.../210297
    I'm wondering if you are hitting this issue.

    Lali

  • Hi,
    With regards to the 24-bit SPI serial flash, we have been using encrypted images to boot from without a problem since 2011 or so, so there is no issue there, but it is only the "Bound to Device option" which is only supported for 16-bit SPI EEPROMs. So yes this is partly true ...
    The boot image I'm using is of the unencrypted type as this is just a test code to validate the custom board, and as it shows on page 8 of sprabd7 the boot signature is 0x09AA at start when you check the .bin file. ... So thusfar I'm still stuck ...
    Regards, M
  • Mike,

    Does an encrypted boot image with a signature of 0x9A4 work?

    Lali
  • Lalindra Jayatilleke said:
    Mike,

    Does an encrypted boot image with a signature of 0x9A4 work?

    Lali

    Hi Lali,

    I've tried the unbound to device encrypted boot image with the 0x09A5 signature as this is straight foward to do, to no avail. So both encrypted 0x09A5 and non-encrypted 0x09AA do not boot. I've taken out the configuration file which does some register initialisation and loads some LCD text to display on the OLED whilst loading the app code from the SPI flash, and still no result.

    So I am bewildered ! I can execute the app code with the emulator, no problems, but as I flash the equivalent app in a binary .bin file and flash it onto the SPI flash memory, it DOES NOT execute.

    One thing to note is that when loading the flashed .bin file from the SPI flash, the initial register initialisation commands and the LCD text commands are loaded as the device's OLED screen lights-up and the boot text displays as shown below. Usually the rest of the code gets booted and then executed, and this is what we usually get with the previous boards.

    This new prototype based on the C5505 CPU seems to boot up the initial register configuration (which by the way, I have stripped down to only a few commands), the pixel mapping to display the text as above, and then I do not know if it loads anything further, but if it does, the rest of the application code that would follow does not execute.

    It would appear it never gets there or it's stuck somewhere in the woods, but the main() function does not begin to execute beyond this ...

    So, I have stripped down the number of registers initialized during the loading of the .bin image to just a few, such as these two : LDOCNTL=0, IDLE_PCGCR2=0xFFBC, then the configuration initializes the LCD and displays the welcome message ... There is not that much being initialized and besides if I do not even create the .bin image with a configuration file it still does not boot and execute normally...

    I guess there must be some difference between the emulated loading of the .out file into the DSP memory, and the loading of the equivalent .bin file from the SPI flash memory, as the later does not work anymore as it used to.

    Somebody at TI might be able to shed some light on where to find this apparent "difference" perhaps some application notes, but essentially we would appreciate a possible explanation and a possible solution... As you can imagine there not much use if the application code executes in emulation perfectly, but cannot be booted and execute from a 24-bit SPI flash memory device ... (The previous custom boards we have for a few years now, based on the C5515 do not have this problem and we flash the .bin code to memory normaly, as advised in the TI application notes etc and it all works fine).

    Regards,

    M

  • Mike,

    I know you initially mentioned something about the application not working with a GEL file.

    When you tested with JTAG, you had a GEL file run on the core?

    If so, did you try without the GEL via JTAG and did it still work?

    Just curious, does your code set the Idle configuration (ICR) register?

    // Enable HWA, CPU, DPORT, MPORT, XPORT, and IPORT in ICR */
        *(volatile ioport Uint16 *)(0x0001) = 0x000E;
        /* Execute idle instruction */
        asm("    idle");
    
        // enable all the peripherals
    	CSL_SYSCTRL_REGS->PCGCR1 = 0x0000;
    	CSL_SYSCTRL_REGS->PCGCR2 = 0x0000;

    Lali

  • Lalindra Jayatilleke said:

    ...

    When you tested with JTAG, you had a GEL file run on the core?

    If so, did you try without the GEL via JTAG and did it still work?

    ...

    Hi,

    Sorry for the late reply. Have been on vacation for the last three weeks.

    So, yes there was a GEL file, and the code runs on JTAG with or without the GEL file, and it starts the main() etc.

    My problem shows up with the flashed .bin code.

    Lalindra Jayatilleke said:

    ....

    Just curious, does your code set the Idle configuration (ICR) register?

    // Enable HWA, CPU, DPORT, MPORT, XPORT, and IPORT in ICR */
        *(volatile ioport Uint16 *)(0x0001) = 0x000E;
        /* Execute idle instruction */
        asm("    idle");
    
        // enable all the peripherals
    	CSL_SYSCTRL_REGS->PCGCR1 = 0x0000;
    	CSL_SYSCTRL_REGS->PCGCR2 = 0x0000;

    Lali

    Hi Lali, yes the application test code and the GEL config file sets the following amongst other at startup :

    IDLE_PCGCR = 0x62B1;            // PCGCR1
    IDLE_PCGCR_MSW = 0xFFBC;        // PCGCR2
    
    // Disable unused CPU domains and keep others active.
    // HW FFT Accelerator Disabled, all others active.
    IDLE_ICR=0x020E;
    asm(" idle");
    
    

  • Mike,

    Can you please check via CCS where the program counter is when you try to boot the application via SPI?
    Trying to see if its still in the bootloader, or reached the application.

    Please don't have a GEL file via JTAG when you try this so that you don't re-init the core with the application loaded via CCS.

    Lali
  • Hi Lali,

    Ok, so I did this without the GEL file and after activating boot from FLASH memory I connect with JTAG to find the program counter at the following bit of code :

    CLKSTOP |= USBCLKSTPREQ;				// stop USB clock.
    
    do
    {}
    while(!(CLKSTOP & USBCLKSTPACK));			// wait for confirmation.
    
    IDLE_PCGCR_MSW = 0xFFBC;
    

    So the above part of the code is inside the InitSystem(); in the main() fuction at the start.

    Void main()
    {
    	Uint16	usb_disconnect = FALSE, i, j;
    	char	serial_number_complete[OFFSET_PRINT_SN+SIZE_SN_COMPLETE +1 ]={"SN:"};
    	char	rev_hardware_ascii[SIZE_REV_HARDWARE+10]={"REV HARD:"};
    	char	id_test_ascii[SIZE_ID_TEST_CHAR+8]={"ID TEST:"};
    																			
    	Uint16	rev_hard=0, plan_freqs=0, temp[2];
    	Int16	temp1=0, temp2=0;
    	LgUns	id_test;
    
    
    	asm("	BCLR XF");					// turn off XF
    	IRQ_globalDisable();					// disable all interrupts.
    	InitSystem();						// Initialisation of pll etc.
    
    	Init_SAR();						// Initialisation of the SAR etc.						
    	wait(20000);						// delai
            ConfigPort();						// configuration des directions des ports et fronts du dsp
    

    So for some reason it appears to be stuck at this point inside the InitSystem() function.

    I have seen this before under emulation but can be resolved by a reset ... it appears to be occasional when under emulation, and I reset the board. But now when not emulated it seems it gets stuck here consistently. I can remove this snippet of code but it is advised to wait for an acknowledge when requesting the USB clock stop.

    Any thoughts on this ?

    regards,

    Mike

  • Ok Lali, so this was all a redundant check afterall, as the USBPWDN in the USBSCR register is by default set to 1 after a DSP reset and the USB module is actually powered-down. So an oversight easily resolved afterall. Many thanks !
    Regards,
    Mike