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.

TMS320C6655 DSP boot issue

Other Parts Discussed in Thread: AM3358, TMS320C6655

We are currently using an AM3358 ARM processor connected to a TMS320C6655 via a Marvell Ethernet Transceiver.  The ARM processor boots the DSP via Ethernet Transceiver over SGMII interface.  What we are currently seeing in our existing prototypes...After system boots-up and the ARM receives the Ethernet Ready Packet response from DSP, the AM3358 starts transmitting packets to DSP per Ethernet Boot loader Process.  Problem...The DSP is not boot-up approximately 20-25% of the time.  We are looking for suggestions to debug this DSP boot-up issue in our system.  Note:  We are using the existing TI boot loader.  

James

  • Hi James,
    Problem...The DSP is not boot-up approximately 20-25% of the time.


    You mean, it is able to boot successfully 7-8 times out of 10 times. Is my understanding right?


    Note: We are using the existing TI boot loader.

    Are you using direct RBL(ROM bootloader) or IBL(Intermediate/Secondary boot loader)?

    Thank you.
  • Hi Raja,

    Yes...We are able to boot successfully 7-8 times out of 10 startups.  I believe we are using the direct RBL ROM bootloader  but I will re-confirm with the software team and reply back regarding this one.

    James

  • Raja,

    I have confirmed that we are only using the direct RBL ROM bootloader in our systems currently.

    James

  • The RBL has timeout and retry count fixed. The source code for the C6657 ROM is published on the wiki for reference:

    http://processors.wiki.ti.com/index.php/Keystone_Device_Architecture#Keystone_ROM_Boot_Examples_and_Reference_code

    Please refer to gauss.h and ethbpmain.c functions for default timeout and retry values and the implementation.

    Function: bootMainBootp()

    Source File: ..BootROM_c6657\C665x_bootROM_src\main\ethbpmain.c

    If you are using Ethernet as second stage boot then you can change the default timeout values.

  • HI Raja,

    FYI...The 2 DSP configurations in our system are for Ethernet boot from AM3358 (Primary boot mode) and Emulator connectivity for debug. I have not had a chance to digest above as of yet. Does above fix the reported issue with Ethernet packets not being received some of the time after a system reset reported in ClearQuest Incident Report or possibly another issue. In order to fix this in current hardware does this require incorporating an Intermediate boot loader which we are currently not using! The parts we currently have are labelled TMS320C6655CZH (A1GHz @ 2012).
  • Raja,

    One more bit of information.  I do not have an eeprom connected to DSP on my custom hardware platform for any type of intermediate boot requirement if  that is required with earlier version of silicon.  Is this occasional Ethernet packet transfer issue resolved in latest silicon version boot ROM or planned to be resolved in very near future...Very Important!!!  Boot-up time is very critical to our system so having multiple boot stage operations to insure packets are received correctly by DSP could take longer than is desired based on our system requirements even if we could support an intermediate boot mode in the future???  We need TIs help to better understand this issue and come to the best resolution...

    Thanks,

    James

  • Hi Raja,

    Any feedback to my last post?  

    James

  • Hi James,

    When the ethernet boot fails, can you provide the program counter value at  which the DSP BootROM is hung?? You can check this by hooking up an emulator and connect to the DSP using CCS. Make sure you remove the GEL file before you connect using the emulator else it will chnage your device state. Based on this information, we can compare that to the ROM symbols and let you know what may be causing the issue. The ethernet bootROM on this device is sensitive to the ethernet traffic that may exist on the network so we recommend that you take steps to reduce the congestion in the network that connects the boards and see if it is impacting your setup. In the past we have seen if a packet is lost then the boot seem to fails. Other than a reboot, the only other option available is to send each packet twice. Ideally the bootROM should have been sending ACK after every packet is received so that the loader can resend packets that were not received but at the moment there is no hand shaking involved so the packet loss will cause the boot to fail.

    Raja`s recommendation to use a secondarybootloader like an IBL would only applies if you want greater control on ethernet boot than the RBL offers or if you need TFTP boot that the RBL doesn`t support.

    Regards,

    Rahul

     

  • Rahul,

    Sorry for the long response time time from last post.  We were pulled off to work some sustaining activities.  We are now back looking at the Ethernet Boot issue from previous post and the DSP does not appear to be getting hung at a particular counter value when it does not receive packets from ARM.  The typical PC reg values after several DSP boot failures was...

    0x20B01A2C

    &

    0x20B10DAA

    The software team is going back to review the boot code that we are running on ARM side and was provided by TI to see if any issues there.  We were wondering as we start to look at this if you could provide us preferably the Boot Code that resides on DSP as part of our debug testing or at a minimum the symbol table...We would prefer to get access to the Boot Code for our testing as we try to debug this issue.  Your assistance as we try to quickly resolve this issue is  greatly appreciated!!!

    Thanks,

    James

  • The bootROM code for C6655 is provided here:

    We don`t typically provide ROM symbol table due to concerns with exposing security related details. If you have a local TI contact, we can evaluate working with him if we can provide a subset of the symbols that are relevant to Ethernet boot.

    Regards,

    Rahul