• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 82 subscribers
  • Views 337 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.

TMS320F28P650SH: Processor does not release reset, XRSn on power up

Adam Levine
Prodigy 50 points

Part Number: TMS320F28P650SH

Tool/software:

First some background, we started with the LaunchPad kit for evaluation. 

We then designed a prototype/development board of our own.  When we power the unit up the reset line on the processor is never de-asserted.  The +3.3VDC VDDIO and 1.2VDC VDD  (external) voltages are both good.  We had an open drain supervisor circuit tied to XRSn, but removed this for troubleshooting.  The pull-up resistor on the XRSn in is still there. We see a power up sequence in the data sheet that shows VDDIO should come on before VDD.  We shorted the 1.2VDC Regulator for VDD to ground, powered up the 3.3VDC rail and then released the short, but the XRSn line remained  low. 

I don't see any special delay/sequencing circuitry on the launchpad schematic, the 3.3VDC regulator just cascades into the 1.2VDC regulator, which is the same as our design.  We do have other IC's connected to the processor but everything powers up simultaneously.  Another thing I noticed is we have the capability of driving the XIN pin with an external 25MHz CMOS clock via a selectable jumper.  When I connect the clock to the processor it is held low, not sure this is relevant.  

Sort of hard to get out of the starting gate with the JTAG debugger when the device is held in reset.

Any suggestions / trouble-shooting advice is appreciated.
We do have another prototype PCB at another site so we are thinking of bring that on up, but want to make sure we haven't damaged the device. 

Thanks in advance,

Adam

  • 0
    TI__Mastermind 21191 points

    Hi Adam,

    Would you be able to provide schematic or relevant snippets from the schematic to help debug the board design. For the MCU, the supervisor circuit isn't required but it is a recommended component so if you could share the schematic for that as well, that could greatly help diagnose this issue. Can you measure the voltage rails on the 3.3V and 1.2V rails with respect to the board ground and let me know the exact readings you are seeing? The Power Management Module requires the rails to be within a certain threshold or the device will be held in BOR/POR

    Regards,

    Peter

  • 0 in reply to Peter Luong
    Prodigy 50 points

    Peter,

    Sorry about the delay in getting back to you, I appreciate your quick response.


    I have done some more troubleshooting and have some relevant and to me perplexing information.  I went to the remote location to bring up the second prototype board. On power up the unit  came right out of reset.  Here is where things then go wrong.  The processor is connected to an altera/intel max V CPLD.  I programmed the CPLD and then the processor does not come out of reset.  If I erase the CPLD then the processor comes out of reset and I can run the TI XDS110 debugger.  In fact just plugging in the CPLD bit blaster to it's JTAG connector (CPLD erased) causes the processor to reset/debugger crash. Both the processor and the CPLD are using the same 3.3V for the IO and the Processor has a 1.2V regulator for the core, while the CPLD has a 1.8V regulator for it's core. I am not sure why the CPLD being  programmed has such a detrimental effect on the processor, maybe some current sneak paths.  

    Another bit of troubleshooting is I shorted the 1.8V CPLD regulator, powered the board.  In this case the XDS110 attached and I could debug, as soon as I released the short the processor reset/debugger crashed.  I am going take another look at the CPLD I/O to see if I have some a I/O error and created some contention between the devices.  Even if this is so, to me, it doesn't explain why just connecting the bit blaster JTAG (CPLD erased) causes processor to reset/crash.

    As requested I have attached a relevant portions schematic:

    .DevBdRev1.pdf

  • 0 in reply to Adam Levine
    Prodigy 50 points

    Well it could be something more obvious. The reset line is also tied to the CPLD so it is possible this is dragging it low.  The pin on the CPLD is/should be defined as an input so I didn't consider this.  I will double check this when I am back on site.

  • 0 in reply to Adam Levine
    TI__Mastermind 21191 points

    Hi Adam,

    Can you verify the resistance of R1, the pull-up resistor for the XRSn line? We recommend 2.2k per the datasheet. I agree with your thought that the CPLD is probably pulling the XRSn line low or in some way holding down the line which prevents the device from coming out of reset. Can you verify for the CPLD device if the pins could be configured as open-drain on reset or what the IO behavior is on startup?

    Regards,

    Peter

  • 0 in reply to Peter Luong
    Prodigy 50 points

    Peter,

    The XRSn pullup is10K.


    The good news is I did get it working, though I'm not sure which change made the difference as I made a couple.

    First, I removed the RESET line from the CPLD code and that did not fix it.

    Then I made a number of changes:

    1) Added the RESET line back to the CPLD but actually brought it into the VHDL logic and used it for initialization

       a) tri-stated all outputs connected to the processor when reset is low.

    2) In Quartus Prime I changed the Option: Assignments>Device>Device and Pin Options 

       From: "Reserve all unused pins: As output driving ground"

       To: "Reserve all unused pins: As input tri-stated"

    I am not sure which one fixed the issue.  I suppose it is possible that although the RESET was defined as an input, since it was not used it got optimized/synthesized out of the design and the "Reserve all pins.." set it to drive ground.  Maybe if I'm motivated later I'll isolate which one fixed it.  Anyway I'll keep working with it and see what happens.

    I do really appreciate your prompt support.  Now the real fun can begin, speaking of which I got into my interrupt routine when strobe was pressed:)

    Thanks again.  I'll mark this as resolved.

    Regards,

    Adam

  • +1 in reply to Adam Levine
    TI__Mastermind 21191 points

    Hi Adam,

    Great to hear, please reach out with any more assistance you may need in the coming future

    Regards,

    Peter