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.

No POR for AM1808 using TPS65070

Other Parts Discussed in Thread: AM1808, TPS65070, OMAPL138

HI,

I am using a custom board with  AM1808( pin-compatoble and same as  OMAPL138)  and TPS65070. We have used the reference design from the LOGIC PD EVM kit for OMAPL138 as advised by TI.  We are facing problems in power-on and clean boot.

  •  During power-on we notice that the PB_IN is clean and the Micro-proc recieves a reset from the PMIC through the PGOOD signal( the delay of 400 ms has been observed ,between PB_IN and PGOOD of the TPS65070.. We have also noticed that the "RESETOUT" also comes out clean from the AM1808. Instead of all these coming clean  the tera-term doesn't seem to who anything.
  • We have access to the nRESET (~PGOOD),nTRST and grounded them to momentarily give a reset to the AM1808. This seems to trigger the boot process.Looking at this we have realized that the external reset to the microprocessor seems to have reset it (POR) and thus initiated the boot process.(the tera-term is active and we can notice the boot going through smoothly) 

The differences between ourdesign and the logic PD design are listed below 

 

  • nRESET and nTRST are both pulled high simultaneously while power-on in our design.(this violates the design rule that the nTRST should be high by the time nRESET is pulled high) But this does not seem to be a huge issue since the AM1808  receives the RESET and also gives out the RESETOUT signal which indicates that the uProc is reset.
  • The other change was the crystal not being connected to the OSCVSS pin. I have found somewhere in the forum discussions that it should not be ahuge problem.

 

  •  
    1. Does a bad removal of POR cause any bad boot scenario??
    2. Is the oscllator not stable by the time POR is removed.crerating this problem?? Since the manual reset by grounding the nTRST and nRESET  after a while nitiates a clean boot.

 

 Regards

Siddharth

 

  • Off the top of my mind, I would suggest you look at the deassertion of the reset to the processor and its timing relative to when the clocks are stable to the device (as well as the power supplies).

    If this looks appropriate, then we can start looking at other things you mentioned.  The key distinguishing aspect of your experiment of manually reseting the device after the power up reset is the fact that the supply rails and the clocks are very likely stable when this application of the reset occurs.

  • Hi Brandon,

    As you said I have checked the clocks and power planes stability and all of them seem to be OK. I would like to add in some more observations I have made in the day long debug.

    In all the observations below the nTRST is obtained from the nRESET through an AND gate.(nTRST and nRESET are asserted and deasserted at the same time)

    • We have noticed that by pulling down PB_IN using a push button to create the PGOOD(nRESET to AM1808) which resets the microprocessor doesn't seem to work. The assertion of PB_IN to low sends the Microproc into reset but the deassertion of PGOOD doesn't initiate a clean boot.(boot sequence is not getting intitiated).
    • The rise time of PGOOD/nRESET is found to be 1us. Is this too slow a deassertion ???We have a 10k pull up on the nRESET and changing this to 5k seems to have not at all reduced the rise time of the nRESET . Is there limit on rise time delay during the de-assertion. 
    • As I have mentioned in the previous post that momentarily grounding the nRESET(using a wire) sends the microprocessor into RESET mode and brings it out of it with the boot sequence successfully initialized. This resetting is not debounced thereby creation a flaky reset mechanism. When we tried the same (assertion anf deassertion of nRESET(PGOOD) externally ) through a debounced signal, we could notice that the boot sequence is not initialized. In all the above trials we noticed that the nRESETOUT from the microprocessor is coming out from the AM1808 with a rise time of 1us (same as the nRESET/PGOOD).
    • One thing we have realised is during a POR as well as the asynchronous reset (manual reset provided using an external swtich (PB_IN pulled low) the Micro-proc goes into reset but doesn't come out clean. The core of the microprocessor doesnt seem to come out of the reset clean.
    • We have observed the voltages on the boot-pins and the pins that were supposed to be high are pulled up to 2.5 V. Is this sufficient enuf to be recognized as a high.?? What is the minimum voltage required on the boot pins to configure them as high.

    We would like to know if any timing requirements need to be satisfied  for the de-assertion nTRST and nRESET.

     

    Siddharth

     

     

     

     

  • Have you also checked the timing of the sequencing of the power supplies relative to the clocks and reset?  Obviously, the levels in a steady state environment need to be at expected levels, but are the supplies in a stable, operational state and the clocks to the device stable when reset is released?

    siddharth.k said:

     

    • We have noticed that by pulling down PB_IN using a push button to create the PGOOD(nRESET to AM1808) which resets the microprocessor doesn't seem to work. The assertion of PB_IN to low sends the Microproc into reset but the deassertion of PGOOD doesn't initiate a clean boot.(boot sequence is not getting intitiated).
    • The rise time of PGOOD/nRESET is found to be 1us. Is this too slow a deassertion ???We have a 10k pull up on the nRESET and changing this to 5k seems to have not at all reduced the rise time of the nRESET . Is there limit on rise time delay during the de-assertion.

    It doesn't seem possible that reducing the pullup resistor of the RC network on the nRESET input by half has no impact on the time constant for the RC network.  Especially since the time constant is directly proportional to the resistance and capacitance.  Are there perhaps other driving influences on the RC network that make this 10K to 5K ohm resistor negligible?

    And yes, 1usec rise time seems very long.  I don't know what the evaluation module does off hand.

     

    siddharth.k said:
    • As I have mentioned in the previous post that momentarily grounding the nRESET(using a wire) sends the microprocessor into RESET mode and brings it out of it with the boot sequence successfully initialized. This resetting is not debounced thereby creation a flaky reset mechanism. When we tried the same (assertion anf deassertion of nRESET(PGOOD) externally ) through a debounced signal, we could notice that the boot sequence is not initialized. In all the above trials we noticed that the nRESETOUT from the microprocessor is coming out from the AM1808 with a rise time of 1us (same as the nRESET/PGOOD).

    What does the nRESET input rise time look like in this scenario?

     

    siddharth.k said:
    • We have observed the voltages on the boot-pins and the pins that were supposed to be high are pulled up to 2.5 V. Is this sufficient enuf to be recognized as a high.?? What is the minimum voltage required on the boot pins to configure them as high.

    2.5V should be sufficient.  For your reference, the AM1808 datasheet indicates what the required Vih and Vil are for the inputs in Section 5.2 labeled Recommended Operating Conditions.

  • Hi Brandon,

    • We have checked the supplies and clock stability before reset and they seem to be ok. We have rigged our board to exactly replicate the reset mechanism on the L138 EVM, which is the same as in AM1808 EVM.(the nTRST is grounded and reset only comes from the nRESET).

     

    • Although we tried a debounced way of resetting the Micro-proc it doesn't reset. But a momentary grounding of the reset signal/pin, which essentially creates lots of resets (since it is not debounced) resets the AM1808.

     

    • The only issue on our rigged board  is that the 24-Mhz crystal on our board is not grounded to the OSCVSS but to the DGND , which is not according to the guidelines. (the L138 EVM has also done the same and their design works).Can create problems while resetting??? 

     

    • We have also checked the rise time of the PGOOD signal on the EVM and it is 500us. This a lot more than what we have on our board(1us).Can a faster rise time can be an issue???

    siddharth

     

     

     

     

  • Was this ever resolved?