software arch and sleep modes

4 posts / 0 new
Last post
mohit3112
Offline
Last seen:8 months 1 week ago
Expert
Joined:2014-08-04 13:45
software arch and sleep modes

Hi , A have a specific architectural question , According to the documents provided for da14850
if da14580 is in extended sleep mode it can be woken up by either of the two :
1 ble core interrupts .
2 external wakeup timer interrupt.

我现在在我的代码设置da14580扩展sleep mode so after that it can be either woken up by external sensor interrupts (every 20ms ) or by internal BLE core interrupts (for ble tx and rx events)

I have following doubts
1 . if da is already woken up by BLE core, before the external sensor interrupt came will wakeup interrupt handler run immediately on firing of external interrupts or it will run when da14580 goes back to ext sleep again ?
2 . after system is woken up by the external interrupt some processing will be done on the data before sensor goes to ext _sleep mode again if this processing takes a long time will the rx and tx event of BLE core get affected ?
3 . how can i synchronise the processing done on reception of external interrupt with BLE core interrupt so i do not end up interfering with the BLE core events.

If you can point me to some example code or application note for it that will be really useful

Thanks
Mohit

Device:
MT_dialog
Offline
Last seen:1 month 2 days ago
Staff
Joined:2015-06-08 11:34
Hi mohit3112,

Hi mohit3112,

1. If the 580 is allready awake and the BLE core is on and the external interrupt hits, the interrupt handler will be executed immidiatelly it wont go sleep in order to wake up again. The wake up controller is operational even when the 580 doesn't sleep.

2. If your device is awaken by an external interrupt that means that your system isn't going to be on a connected state, so there isn't any timing constrain in order to keep a connection. The Tx and Rx you are worring about, are the advertising intervals i suppose. Yes if you stall the 580 in any of the hooks, the app_ble_on_powered for instance and you dont schedule the pending events you will miss the proper intervals and you will send another advertising as soon as the proccessing has completed and the rwip_schedule() gets called.

3. If you are worried that perhaps the proccessing will take much longer and you will miss the BLE event you should make sure that you schedule the pending events, for example an idea would be to make the processing in the app_on_ble_powered hook and break the long procedure into smaller ones in order to return KEEP_POWERED every time a smaller procedure ends and eventually the rwip_schedule() function to be called. You can have a look at the AN-B-006 document and check the available hooks.

Thanks MT_dialog

mohit3112
Offline
Last seen:8 months 1 week ago
Expert
Joined:2014-08-04 13:45
hi thanks for your reply it's

hi thanks for your reply it's really helpful
in your second answer you said that if device is awaken by external interrupts that means system is not in connected state but it's not quite the case , in connected state also i am waking up the device by external interrupts.
according to what i understood reading documents is that device can be in extended sleep mode and connected also , in this case it can be waken up by either by connection events or by external interrupts so every time there is connection event or external interrupt device will wake up and then it can go to extended sleep mode again.
did i miss something ?
also i am using sdk 3.0.10.1

Thanks
Mohit Maheshwari

MT_dialog
Offline
Last seen:1 month 2 days ago
Staff
Joined:2015-06-08 11:34
Hi mohit3112,

Hi mohit3112,

I misunderstood the operation you want to accomplish, i thought that your system is awaken only by an external interrupt and by the time it is awake there is no BLE activity. Yes you can be in extended sleep and connected and wake up via external interrupts, so that the device can wake up either due to a BLE connection event or an external event.

Thanks MT_dialog