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.

C6654 Boot Problem

Other Parts Discussed in Thread: UCD9222

Hello,

 We are using our C6654 custom  board with SPI boot.  Now we are facing a strange problem of DSP instability. Our board is boot capable only 1 minute after power on. If the board is "cold" we have proper SPI data transfer and boot process is completed successfully. But if we are trying to restart our board 1 minute later, the boot process stops after the first SPI transaction (8 bytes) and our processor hanges up. So it seems like we have the problem of C6654 overheating. But we are using heatsink, so bad cooling is not the case.

Some details about our board:

We have another ARM-based processor that takes C6654 out of reset by RESETFULL pin.
SmartReflex is functioning correct, CVDD is adjustable from 1.1V to 0.93V. But some seconds that needed for  ARM-based processor to bring C6654 out of reset we still have 1.1V CVDD. Is it correct?

So we have no ideas why our C6654 is unable to boot after a short time of operating.

We will appreciate any ideas to help us resolve what is causing this issue?

Best regards,

Mike.

  • Hi Mike,

    There are restrictions for how long the C6654 can be held in reset over the life of the part but I don't think that it has anything to do with your problem. The C6654 is a relatively low power part so the chances that the part is overheating are small. What is the difference between your first reset and the one that is failing? Is the DEVSTAT register value the same after both resets? Are the same values read from the SPI memory for both boot attempts?

    Regards, Bill

  • Hi Bill,

    Thank you for your response.

     1) There is absolutely no difference between successful and failing boots.

     2) DEVSTAT register value are always correct according to chosen boot mode.

    3) SPI transfer is controlled by external SPI monitor so we are sure that all data values are the same for every boot attempts. But in case of failing boot only 8 bytes of data are sent before DSP gets hanged.

    There are some more information to consider:  If we have successful boot, then DSP is able to operate properly all the time before reset/restart. But once we restart the board, it comes to failing boot. Any attempts to reboot board right away are unsuccessful. So we need to wait for some minutes for board to get back ability to boot properly. It seems when we are cooling board it is able to return to successful boot sooner.

    Regards,

    Mike.

  • Hi Mike, 

    If you believe that cooling the board changes the behavior, have you used a temperature monitor to check the temperature? Have you added air movement or cool air to keep the temperature low to see if that effects behavior?

    Since you have the JTAG attached to check the DEVSTAT, could you check the memory to see what the SPI memory interface is reading?

    Regards, Bill

  • Hi Bill, 

    1) We have used a temperature monitor and do not see any obvious reasons for such behavior. The temperature of the DSP is not really high. But we are planning to do some more experiments on board temperature conditions.

    2) Having 8 bytes of data sent during failing boot, I have not found them in DSP memory (I have checked region 0x0087 2DC0 - 0x0087 FFFF used by the bootloader).

    In most cases, when  the  DSP does not operate properly, trying to attach JTAG I get a message:

    ---------------------------------------------------------------

    Error connecting to the target: (Error -1143 @ 0x0)

    Device core was hung. The debugger has forced the device to a ready state and recovered debug control, but your application's state is now corrupt. You should have limited access to memory and registers, but you may need to reset the device to debug further.

    <Cancel> <OK>

    ---------------------------------------------------------------

    If I choose OK, I am able to start debugging.  I can step through the source code, watch core and control registers. But registers of peripherals are not accessible. Trying to check them I get error message "Error: unable to read. Console Trouble Reading Memory Block at 0x22xxxxxx...".

    If the board is "cold" and boots OK, I can attach JTAG without any error messages. But DSP hangs after about 10 minutes of operation.

    So the problem still persists. We would greatly appreciate any additional ideas you could provide to us to resolve this problem.

    Regards, Mike.

  • Hi Bill,

    If there is some more information on the subject we can provide you with, just let us know.

    Regards,
    Mike.

  • Hi Mike,

    I've asked the boot rom support team to join the thread to see if we can get some additional information on where the data should end up. Have you been able to capture more information on the temperature where the failure occurs? The component has been tested at temperature so we need to investigate the stability of the SPI interface when the temperature is high. Can you do a read test of the SPI memory when the device is at a high temperature to see if you can read the memory correctly? Can you also capture the read from the SPI memory when the reset occurs at the higher temperature? I want to see the signal integrity so please capture the clock and data as close to the SOC as possible.

    What is the C6654 doing when you reset the part? Have you set the PLLs so that the core is running at full speed? You should also probe the CVDD at the C6654 when the reset is applied. We have seen some boards with an insufficient PDN design that will experience an overshoot or undershoot in the CVDD when the part throttles from full speed to bypass at a reset.

    Regards, Bill

  • Hi, Bill!

    Sorry for the late reply due to national celebrations and my urgent support of the other projects.

    Can you do a read test of the SPI memory when the device is at a high temperature to see if you can read the memory correctly?

    If the C6654 fails to work, its SPI interface is not functioning properly. When I step through the SPI initialization code I am getting error message:

    -------------------------------------------------------------------------------------------

    Trouble Reading Memory Block at 0x8086a8 on Page 0 of Length 0x4:
    (Error -1202 @ 0x8086A8)
    Device core is hung. The debugger will attempt to force the device to a ready state to recover debug control. Your application's state will be corrupt. You should have lim-ited access to memory and registers, but you may need to reset the device to debug further.

    -------------------------------------------------------------------------------------------

    So it is seems impossible to do a read test of the SPI memory when device refuses to work.

    Can you also capture the read from the SPI memory when the reset occurs at the higher temperature? I want to see the signal integrity so please capture the clock and data as close to the SOC as possible.

    We can capture SPI transfer by means of  Beagle I2C/SPI Protocol Analyzer. So here is the protocol of a succesfull boot:

    -------------------------------------------------------------------------------------------
    1st transaction:

    MOSI: 03 00 00 80 00 00 00 00  (8 bytes)
    MISO: FF FF FF FF 00 28 00 00 (8 bytes)

    2nd transaction (reading the Boot parameters):

    MOSI: 03 00 00 84 00 00.... (40 bytes)
    MISO: FF FF FF FF 00 32... (40 bytes)

    Next transactions:

    ... Reading the boot image by means of  alternate 8 and 128 bytes data transfers.

    ---------------------------------------------------------------------------------------------

    here is the protocol if boot failure occurs:

    MOSI: 03 00 00 80 00 00 00 00
    MISO: FF FF FF FF 00 28 00 00

    That is all. No more data are transferred. So C6654 hangs after 1st transaction is finished.

    It seems the boot failure is not connected with the SPI memory problems. Even if we do not have boot image in the SPI memory and are using JTAG to debug code, some time later we are facing the device functionality problem.


    What is the C6654 doing when you reset the part?

    The other ARM-based processor takes C6654 out of reset by setting RESETFULL pin to HIGH.

    Have you set the PLLs so that the core is running at full speed?

    I have tried different PLLs settings but it does not resolve the problem. Moreover I would like to draw your attention to the fact that it does not matter whether I set the PLLs or not. Even if I power on the system without any boot image in the SPI memory, some minutes later C6654 fails to work if I start debugging.


    You should also probe the CVDD at the C6654 when the reset is applied.

    We have checked CVDD pin. The core voltage is changed from 1.1V to 0.93V (VID 100100b). We are using power supply solutions based on UCD9222 and UCD7242RSJ.

    Have you been able to capture more information on the temperature where the failure occurs?

    I need some additional devices for it. In the nearest time I will finish this work and provide you with information on the C6654 temperature.

    Please let me know if I might provide you some more information on the problem.

    Regards,
    Mike.

  • Hi, Bill!

    I have checked the temperature of the C6654 when boot failure occured. It is not high - no more then 40C (104F). So I think this slight heating is not the reason for the problem.

    I have sampled CVDD while SOC taking out of reset and found some oscillations in it (from 0.78V to 1.36V). As I suppose it can be the main reason causing the DSP failure during reset. So our electronics engineer are revising board design now.

    Do you think such oscillations could be the reason for SOC unstability?

    Regards,
    Mike.

  • Hi Mike,

    This type of variation on the CVDD voltage when the part is removed from reset indicates that the power distribution network for you design is not effective. This could easily be causing your problem. You must design you PDN to keep the CVDD supply within regulation at all times.

    You stated that the problem was occurs when a reset is applied after the board is operating. This situation will cause a large drop in the current requirement for the C6654 when the IPs are placed in reset and the PLLs are returned to bypass mode. Are you seeing the wave form above when the reset is applied (falling edge) or when the reset is removed (rising edge)?

    Reseting the part will cause an change in current consumption but that current change might not be the worst case change that you can expect to see. You may have to increase the number or vary the value of your bypass capacitors, change the location of your capacitors or change the shape or position of the CVDD plane in your layout. There are a number of good articles on PDN design available on the internet or in text form. 

    Regards, Bill

  • Hi, Bill!

    I see the wave form above in both cases: when the board is starting and reset has rising edge or when I resetting the board and reset has falling edge.

    I hope our engineers will be able to fix the problem soon. I will inform you when new board is tested.

    Thank you for your advice.

    Regards,
    Mike.

  • Hi Mike,

    How do you connect the CVDD power supply to the C6654? Are you using a plane? Can you provide a picture of the shape?

    Regards, Bill