I got your point now.

Yes, I agree with you. the ISR fired with below code:

void GPIO_ODD_IRQHandler(void) 
{
  // Clear all odd pin interrupt flags
  GPIO_IntClear(0xAAAA);

  // Toggle LED01
  GPIO_PinOutToggle(BSP_GPIO_LED1_PORT, BSP_GPIO_LED1_PIN);
}

void initGPIO(void) 
{
  // Configure GPIO pins
  CMU_ClockEnable(cmuClock_GPIO, true);

  // Configure PB0 and PB1 as input with glitch filter enabled
  GPIO_PinModeSet(gpioPortE, 13, gpioModeInputPullFilter, 0);
  GPIO_PinModeSet(gpioPortE, 12, gpioModeInputPullFilter, 1);
  GPIO_ExtIntConfig(gpioPortE, 12,13, 1, 1, true);
  // Enable IRQ for odd numbered GPIO pins
  NVIC_EnableIRQ(GPIO_ODD_IRQn);

  // Enable falling-edge interrupts for PB pins
  GPIO_ExtIntConfig(gpioPortE, 13,13, 1, 1, true);

}

Picture to help detail an example scenario.

I am still wondering if I understand your requirement correctly or not.

My understanding is:

1. you need to determine if the debugger is connected, because you need to enter EM2, if you use the 'debug' button of Simplicity Studio to start the debug your firmware, this would not allow the EFM32GG to enter real EM2. after you call EM2 in your firmware the device in fact will not execute code any more (the device enter EM2), but some clock remain active, so the power consumption is high.

2. That's the reason you want to have a workaround. use the watchdog to reset the device.

a. the firmware determine if debugger connected , if connected, you force a watchdog reset.

b. if debugger was not connected. you configure the watchdog and feed it normally.

c. you need some RAM or register to different these 2 reset (you write value before watchdog fire in your code). the content of the RAM (or other) need unchanged after watchdog reset.

I don't encourage you implement this, but you may take a look at below KBA, see if it works (determine debugger connect) and try if you could have other options/solution to enter real EM2.

https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2018/10/02/debugger_detectionu-Jk6S.html

I am still wondering if I understand your requirement correctly or not.

My understanding is:

1. you need to determine if the debugger is connected, because you need to enter EM2, if you use the 'debug' button of Simplicity Studio to start the debug your firmware, this would not allow the EFM32GG to enter real EM2. after you call EM2 in your firmware the device in fact will not execute code any more (the device enter EM2), but some clock remain active, so the power consumption is high.

2. That's the reason you want to have a workaround. use the watchdog to reset the device.

a. the firmware determine if debugger connected , if connected, you force a watchdog reset.

b. if debugger was not connected. you configure the watchdog and feed it normally.

c. you need some RAM or register to different these 2 reset (you write value before watchdog fire in your code). the content of the RAM (or other) need unchanged after watchdog reset.

I don't encourage you implement this, but you may take a look at below KBA, see if it works (determine debugger connect) and try if you could have other options/solution to enter real EM2.

https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2018/10/02/debugger_detectionu-Jk6S.html

I am still wondering if I understand your requirement correctly or not.

My understanding is:

1. you need to determine if the debugger is connected, because you need to enter EM2, if you use the 'debug' button of Simplicity Studio to start the debug your firmware, this would not allow the EFM32GG to enter real EM2. after you call EM2 in your firmware the device in fact will not execute code any more (the device enter EM2), but some clock remain active, so the power consumption is high.

2. That's the reason you want to have a workaround. use the watchdog to reset the device.

a. the firmware determine if debugger connected , if connected, you force a watchdog reset.

b. if debugger was not connected. you configure the watchdog and feed it normally.

I don't encourage you implement this, but you may take a look at below KBA, see if it works (determine debugger connect) and try if you could have other options/solution to enter real EM2.

https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2018/10/02/debugger_detectionu-Jk6S.html

have you defined the "USB_CORECLK_HFRCO"?

have you defined the "USB_CORECLK_HFRCO"?

have you defined the "USB_CORECLK_HFRCO"?

Hello Davide, your understanding of message queues is correct.

We usually allocate the message in the calling task stack.

See the following examples at:

C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.7\app\micrium_os_example\kernel\ex_kernel_q.c

https://doc.micrium.com/display/OSUM50800/Using+Message+Queues

i guess you are using the EFM32TG device (not EFM32TG11).

https://www.silabs.com/mcu/32-bit

I have followed the example for Pearl Gecko kit and have used the config-sl-crypto-all-acceleration.h config file to enable the hardware crypto  engine. i am using the EC private key generated by the openssl tool.

AFAIK, EFM32TG only has AES peripheral and could not accelerate the ECDSA.