Who and how wakes up CPU when BLE notification is received?

[Primož Kralj]

Ok, so please bear with me as I'm quite a greenhorn both in embedded world as in nRF series chips. My aim is to understand how deep sleep works. I might use wrong terminology too.

This is my current understanding:

I have one nRF chipset (does not matter which one specifically), let's call it chip Central which is bonded with another nRF, say chip Peripheral. Central is waiting for notifications on BLE service from Peripheral. In the meantime, it goes to deep sleep with sd_app_evt_wait() which calls underlying ARM's __WFI instruction.

Where it gets foggy:

Now, something from the outside world of CPU (radio circuitry?) on chip Central needs to listen all the time and when BLE signal is detected, it wakes up the CPU by turning on a pin which triggers CPU interrupt. Is this correct? But then "radio circuitry" runs all the time (or maybe in intervals?) and uses power?

I would also be glad for any hint on where to read up on this.

[Petter Myhre]

If you are in a connection it is actually the peripheral/slave that is listening for packets from the central/master. It doesn't need to listen all the time, because the master have a told the slave what connection interval to use. On every connection interval there is a connection event. RTC0 is used to keep track of when the master should transmit, and when the slave should listen. So every connection interval the master transmits a packet, and the slave listens and receives it. Then the master listens and the slave transmits a packet. One packet will be sent each way on every connection event(if the slave doesn't use slave latency). If there is no data to send, they will be empty.

If the slave has a notification to send, it will have to wait for the next connection event, then it receives a packet from the master, and then it sends the notification.

[Primož Kralj]

Excellent, I fully understand now. Thanks Petter.