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.

C6747: port pin electrical failure

Other Parts Discussed in Thread: TMS320C6747

Hi,

My board uses C6747BZKB3. I have two prototypes on which the same port pin is now malfunctioning. It is pin GP1[7] (ball N10) that is always configured in GPIO input.

Since this pin has a weak internal pull-down, I have an external pull-up (connected to 3.3 V) to make the input signal High at power-up and for the case where the master board does not use the signal (not connected). When I probed this signal outside the DSP, it was not near 3.3 V but more around 2.1 V.

The documentation states that the internal pull-ups and pull-downs are "weak" and to acheive the required opposite level, a 1 kohm resistor is suggested. I tried 4.7 k instead and the level was now 2.4 V, still unsatisfactory with respect to the TTL Vi High threshold. So I used a 1 k and the level did not change. It seems that the port pin is saturated or in contention. I confirm that there is absolutely no other device connected to this signal so it is not driven by another source.

I modified a prototype to have this signal go to another port pin (the malfunctioning pin is not connected anymore). I'm now using GP0[11] and everything is working properly, the level is almost 3.3 V.

I also did some tests with the emulator and verified that the GPIO port configuration was as configured as expected (PINMUX and DIR01 registers). When the pin is set to Hi-Z instead of being connected to the GPIO interface, the level of the malfunctioning pin did rise to almost 3.0 V. I tried many configurations while probing with the scope and I may have done a contention that damaged the port even more because now I always read about 0.5 V. The first prototype did not undergo all these tests, the port pin just died and was always stuck to 0 V.

I have other similar signals on my board that are connected to other DSP GPIO pins and these have not malfunctioned (yet).

Is there any reason why this port pin may be more sensitive than others? Have you heard of this type of problem in the past?

Best regards,

SC

  • Hello Scoutu,

                            Please confirm the following conditions : -

                  1.       In TMS320C6747 I/O PORT is configurable for 1.8V & 3.3V. In both cases you are powering with 1.8V or 3.3V ?

                  2.       In both cases status of Internal Pull-down resistor  is "Enable / Disable" ?

                  3.       In both cases status of Internal Pull-up resistor is "Enable / Disable"?

                  4.       You configured the GP1[7] as input but disabled the other Peripherals properly?


                            Is it possible to post the GPIO initialization code only.

     

    Regards

    Abhijit

  • Hi Abhijit,

    Here are the answers to your questions:

    1. There is no 1.8 V on my board. All DVDD supply pins are connected to 3.3 V. From the datasheet, I understand that some USB pins can use 1.8 V but that all digital I/O must use 3.3 V. Is this correct? Furthermore, I don't see any registers accessible by software that can allow selection of 1.8 or 3.3 V.

    2. The datasheet states that the Internal Pulldown and Pullup resistors are not configurable (enable/disable). Some port pins have IPD and others have IPU and these cannot be disabled.

    3. Same as 2.

    4. The PINMUX registers allow the selection of the peripheral output that is connected to the port pin (the pin always feeds all the peripheral inputs). In my case, I selected the GPIO peripheral. Even is another peripheral associated to the same pin was active, there should not be a contention. Anyways, the LCD controller and EMIFA peripherals also used by GP1[7] are not used so I do not activate the power to them through the PSC registers.

    The PINMUX registers are written to by the ROM bootloader because I use the AIS file format. This means that after booting, GP1[7] is connected to the GPIO peripheral. The pin for GP1[7] is in PINMUX16. Here is the value of that register: 0x00888888. Also, I activate the GPIO peripheral via the bootloader and the AIS file. Here are the numbers of the activated peripherals in PSC0: 0,1,2,4,9 and PSC1: 3,6,7,10,20. (GPIO is #3 in PSC1)

    Here is the code for GPIO configuration for this pin:

    CSL_GpioRegsOvly GPIO = (CSL_GpioRegsOvly)CSL_GPIO_0_REGS;

    GPIO->BANK[GP1].DIR |= GP1P7;    /* input */

    When I check the configuration at run-time using the emulator, I use a GEL file to configure the DSP. The values for PSC and PINMUX in the GEL are exactly the same as the ones found in the AIS file.

    Best regards,

    SC

     

  • Hello Abhijit,

    I haven't received a response since almost two weeks. Do you require some additional information? Please let me know.

    Best regards,

    SC

  • Hi SC,

    I would first double check there is really nothing else driving the bus externally. Also, please make sure you are probing at the right point. Moreover, make sure you are not accidentaly accessing any reserved memory spaces. Also make sure indeed all the power pins are powered @ 3.3v.

    If possible, set the device to boot in emulation boot mode or uart boot mode. Instead of running your application, only run a standard GEL file and setup PINMUX, power, and GPIO.

    Please let us know what you find out.

    regards,

    Paul

  • Hello Scoutu,

                            Any update ? Please let us know find out.

    -- Abhijit

  • Hi,

    I checked the trace going to the port pin in the PCB design file and it goes to our I/O connector. On the other side of the connector, the corresponding signal does not exist, there is no trace going to that pin.

    Yes, I have 3.3 V everywhere except for the incoming 5 V that feeds the 5 -> 3.3 and 5 -> 1.2 V regulators. The 5 V doesn't go elsewhere.

    Like I indicated earlier, I did run my application in emulation mode using a GEL file. This allowed me to check the port configuration registers and the electrical status of the pin before running my application. But the port pin operation seems to be already damaged so it is hard to come to a conclusion.

    I had a different problem giving a similar result. On another prototype, the SPI port stopped functioning. After further investigation, it narrowed down to the SIMO signal on our board I/O connector that is right next to the 5 V going to the aforementioned LDO. I think that there may have been a contact between the SIMO and 5 V when hotswapping our prototype without carefully aligning the pins. Since the DSP ports are not 5 V tolerant, I guess that this damaged it. In the case of the pin in this post, it is placed next to a Ground Pin. I don't see how this could damage the port pin because after a hardware reset, the DSP places all pins in analog input mode, hence contention should not happen. Could the pin be in an intermediate state between the arrival of the 3.3 V I/O voltage source and the end of the internal reset cycle?

    Best regards,

    SC