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.

TMS320C6678: DSP doesn't read the correct value on the boot mode pins

Part Number: TMS320C6678

Hello,

I have custom board with 4 TI DSPs (TMS320C6678).  The boot mode pins double as GPIO pins that are connected to Xilinx FPGAs.  I have pull-up/pull-downs on the bootmode pins.  I'm noticing that certain pins are not being detected properly by the DSP.

For example, register 0x02620020 returns 0x00019001 instead of 0x0001980B for 3 of 4 DSPs.  The expected value should be 0x0001980B based on the bootmode pins resistor pull-up/pull-down configuration.  Also, the measure value the following voltage.  I've only focused on the pins with unexpected behavior.  Can you help understand why this would be happening and what can be done?  Is there something I'm missing?  I've included the schematic page of the bootmode pins for your review as well.

DSP Boot mode pin Voltage (V)
1 0 1.72
1 1 0
1 2 1.69
1 10 0.06
2 0 1.72
2 1 0
2 2 1.69
2 10 1.69
3 0 1.72
3 1 0
3 2 1.35
3 10 0.07
4 0 1.698
4 1 0
4 2 1.698
4 10 1.698



  • Hi Joseph,

    I've forwarded your query to the software experts. Their feedback should be posted here.

    BR
    Tsvetolin Shulev
  • Joseph,

    The image that you attached is not readable.  However, there are some basic checks that you need to perform.  What is the FPGA doing with these pins during boot?  Are they inputs or outputs or is the FPGA even loaded with a configuration?  The FPGA cannot be driving these pins during bootmode latching if you expect the resistors to be able to set the level.  The RESETSTATz output can be used to disable FPGA drivers connected to BOOTMODE pins.  Also note that FPGAs sometime have internal pull resistors active when not programmed.  Is there anything else attached to these pins that could be providing leakage to bias the BOOTMODE inputs?

    Tom

  • Joseph,

    Do you see identical results on all boards assembled?

    Tom

  • Tom,

    Yes, I see results on at a least 1 other board.  I haven't gone through the process of check all board just yet.

    As regards the questions about the FPGAs, they are not configured.  The FPGAs on the board are configured to disable internal pull-ups when not configured.  Also, the bootmode pin 10 is not connected to a FPGA, however, two of the four DSPs have incorrect measured voltage on those pins.

    If you like, I could send you a pdf of schematic.  Let me know the best way to this.

    Please advise,

    Joe

  • Joe,

    You can attach a PDF file to the E2E post.  Please only attach the section related to the BOOTMODE pins.

    How many boards have you built?

    Tom

  • DSP_Bootmode.pdfTom,

    So far we've built 4 boards.

    I've attached the pdf file.

    Thanks

  • Joe,

    Do all boards tested have the same result?  If so, you need to determine what is providing the extra leakage.  The 1K ohm resistors should overcome the internal pulls and result in valid input levels.  You may need to verify that the resistors installed are the correct value.  You may also need to verify that there are no PCB circuits connected by mistake.  The C6678 is not causing these voltages to occur while it is held in reset.

    Please confirm that the voltages above were measured while the C6678 was held in reset.  Also, verify that a valid clock is being provided to the C6678 while these voltages were measured.  You should also validate that your power-on sequence matches the datasheet requirements.

    Tom

  • Tom,

    Here are my latest observations from our discussion a few weeks back.

    1) Of the four boards that we built, 2 boards display this issue while two don't.  

    2) The voltages above were not measured when the device was in reset.

    3) When the reset is asserted all GPIO pins are have the voltage level that is expected.  So the 6678 is not causing these voltages to occur in reset. This behavior is observed whether POR_N or RESET_FULL_N is asserted.  

    3) The reference clocks are present.

    4) I checked that the power up sequence matches the datasheet to the best of my understanding.  I'm using the sequence: 1.8V -> CVDD -> CVDD1 -> 1.5V.  I've checked to make sure the clocks are disable while power supplies stabilizes and that it's active before the POR_N and RESET_FULL_N goes high.

    In the errata, there is usage note specifically about the POR_N and RESET_FULL_N.  What is the intent of this usage note?

    Is there anything else I can look at or anything mitigating I can do on the next revision?

    Thanks,
    Joe

  • Tom,

    Additionally, it appears that all the other functionality on the 6678 operates as expected when reset is deasserted. I'm not sure if this means anything but it's a data point.

    Thanks
  • Joe,

    The Usage Note is emphasizing that RESET_FULLz should be the signal used to latch the BOOTMODE pins and that PORz should rise before RESET_FULLz.  Note that PORz must remain low until after all power sequencing is complete and the clocks are stable.

    You say that the proper voltage exists on the BOOTMODE pins when the C6678 is held in reset.  Therefore, that implies invalid voltages only exist after reset release.  You will need to determine what devices are driving the BOOTMODE nets when the invalid voltages are measured.  If you put the C6678 back into reset after improper voltages are measured, do proper levels return?  Is any other device attached to these nets other than the C6678, the BOOTMODE resistors and the FPGA?

    Tom

  • Tom,

    The PORz is being held low while the power supplies are being initialized and stabilized.

    Yes, invalid voltages exists only after the 6678 reset is released. When reset is held I've observing the expected voltage. I have been able to replicate this behavior repeatedly.

    Only the 6678, the BOOTMODE resisters and FPGA are connected to these pins. In one specific case only the 6678, BOOTMODE resistors and header in play.

    For parts that are not working I read back consisently 0x19001 for register 0x02620020 when R18 is not populated and 0x19803 when R18.

    Thanks,
    Joe
  • Joe,

    I recommend that you create a table that lists the pull-up resistor value installed, pull-down resistor value installed, resistor inside C6678 (PU or PD) and steady-state voltage both in and out of reset for each BOOTMODE pin for both a 'failing' board and a passing 'board'.  Please attach the table to the forum post.

    Tom

  • DSP_bootmode_pins.xlsxTom,

    Attached excel spreadsheet with information you requested for a "good" board and "bad" board.  Since each board has 4 6678s, I only choose 1 6678 for this exercise.  

    Please advise,

    Joe

  • Tom,

    Also, by the way I will change the external PU on BOOTMODE1 to 1k from 4.75k. I recognize this is an error, that will be fixed. Never the less, it stills returns a high on that net.

    Thanks,
    Joe
  • Joe,

    Bit 15 and bit 11 show that something is driving these pins low after reset disabled (inactive high) on the bad board.  This contention was not present while the reset was enabled (active low).  How soon after reset release did these signals get pulled to this low voltage.

    Bit 10 on the bad board and bit 8 on the good board show a high voltage after reset release.  Is this expected on the good board?  If so, what is driving it?  How soon after reset release did these signals get pulled to this high voltage.

    I agree that the pull-up resistor value on bit 3 needs to be changed to a 1K.

    Tom