• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 3 answers
  • Subscribers 99 subscribers
  • Views 490 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.

TCI6630K2L: Sleep Mode / Resets

Ryan.Bishop
Expert 3900 points
Part Number: TCI6630K2L
Other Parts Discussed in Thread: 66AK2L06

Hello,

One of our customers is seeing some strange reset behavior as follows:

  • Does the TCI6630K2L support sleep mode where it can be put to sleep by setting the BOOTMODE register with “SLEEP” mode and toggle RESETFULL. Then later write it with a normal boot mode (ie SPI) and toggle RESETFULL? 
    • I’ve seen weirdness around this when we put it to sleep. 
    • After a while (10-15 minutes) we try to wake it up and it never completes its boot configuration (RESETSTAT stays low). 
    • It seems like it does this if the DSP is allowed to sit in sleep mode for a while (10-15 minutes). 
    • When it fails to reset properly (RESETSTAT stays low) it has to be powered down for 15-30 seconds.

Regards,
Ryan B.

  • 0
    TI__Mastermind 37500 points
    Hello,
    I have looked in the Keystone II ARchitecture ARM Booloader User Guide, sruhj3.
    This does not tie into partial reset of the device.
    The Reset sequence has to be complete.

    The ARM performs in sleep mode the "basic initialization" no user application is loaded.

    If you then added code for the ARM to wake from interrupt, you could wait in this partial boot state until the external event triggers
    the application.

    You could then run your application (which now wakes up more of the device, causes more power to be utilized).
    You could then put the ARM back to wait for interrupt.

    Please send the document that describes the sleep mode you are trying to use.

    Regards,
    Joe Quintal
  • 0 in reply to Radio-Joe
    Prodigy 50 points
    Joe,

    We have the 2xK2L devices controlled by another processor. We originally wanted to hold the K2L in reset until it's needed, however there are stipulations how long it can be held in reset (no longer than 1hr, or some % of it's lifetime). So we need to take it out of reset (following the power up sequence for RESET, POR, and RESETFULL and put it to sleep by driving the BOOTMODE pins controlled by the other processor. Driving the Mode (Figure 9-1 from TCI6630K2L datasheet) to 000 (SLEEP). Later we would configure the BOOTMODE pins differently and then program the mode to SPI (011) and toggle RESETFULL to boot it. That doesn't always work, sometimes the K2L never drives RESETSTAT to 1. When it gets into this state, no type of reset (RESET, POR, or RESETFULL) can recover it. We have to power the board down completely and wait a short amount of time, ~10s. It's acts as if something in the K2L has latched-up. What could cause this type of behavior?

    Thanks,

    - Bryan
  • 0 in reply to Bryan Peterson
    TI__Mastermind 37500 points
    Hello Bryan,

    I think you can boot as if you are using UBOOT, and create a WAIT loop for a specific IO to change after IO Mux, PLL setup. In this manner the part has completly booted in SPI mode, (hopefully that works for you).

    If the GPIO test is done before releasing most of the IP LPSCs then you will be in a low power condition, waiting for the GPIO to indicate the Lamarr to software sequence.

    In your previous discussion the SLEEP mode of the Boot Mode, still wakes up part of the device. In the manner using UBOOT for this sequencing, you could just be in SPI boot. The boot up completes, the ARM software monitors the GPIO to complete the Lamarr sequence.
    Note: if you need to perform a shutdown with saved state information, that requires another sequence and GPIO, to store your required history, then used the LPSCs to turn off sections. Then place the master ARM processor back on the Wait for Interrupt, or do a complete shutdown.
    Regards,
    Joe Quintal
  • 0 in reply to Radio-Joe
    Prodigy 50 points
    Joe,

    That's not a bad idea. We're currently just letting it cycle in uboot, but as you suggest putting the GPIO check prior to fully booting into uboot should help save the extra power. I see about 3.5W difference with it being in sleep bootmode vs. uboot cycling, but your suggestion should help that.

    On the dsp getting into the locked up state I described previously - we do also see that when rebooting our main processor (with the K2L booted and running Linux for >15-20s). I've not been able to come with a solid reset sequence on our main processor to keep the DSP from getting into that locked-up state which requires a board power-down. Any ideas where to look would be helpful. I'm probably doing something wrong in the handling of the DSP reset, but the fact that the K2L gets into a state that requires a power-off is frustrating. I was wondering if that was something that had been seen before an understood how to avoid.

    Thanks,

    - Bryan
  • 0 in reply to Bryan Peterson
    TI__Mastermind 37500 points
    Hello Bryan,
    I assume you have used the TCI6630 or 66AK2L06 EVM. The documentation has the power sequence. The Keystone 2 Hardware Design Guide has a Core before IO, and an IO before Core style, see sprabv0 . I think the EVM uses Core before IO.

    I have not had this problem with the TCI6630K2L EVM.

    Regards,
    Joe Quintal
  • 0 in reply to Radio-Joe
    Prodigy 50 points
    Joe,

    I have not used the K2L EVM, but I have reviewed the schematics for the TCI6630K2L and based our design from that. We have a custom board design. I can get the K2L out of reset very time from a power on. It's future resets of the host processor (and K2L), where the K2L is reset from the host processor where I run into this problem. I don't believe it's a power up/on sequence issue - or the DSP wouldn't run the first time. I believe there is something else that is happening to the K2L when the host processor goes though reset and was hoping that that had been seen before.

    Bryan