What is your BOD threshold setting? Do you have proper bypass capacitors?
BOD is default, 1.8V.
Capacitors? I have on DVDDs, and on DEVDDs, also on EVDD and on AVDD.
Going to be battery powered, so no large capacitor on the powerline. Do you think I supposed to apply one for the USB case?
Thanks!
I think you are fine, but just in case, check power lines with the oscilloscope. It is possible that you are doing something bad with GPIOs on wake up. Like shorting two outputs, or something similar.
It is also possible that reset reason is incorrect, however, I used this function a lot and it never failed.
Try to disable BOD. If you have problems with power supply, then device is most likely to reset, but reset reason will be different.
Will try disabling it soon.This solved the continuous resets
It is possible that you are doing something bad with GPIOs on wake up.
How can I control what to do on these kind of wakeups?
In theory, only the stack checks something, and goes back to sleep asap. In my understanding.
So basically I have no chance to control anything after this wakeup I guess.
It would be interesting to see where execution gets after the wake up. It is possible that something in the hardware misconfigured in a way that conflicts with sleep. I'm not sure if it is even possible, just a thought. May be a way some peripherals are connected and configured. Can you post MCU-related part of the schematic?
Yes, it's here for some time:
That looks fine to me. I'd check all power supply rails with the scope anyway, just in case.
Hello!
Thank you, I'm proceeding now at least.
But now I got some issue again, after sleeping goes fine, I'm trying to wake it up again (on ISR).
I have an ISR routine with HAL_RegisterIrq.
In the IRQ handler I call
SYS_PostTask(BSP_TASK_ID);This should make the state machine run, right? Power consumption not increasing when raising this INT, so I believe state machine doesn't start for somewhy.
(Consumption only increase after 1minute which is exactly CS_END_DEVICE_SLEEP_PERIOD.)
What IRQ and other parameters do you use in HAL_RegisterIrq?
Also, you are posing BSP task. It will wake up the MCU, but application task will not run, of course.
Yes, I know, it's okay:
IRQ reg:
HAL_RegisterIrq(INT4, IRQ_FALLING_EDGE, IRQ_Handler);BSP's handler after getting its task, will call an application function named "appButtonPressed".
In this function I call HAL_OpenI2cPacket which would change the LCD display data, but in this case, LCD data is not changing at all before CS_END_DEVICE_SLEEP_PERIOD.
So there could be 2 cases:
1.) BSP's task handler is not getting called after SYS_PostTask.
2.) BSP's task handler called, but HAL_OpenI2cPacket won't run for some other reasons which I'm not yet aware of.
Anyway it's an interesting extra info, that I also have "appWakeup" in "appButtonPressed" which basically:
void appWakeup() {
appState = WAKEUP;
SYS_PostTask(APL_TASK_ID);
}
...
case WAKEUP:
zdoWakeUpReq.ZDO_WakeUpConf = appZdoWakeUpConf;
ZDO_WakeUpReq(&zdoWakeUpReq);
break;
...
static void appZdoWakeUpConf(ZDO_WakeUpConf_t *confirmInfo) {
if (ZDO_SUCCESS_STATUS == confirmInfo->status)
{
appState = APP_IN_NETWORK_STATE;
appPostGlobalTask();
}
else
{
appWakeUp();
}
}
So I'd totally assume that not just the SM but also the radio should be waking up for these combination
The system can only wake up on level from INT 4-7. See Table 12-1 in the datasheet. And specifically note 3 after the table.
what a silly amateur mistake of mine... thanks.
I'm handling a rotary encoder with INT4 and INT5 which needed EDGE interrupts, I'm gonna deepdive to see how do they work with only level INTs.
There are so many things to take care of when going on battery!
Given that the only supported level is low, it may be hard or impossible. Those hardware interrupts are annoying. Pin change interrupts work way better.
You must definitely be right, yes.
Anyway I'd need to redesign this board for sure. There are too many hackish solutions now, not just this level INTS but also buttons with WDT which is far not that good either.
Thank you very much Alexru,
Merry Xmas to all forum readers!
Hello again!
I'm back with a brand new, redesigned PCB, which has its buttons connected to the INT pins, and its rotary to the INT2-3, which is able to wakeup the MCU from sleep even on edge interrupt.
I also reverted all the hackish code parts with watchdog, and timers, so now I should have a fully functioning sleeping device.
But my observations shows something else:
1.) If I use SYS_EnableSleepWhenIdle() the device simply doesn't sleep. (consumes 15.3mA @3.3V)
2.) If I try to sleep it manually (ZDO_SleepReq without sleepwhenidle), it goes into sleep (less than 0.5mA @3.3V), this is what I wanted
, but after a few seconds (usually 2-4) it resets.
I'm investigating now the cause of reset.
But it's very interesting that sleepwhenidle is simply not working. What could prevent that? I have only long-lasting timers (10 sec, 1 minute) - for testing, they will be increased to 10 - 20 minutes later.
I'd expect that in this case, sleepwhenidle should sleep for 9 seconds than wake up for the timer @10s, do its stuff, and go back to sleep until the next 10s. Am I wrong?
Thanks!
Cheers
Stack has its own timers, some of them are pretty fast. Sleep when idle reduces average power consumption, but current consumption is very pulsed, so multimeter may get confused. I recommend powering device though a small (1-10 Ohm) resistor and measure a voltage drop across this resistor with an oscilloscope.
It is also possible that device is actually awake because of something else going on. I would check that pending task mask is 0 at some point and sleep is actually requested. This all should be located in the open part of the stack.
Sleep When Idle is not a replacement for full sleep, it is an attempt to reduce power consumption of an active device.
Also, I don't think that sleep when idle disables the radio, since it needs to be able to wake up on the radio interrupt. But I may be wrong here.
Thanks for these valuable infos, ataradov!
Anyway, I chosed managing the power manually. It's more exact.
So I did some further tests, which is interesting:
1.) After configuring the sleep and wakeup calls, I uploaded the firmware onto xplainedpro, and it can sleep tight. On pressing its button (PE4, INT4) it 'wakes' up, executes the ISR, and goes back to sleep (I have one button on the same pin, so no firmware mod was needed). If I call ZDO_WakeUpReq, the whole stack comes back awake. This whole process is definitely measureable with a multimeter: 15-16mA awake, 1-2mA sleep. (Just wanted to show you that my firmware shouldn't do anything harmful, it can sleep qutie well).
This is great, I believe that this firmware is getting to the point.
2.) However, afterwards, I uploaded the exact same fw to my board: after going to sleep, it resets in 2-3 seconds. Going to sleep works great. It happens exactly the same time on my board and on the xplainedpro. However, for some reason, my board gets rebooted every time after sleep. I think I don't have watchdog enabled on my board (fuses: E:FE, H:99, L:EF). Also, reset is not scheduled exactly. Sometimes it needs 0.5s, and sometimes it takes 3 seconds. But it surely reset.
Now, the thing is that since this doesn't happen on the xplained, I nee to have some issue on my board. It has some external circuits of course, but none of them should raise a reset.
I'll check the reset reason, and post it here.
So, very interesting: HAL_ReadResetReason() returns 0x04 which is BROWN_OUT_RESET.
I had this before. But now I checked the power line with a scope, and nothing happens on the powerline. Not a small glitch. I can disable BOD for sure, but what causes it to fire when the chip is sleeping?
And what is much more interesting, why is that not happening on the xplained? (its fuses: E:FE, H:91, L:F7)
Why do you have different fuses between the boards? Are you sure they don't set different BOD levels, for example? I would use AS to generate fuse values you want.
BOD levels are set through EFUSE0..2, which was set to the same for both boards.
Other differences was the EESAVE (preserve eeprom on erasing) and one board was set to fast rising power, while the other is set to slow rising one.
fast rising power 16K CK 14CK + 4.1 ms,
slowly rising power 16K CK 14CK + 65 ms
I think they shouldn't do anything bad with BOD
But you are absolutely right that setting them to exactly same should normally decrease possible faults.
Hello,
I've got two new questions. (should I use a new thread? they both belong here technically)
1. What is the required behaviour after CS_SLEEP_PERIOD on EDs? Do they have to call ZdoWakeUpReq for the stack to sync with the C, or I can use ZdoSleepReq immediately?
2. My device needs to wakeup after x minutes, where x varies by time. My intention is to set CS_SLEEP_PERIOD to 60000, and on each iteration I'll be able to decide eiter going back to sleep, or waking up.
Is this the right approach here?
Thanks!
1. What is the required behaviour after CS_SLEEP_PERIOD on EDs? Do they have to call ZdoWakeUpReq for the stack to sync with the C, or I can use ZdoSleepReq immediately?
You need to make sure that ED checks in at least every CS_SLEEP_PERIOD ms. You can either just do it on CS_SLEEP_PERIOD intervals, or you can keep track of time since the last check in, and then do noting on CS_SLEEP_PERIOD. The idea here is to make sure that parent does not think that device has left for good and does not free the corresponding entry.
2. My device needs to wakeup after x minutes, where x varies by time. My intention is to set CS_SLEEP_PERIOD to 60000, and on each iteration I'll be able to decide eiter going back to sleep, or waking up.
Is this the right approach here?
Yes, as long as parent has the same sleep interval set.
Thanks!
One point is missing:
ED checks in
If ED is sleeping (no HW INTs are coming) how can it check in? After CS_SLEEP_PERIOD I need to call ZdoWakeUpReq, and send a message to C?
(I understand the basic idea, but don't know if stack does the checkin behind the walls after CS_SLEEP_PERIOD.)Sorry. You've already explained this.
"3. CS_SLEEP_PERIOD - the whole stack and radio wakes up and sends the poll request."
So I'd reverse my question.
What is the most efficient way to wake up the MCU without radio in every minute? (I'd like to have a sleeping ED, which wakes up periodically, but does rare radio transmission to preserve battery. In this case I'd set CS_SLEEP_PERIOD to a higher number like 30*60*1000).
Thank you!
What is the most efficient way to wake up the MCU without radio in every minute? (I'd like to have a sleeping ED, which wakes up periodically, but does rare radio transmission to preserve battery. In this case I'd set CS_SLEEP_PERIOD to a higher number like 30*60*1000).
There is a way to completely disable automatic checkins. I think you need to use 0 or something like that.
The thing to keep in mind is that you need to set appropriate value on the coordinator. It needs to reflect actual check in period. Although if you don't mind that devices sit in tables for a long time, then even that does not matter.
Yes. that's cool, I can set 0 for that, but in that case, what would wake up the MCU from sleep?
(I think only HW INTs can do that. Shall I use watchdog INT for this purpose?)
Oh, and one more thing.
After HW interrupt (button press), the MCU wakes up. How can I send it back to sleep? (On ZDO_SleepReq, it returns with code 128 which is ZDO_INVALID_REQUEST_STATUS.)
Yes. that's cool, I can set 0 for that, but in that case, what would wake up the MCU from sleep? (I think only HW INTs can do that. Shall I use watchdog INT for this purpose?)
That's more for a case when you know that external events happen at a certain rate. Let's say you have a motion detection sensor, so you know that there is going to be at least one event per day, or something like that. If you don't sure, then just leave a really long wake up time.
Oh, and one more thing.
After HW interrupt (button press), the MCU wakes up. How can I send it back to sleep?
Use SYS_Sleep(). ZDO returns ZDO_INVALID_REQUEST_STATUS because it thinks that it is already sleeping