• State TI Thinks Resolved
  • Locked Locked
  • Replies 15 replies
  • Answers 6 answers
  • Subscribers 35 subscribers
  • Views 643 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

AWRL6432: Deep sleep wakeup source enable

chianan chang
Intellectual 810 points
Part Number: AWRL6432
Other Parts Discussed in Thread: SYSCONFIG,

Hi

          We had a design need to have two pin  ( PADAN and PADAL) or ( PADAM and PADAL) input signal to wakup the Radar from deep sleep mode, how to enble it before enter deep sleep?

          (1)We had tried to let PADAM or PADAL  pinmux to SYNC_IN and enable the Radar enableGPIOSyncIOWakeupLPDS to be false to choose SYNC_IN , and it can work well to wakeup the Radar but if we let both PADAM and PADAL pinmux to SYNC_IN than nither PADAM nor PADAL can not wake up . Seems PINMUX can not let the same SYNC_IN to different PAD at the same time. 

          (2)We try the other way use PADAN and PADAL use PINMUX to WU_REQIN , the result is similar to use SYNC_IN.

         (3) We try to let PADAN PINMUX to WU_REQIN and PADAL pinmux to SPIA_CS1_N and enable Power_config.enableSPICSWakeupLPDS=true than PADAN can wakeup, but PADAL can not. Becaus eout system does not use SPI port, so we do not do MCSPI_init() and Drivers_mcspiOpen() . 

         Can you let me know how to let either PADAM or PADAL can wakup the radar from deep sleep? Is it possible that I use (3) method but just write some MCSPI register value than I can implement this function?

  • 0
    TI__Guru* 91206 points

    Dear Chianan - 

    Thanks for the post. 

    The pins available for use for wake-up interrupt are: 

    H10 = GPIO_2 = PADAL ==> in order to use this pin as an interruptible GPIO needed for wake source, you would need to configure this pin to mode 5

     

    For further detail, see page 1653 in the TRM https://www.ti.com/lit/ug/swru599/swru599.pdf 

    L12 = UARTA_TX = PADAN ==> in order to use this pin as an input needed for wake source, you would need to configure this pin to mode 4

    For further detail, see page 1072 in the TRM https://www.ti.com/lit/ug/swru599/swru599.pdf 

  • 0 in reply to Josh Wyatt
    Intellectual 810 points

    Dear Josh

    Thanks for your quick response, but the method you subject I already try it ( (2) of my original post) before and it doesn't work .

  • 0 in reply to Josh Wyatt
    TI__Expert 3430 points

    Hi Josh,

    I think the question is: Could several pads be set as WU_REQIN mode simultaneously? or there's only one pad can be set as WU_REQIN mode?
    It looks only one pad can be set as WU_REQIN mode from experiment.

    The SYNC_IN is also the same situation as WU_REQIN. (only one pad can work)

  • 0 in reply to James Austrial
    Intellectual 810 points

    Can you let me know how to let either PADAM or PADAL can wakup the radar from deep sleep? Is it possible that I use (3) method but just write some MCSPI register value than I can implement this function?

  • 0 in reply to chianan chang
    TI__Guru* 91206 points

    Chianan - 

    Please see my previous post and use the TRM instructions to configure the pins as you desire. PADAM = J11 and is not a wakeup source

  • 0 in reply to Josh Wyatt
    Prodigy 30 points

    Hi Josh,

    AM(J11) can be a wake up source by setting as SYNC_IN, we had evalated only this single pin was workable,

    AL(H10) can be a wake up source by settubg as "WU_REQIN", we had evalated only this single pin was workable,

    AM(J11) be SYNC_IN or AL(H10) be WU_REQIN can wake up radar separately,

    but we want to use both pin at the same time, Sysconfig does not allow to set multiple pins with 2 pins to be SYNC_IN & WU_REQIN at the same time.

    We do evaluating by hard coding,

    SYNC_IN and WU_REQIN seems both are GPIO wake-up sources, and seem not able to be used at the same time.(in our evaluation)

    Technical reference doesn't decribe more detail about this. if so, we need to change current design of these 2 pins. one pin to be assign to SPIA_CS0 or anything can be.

  • 0 in reply to Brian Ho
    TI__Guru* 91206 points

    In looking at the datasheet for this device, you are right about J11 being SYNC_IN

    and the wakeup is a OR situation. 

    (from page 220)

    and there is a mux selection register, page 223/224

    perhaps if you have two sources you want to leverage for wakeup - you should OR them into one of the possible choices available. 

    Here are 11 parts from TI that are auto rated. 

    https://www.ti.com/logic-voltage-translation/logic-gates/or-gates/products.html#1498=Automotive& and there are 84 total on ti.com to choose from. 

  • 0 in reply to Josh Wyatt
    TI__Expert 3430 points

    Hi Josh,

    User need to know who wakeup the system between these two wakeup resources.

    So, the OR gate can't achieve the design goal...

  • 0 in reply to James Austrial
    TI__Guru* 91206 points

    James - 

    What are you using for sources? Perhaps if you shared with us the idea or concept of (simple block diagram may suffice) what you are thinking, that may help us guide you further with a logical solution to your design issue. 

  • 0 in reply to Josh Wyatt
    TI__Expert 3430 points

    Hi Josh,

    Let's assume there're two external systems from AWRL6432 point of view: One is G-sensor system and the other one is Camera system.

    Either G-sensor system or Camera system can wake up AWRL6432.

    AWRL6432 needs to know who wake it up: Could be from G-sensor or from Camera, of course, it's also possible that G-sensor and Camera wake up AWRL6432 at the same time (I assume it's rare but still possible). 

    AWRL6432, G-sensor, Camera, these 3 system are all independent.

    The diagram is like below:

       

  • 0 in reply to James Austrial
    TI__Guru* 91206 points

    James - 

    Thanks for the high level diagram. The simplest implementation that comes to mind here would be to OR those two logic level IRQs (assuming that is what they are) together as previously suggested, to trigger the wakeup and tie each of them to individual open GPIOs as well, which would be read after the wakeup IRQ for level change. This would work if the IRQs were latched by the source, but if they were not (just a pulse), then you could arrange a simple latch for each of them, like this: 

  • 0 in reply to Josh Wyatt
    Intellectual 810 points

    In the real situation, Radar is an I2C slave , Camera is I2C Master ( one of the wake up source to Rada, use PADAN and PADAM for SCL and SDA ), There is an G sensor interrupt connect to PADAL( the second source need to wake up radar ). When Radar is wakup, it need to know the wakeup source is come from Camera or G sensor. So use external Gate to or G sensor int and one of the I2C is not possible, it will let the I2C BUS will be interference by G sensor int when Camera is communicate with Radar by I2C, and it also can not let Radar know who wake him up. 

  • 0 in reply to chianan chang
    TI__Guru* 91206 points

    Chianan - 

    If you are using those pins as dedicated I2C SDA and SCL, then they will have pullup resistors and you won't be to use them. If you want to provide an actual diagram of what you are intending, and any other caveats that you have for your system, we can attempt to help you further. 

  • 0 in reply to Josh Wyatt
    TI__Expert 3430 points

    Josh,

    Send you the schematic offline via E-Mail

  • 0 in reply to James Austrial
    TI__Guru* 91206 points

    James- 

    Thanks -closing this post as we moved it to email.