In SI446X(SI4463) wake on radio applications, the RFChip will send out interrupts when received waked packets from the master devices.
In a very little possibility, the MCU (Our MCU is EFM32G210) may miss the interrupts from the SI446X, hence the SI446X chip will not in sleep mode and waiting for the MCU to get read out the packet, and the MCU miss the interrupt and still keep in sleep mode.
Then the battery may quickly brown out in serveral days.
Because it is hard to catch the case the MCU missing the interrupt, when we found one client device can never be waked up, the battery voltage is about zero!
To prevent the RFChip enter idle status we set the status as followings:
If the RFChip works well, then there is no way to enter idle status or keep in RX status to dry out the battery.
But to our surprise there is very little possibility that some nodes may quickly dry out the battery in serveral days. There is no master device sending packets while some nodes may dry out the battery.
We think that the following reason may cause this exception:
(1) The SI446X chip may received a noise or disturbing signal and then exit the sleep status
(2) The SI446X chip switch to idle or Rx status, then the current consumption will be about 13mA
(3) The SI446X chip wait for the MCU to issue comamnds to re-enter sleep status, but the MCU is also in sleep status
Then how to design the mechanism to quickly detect the SI446X chip exit sleep status?
We found if the SI446X chip enters wake on radio mode, it will switch between sleep and RX status, then if we set one GPIO (0/1/2/3) to indicate status, then there will be one pulse output from the GPIO (0/1/2/3).
This pulse may be used as the feed signal for a watchdog timer, if the SI446X chip exit the sleep status and keep in one steady status, such as IDLE or RX status, the the pulse will disappear!
But an external watchdog chip is requied in this mechanism, the internal watchdog timer of the MCU (EFM32G210) can only monitor the software stalemate. It can not monitor the GPIO pulse, especially in sleep status.
Then my question is:
(1) Is there any other mechanism to detect SI446X chip status? it should switch between RX and sleep periodically
(2) If an watchdog timer is required anyway, is it possible to setup another one by the internal TIMER, RTC or LETIMER to function as an external hardware watchdog chip.
If you need any further information please let me informed!
Thanks & Best Regards!
Using internal status signals (RX_STATE, RX_DATA, WUT, SYNC_WORD_DETECT) on GPIOs you can observe what causes the excessive RX periods.
If you see too many packet detection on noise, you should use longer preamble or sync to make false detection less likely.
I recommend to set level sensitive interrupt on the host MCU. NIRQ won't go back to HIGH until the PEND bits are cleared by the host MCU. I suppose it won't take days to finally service the interrupt.
For RXTIMEOUT_STATE we recommend to set NOCHANGE, otherwise the preamble detection timeout will stop the RX period instead of the wakeup timer (if the timeout is the shorter).
In may system the LDC+DSA is enabled, so the RX_TIMEOUT_STATE should be SLEEP, is it right?
I have ever post one question about the sleep with wakeup. you told me that how to configure the state of the modem.
So I set the STATE1_RXTIMEOUT_STATE_ENUM_SLEEP is a correct settings, isn't it right?
With Best Regards.
Original Case Details:
I did set the GPIO0 for SYNC_WORD detect to prevent NIRQ missing. It did work well to wakeup the MCU even if the nIRQ is in LOW status.
This GPIO will send out several pulse to wakeup the MCU even if the MCU missed last nIRQ interrupt.
But there is still a little possibility of the low power device to dry out the battery in several days.
We think there are the following reasons to let the system NOT in low power status
(1) CASE-1: The MCU failed to enter sleep status. We use function EMU_EnterEM2 or EMU_EnterEM3 to enter sleep status in a while(1) loop, This funciton may not work well?
(2) CASE-2: The SI4463 failed to enter sleep status by SPI command
(3) CASE-3: The SI4463 enters sleep status successfully, but later it waked up quietly by some noise and send NO intererupts to wakeup the MCU
Below is a analasis of the cases list above:
(1) CASE-1：The funciton EMU_EnterEM2 or EMU_EnterEM3 is put in the while (1) loop. If it failed one time, other functions will be called and then go to the beginning of this loop and call the functions EMU_EnterEM2 or EMU_EnterEM3 again.
(2) CASE-2: We have set the GPIO1 to indicate the SI4463 Sleep/Active status (GPIO Mode=28d=0X1C). After we issue command to let the SI4463 to entered sleep status. The GPIO1 will becomes LOW in 1ms. If the MCU checked this GPIO status in sleep status, then let the MCU enter sleep status by command EMU_EnterEM2 or EMU_EnterEM3. otherwise it will retry for at least 8 times with an interval of 3ms between each SPI command.
(3) CASE-3: The function ezradio_start_rx have 3 parameter to define the SI4463 status. We can NOT make sure the correct parameters can never deadlock the SI4463 in NONE sleep status(such as IDLE or RX status) . If it happed, this MCU can never be wakedup and the SI4463 will dry the battery out quickly.
So my quesiton is:
(Q1) In sleep status with LDC +DSA, The correct configure for SI4463 is
(Q2) With the correct configure for SI4463, the modem will never be deadlocked to enter IDLE or RX status without interrupt notice to wakeup the MCU.
(Q3) If the answer to (Q2) is NOT positive, then a watchdog timer to monitor the GPIO1 may be required as described in another post?
If you need any further question, please let me informed!
Thanks & Best Regards.
Yes, right. For LDC+DSA the RX_TIMEOUT_STATE should be SLEEP.
My previous recommendation of NOCHANGE was for LDC without DSA.
If you want the radio to go back to sleep in every case and not wait in READY or RX state for the MCU to react, you should set also the RXINVALID_STATE to SLEEP state. This way the WUT will wake up the radio regularly but it will always go back to sleep.
I recommended to use the status signals to observe and debug what is happening in the radio and not to replace NIRQ with them. If you understand how NIRQ works, you can use it reliably. NIRQ is LOW when any of the PEND bits of the enabled interrupts are active. It is advised to handle in the MCU the NIRQ as level sensitive interrupt, so it will generate interrupt in the MCU again and again until the MCU clears all the enabled PEND bits.
Regardless of how well is your application working, generally it is advised to regularly reinitialize the radio with a cycle time allowed by the use case, to prevent any unexpected external disturbance.
You mentioned in your last post:
"If you understand how NIRQ works, you can use it reliably. NIRQ is LOW when any of the PEND bits of the enabled interrupts are active. It is advised to handle in the MCU the NIRQ as level sensitive interrupt, so it will generate interrupt in the MCU again and again until the MCU clears all the enabled PEND bits."
In fact we have expected the EFM32G210 and EZR32LG230F128R63G to support the level sensitive interupts YEARS ago.
If the ARM MCU supports level sensitive trgger interrupts, the nIRQ pin is enough and the watchdog timer is no longer needed to monitor the GPIO1 status(Active/Sleep status indicator of the Radio).
But we found that only the 8051/C8051 processor supports level and edge trigger interrupts.
The ARM cortex M3 CPU only suuports edge trigger interrupts and do NOT suuport level trigger interrupts.
Below is the copied information from the reference mannual of the EFM32G series ( the same as the EFM32LG series )
• 2 interrupt lines from up to 16 pending sources
• All GPIO pins are selectable
• Separate enable, status, set and clear registers
• Asynchronous sensing
• Rising, falling or both edges
• Wake up from EM0-EM3
• Peripheral Reflex System producer
• All GPIO pins are selectable
• Configuration lock functionality to avoid accidental changes
If you believe that the EFM32G210 and EFM32LG230(i.e. EZR32LG230F128R63G) support level sensitive trigger interrupts, would you please give out the detailed steps for configuration?
(Q1) Does the EFM32G210 and EFM32LG230(i.e. EZR32LG230F128R63G) supports LEVEL sensitive trigger interrupts?
(Q2) If the answer for (Q1) is YES, then how to configure it with API or registers?
If you need any further information, please let me informed!
Thanks & Best Regards.
My answer about NIRQ typical use case was from radio standpoint. You have to take into account the interrupt capabilities on the MCU side. If you need help with that, our MCU forum is a better place for that. (I can confirm I don't see level sensitive GPIO interrupt option in the EZR32LG ref manual.)
I did post this quesiton in the MCU forum:
The answer to this quesiton is also negative!
Thanks & Best Regards for your kindly support!
No problem. I believe you will solve this issue also with the edge triggered interrupt.