MSP432E401Y: MSP432E401Y

Hi,

  I see problem with your below line. You have both wake low and wake high. You cannot wake on both states.

MAP_GPIOPadConfigSet(GPIO_PORTA_BASE, GPIO_INT_PIN_2, GPIO_STRENGTH_2MA, (GPIO_PIN_TYPE_WAKE_LOW | GPIO_PIN_TYPE_WAKE_HIGH));

 If you want the PA2 pin to wake the device when it is low then you should change to:

GPIOPadConfigSet(GPIO_PORTA_BASE, GPIO_PIN_2, GPIO_STRENGTH_2MA,
(GPIO_PIN_TYPE_WAKE_LOW | GPIO_PIN_TYPE_STD_WPU));

Hi Charles,

I did further debugging. It seems, in the above scenario, the system is NOT Rebooting.

It seems to WAKE UP from HIBERNATE with HIBERNATE_INT_PIN_WAKE status.

Infact, I did not set HIBERNATE_WAKE_PIN.

I am doing "HibernateWakeSet (HIBERNATE_WAKE_GPIO)". But even then, the system immediatly WAKEs UP from Hibernate as  HIBERNATE_INT_PIN_WAKE.

Since I did not check for " HIBERNATE_INT_PIN_WAKE" status earlier, I thought the system is rebooting. My bad. 

This problem is similare to the below one.

https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/841688/msp432e411y-unexpected-gpio_wake-immediately-after-entering-hibernate-mode

But the solution suggested in that issue (HibernateIntClear(ui32Status)) is NOT working to me.

Thanks

Hi,

  How is your WAKEn pin connected? Do you have a pullup on this pin? Here is a reference design for WAKEn pin. See below. 

  Can you repeat the same problem if you run your code on the LaunchPad?

  Can you repeat the same problem on your custom board if run the stock example at C:\ti\simplelink_msp432e4_sdk_4_20_00_12\examples\nortos\MSP_EXP432E401Y\driverlib\hibernate?

Thanks Charles,

When testing using the SDL sample application you mentioned in out board, I still get the same problem (WAKE_PIN). So, when I issue "hib" command to put the device to HIBERNATE, it WAKEs up immediatly with "WAKE_PIN" message (HIBERNATE_INT_PIN_WAKE status).

I will get the details about the connection of WAKE pin from our hardware team (they are from German). In the meanwhile, is there any way to disable/configure the WAKE_PIN to make it work as needed.

Hi,

Shriganesh Shenbagamoorthy said:

When testing using the SDL sample application you mentioned in out board, I still get the same problem (WAKE_PIN). So, when I issue "hib" command to put the device to HIBERNATE, it WAKEs up immediatly with "WAKE_PIN" message (HIBERNATE_INT_PIN_WAKE status).

What if you run the same example on the LaunchPad board?

I wanted to add an exchange we had via email. Let's continue the discussion from here:

Based on the below information, it seems, the WAKEn pin is not connected to any pullup in our schematic.

 Charles: How is the WAKEn connected on your board right now? If you do not plan to use WAKEn pin as a wake source, can you do an experiment by simply just tie it to VDD. I understand that in your code you did not specify WAKEn as one of the wake sources but nonetheless the device is woken from it.

Is there any alternate to option to use the hibernate wake up based on GPIO without considering WAKEn pin connection.

 Charles: It is the code that I pasted in the forum to use GPIO for wake source.

As said earlier, HibernateWakeSet () API is called with only HIBERNATE_WAKE_GPIO. We are not providing HIBERNATE_WAKE_PIN as argument here . We hope only HIBERNATE_INT_GPIO_WAKE triggers WAKE from HIBERNATE (not HIBERNATE_INT_PIN_WAKE).

Charles: When I run the SDK example code on the LaunchPad, I do not get a wakeup from WAKEn pin. This is why I suggested to pull WAKEn high as an experiment on your board.

I am thinking of doing something like, configure a interrupt handler for HIBERNATE_INT_PIN_WAKE and put the unit back to HIBERNATE. But not sure will that work. Unfortunately, if this makes the system in a endless loop of WAKE and HIBERNATE calls happening consecutively, there won’t be any power saving happen here.

 Charles: If you resolve the hardware issue then I think it will work to use WAKEn as a wake source. If your WAKEn is tied to GND, then it will immediately wake up the device after you assert HIBn.

We are also internally discussing how to handle this situation like to have a periodic RTC hibernation mechanism and poll the specific GPIO to wake up. Again, this will consume more power than using proper way.

 Charles: I thought you already got RTC working as a wake source. In the SDK example, the RTC is configured to wake after 5 seconds. Have you tried the example?

The RTC based Hibernate/Wake works as expected. And hardware mod is not an option (design is finalized and ready for manufacturing).

Charles: You said that you ran the stock SDK example and it will immediately wake up. On the contrary, I ran the same example on a LaunchPad and I do not have an issue. This indicates a hardware difference, particularly on the way the WAKEn is connected. Please try to run either your own code or the stock example on a LaunchPad for comparison. I understand it is undesired to change the board design. But at least, please do experiment to tie WAKEn to VDD to confirm if it resolves the issue when running either the stock example and your own application. We need to understand the root cause before we know if board needs to modify or not.   

So, what I mentioned was to use RTC based hibernate to wake periodically (say, once every minutes) and check the necessary GPIO pin’s status. If needed go back to Hibernate mode. Otherwise, continue working.

 Charles: I don’t see an issue with such a setup. This is mainly what the stock example is doing – go into hibernate and wake after five seconds. When the device is awake, it is in full running state, you can check GPIO pin’s status or other tasks.

Before doing that, I was checking whether is there any other simple option.