• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 97 subscribers
  • Views 695 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Boundary Scan test failure with C6748.

Martin Ostrom
Prodigy 110 points
Other Parts Discussed in Thread: TMS320C6748

Hi,

I have a own developed circuit board with a TMS320C6748BZWT3 on.

The board also contains a Xilinx FPGA and a Atmel MCU.

These three IC:s (C6748, FPGA and MCU) have there own separate Boundary Scan chains i.e. three separate connectors.

From these three IC:s I can read the IDCODE and do a simple chain test, I think it just checks that the chain throw the circuit is OK.

So I think I got the C6748 into testmode, pulling TRST high after power on.

The FPGA and MCU also works OK when exercising the I/O:s. This is the first basic test, the I/O:s check themselves within the Boundary Scan cell. Put out a '1' and read a '1' and same with '0'. I'am not 100% familiar with how this works, but it works on the FPGA and MCU.

When I try to do the same thing with the C6748 I get almost 100% fault, some stuck at '0', some at '1'.

Even dangeling signals (not connected to any other circuit) report stuck at '0' or '1'.

Okay it could be so that the signals actually are stuck (soldering this fine pitch BGA, ZWT, can go wrong), but I can from the FPGA set signals to '0' or '1' that the C6748 says is stuck.

What can be wrong?

Is the C6748 not in 100% Boundary Scan mode?

Is the BSDL-file wrong or special in some way.? I read that it is not compliant with IEEE 1149.1 regarding the DDR2-pins.

 

The BSDL-file I have used is sprm366-2p0.bsm.

Hope for a quick answer, thank you!

/Martin

  • 0
    TI__Genius 14545 points

    Martin,

     

      As you mentioned about, there could be many things that can throw you an error in this scenario. I would recommend that you use a divide and conquer approach. It's is a custom board that you developed - you may want to put it under a microscope or use a magnifying glass to ensure you didn't short any pins together. (i doubt that they are all shorted together)

    Second, you'd want to verify that the device is actually in test mode, and that all the power nets of the device are at the corresponding voltage. Once you confirmed that, there will be some additional checks to perform, but I'd start with the basics first for a quick sanity check.

  • 0 in reply to dabuan
    Prodigy 110 points

    Hi Drew,

     

    now I think we solved it!

    If we set the RESET_N pin high after power on it seems to work.

     

    I read about it in the datasheet for the TMS320C6748

    SPRS590B–JUNE 2009–REVISED AUGUST 2010

    6.34.4 IEEE 1149.1 JTAG

    ....

    RESET must be released only in order for boundary-scan JTAG to read the variant field of IDCODE
    correctly. Other boundary-scan instructions work correctly independent of current state of RESET.

    ....

    Here it says that for Boundary Scan test, RESET doesn´t matter.

     

    But following paragraph says

    6.34.5 JTAG 1149.1 Boundary Scan Considerations

    To use boundary scan, the following sequence should be followed:
    • Execute a valid reset sequence and exit reset
    • Wait at least 6000 OSCIN clock cycles
    • Enter boundary scan mode using the JTAG pins
    No specific value is required on the EMU0 and EMU1 pins for boundary scan testing. If TRST is not driven
    by the boundary scan tool or tester, TRST should be externally pulled high during boundary scan testing.

     

    This I can interpret like RESET should be high, "exit reset".

    For me this sounds like contradiction, maybe you could clarify this section.

     

    But anyway, now it seems to work correctly which is very nice!

    Thank you for this time!

    /Martin

     

     

  • 0 in reply to Martin Ostrom
    TI__Genius 14545 points

    Martin,

        That is pretty ambiguous.

    My interpretation of it is that the JTAG logic will function irrespective of the nRESET signal. (other than reading the IDCODE)

    The JTAG logic is only one portion of the device however, and the nRESET pin will fan out to other logic portions of the chip.

     

    nRESET active low will put the device into a warm reset state as per 6.4, which will subsequently tri-state all the device pins.

     

    Good to hear that you got the the boundary scan to work.