TMS320C6727B: Floating GPIO Pins

Are the pins configured as GPIO or AXR? Which pins (package/ball)?

--Paul

Pins are configured as GPIO. But even at power up before the UHPI boot, pin floats high which is not typical. BGA package - GDH (S-PBGA-N256).

Is this just one pin or multiple?  Can you giver me a specific pin? 

You mention that this is not typical, compared to  other pins? samples? 

-Paul 

Traces_Floating pin.docx

AXRO13 Pin B6 appears to be floating for sure. AHCLKR2 pin C14 is used for the external interrupt and that's not triggering either. I have attached screenshots of the layout.

If C14 is configured as an input for an external interrupt, it's should be driven by the source, or via a pull resistor. Perhaps you are using the internal pull? 

Are you seeing the same issue/symptoms with other boards?  if working on other boards, perhaps there is an assembly issue? 

You are correct C14 is driven and the concern there was that it wasn't triggering the interrupt. Pin B6 is an input into an FPGA. Has no internal/external pullups. FPGA detects it as high at power up. A measurement on the net drops the voltage to zero and the FPGA detects the change. It may very well be a board issue but would be helpful to know what  the initial state of B6 is at power up when configured for UHPI boot but prior to the boot. Is that behavior normal.

I had the boards reworked and new DSP chips placed. Now when I write to ochip memory 0x10000000+ and readback I'm always reading back 2650 or 0x00000A00. Before the chip change I was accurately writing and reading back. What does 2560 indicate? Thanks.

Hi Paul, 
did you have the chance to take a look at this? 
appreciate your feedback!

thanks,
Jens, FAE 

I don't think there is any significance to the value you are reading back from memory.  Is it the same value after power cycling the board?

Given that this is a new problem after swapping devices, the primary suspect will still be board assembly issues.   It is possible one or more of the power supply balls is not connected.

Can you ready the correct, known reset values of registers? Can you read/write peripheral registers correctly? what about external memory? Any other indications of strange behavior? 

Hi Paul,

thanks for the feedback. Prior to the rework I was able to write and read back from on-chip memory using UHPI. Could write the whole program hex file and and read it back accurately. Now depending on how I reset the chip I read back the first value written to address 0x1000000 for all subsequent addresses. if I hold the chip in reset I readback 0x00000A00 (int 2560). This must be reset value. I have attached a pdf of some changes we had to make to the design to address some obsolescence and long lead time issues and wanted to run them by you to make sure they could not be an issue.  They were changes to the power supply filters and voltage supervisor circuit. Your feedback is appreciated. Thanks

Hi Paul,

thanks for the feedback. Prior to the rework I was able to write and read back from on-chip memory using UHPI. I could write the whole program hex file and and read it back accurately. Now depending on how I reset the chip I read back the first value written to address 0x1000000 for all subsequent addresses. if I hold the chip in reset, I readback 0x00000A00 (int 2560). This must be reset value. I have attached a pdf of some changes we had to make to the design to address some obsolescence and long lead time issues and wanted to run them by you to make sure they could not be an issue.  They were changes to the power supply filters and voltage supervisor circuit. Your feedback is appreciated. Thanks

Working and Not Working Design Differences.pdf

Derek

No feedback yet, 

--Paul 

Hi Paul,

We still have not been able to figure this one out. Looks like a portion of the chip including the clock/PLL is not working. One observation made is a 3.3V clock being used but max clock input is 1.8V. See attached. This works fine on a different board. Is this a potential issue? Any feedback on this will be greatly appreciated. 

Thanks,

Derek

TMS320C6727 Max Ratings and Clock.pdf

Derek

Apologies for the delay.  Yes, Driving a 1.8v input with 3.3v is an issue. inputs should never be driven outside their absolute max range.