Hi,
We have the following setup:
Our device is a BLE peripheral which is an external MCU connected over UART to DA14580. The GATT database (services and characteristics), the advertisement data and any other events are received from the MCU to DA14580 over UART and then DA14580 starts advertisement. Similarly, once connected, for read and write requests from central, the DA14580 sends requests to the MCU and when MCU responds DA14580 sends the same to the central.
Now, we intend to use extended sleep mode on DA14580.
As per my understanding,
1.The following should be set first:
const static sleep_state_t app_default_sleep_mode = ARCH_EXT_SLEEP_ON;
2. Then in app_on_system_powered callback, if GOTO_SLEEP is returned then the DA14580 will go in extended sleep. If KEEP_POWERED is returned throughout then enabling extended sleep (from 1. above) will have no effect. Is this right?
Now, how do I use extended sleep such that, all my UART requests from the MCU are handled by DA14580. Along with that, all the BLE related requests from the central device are also handled by DA14580?
Does the DA14580 when in extended sleep wake up on:
1.从单片机UART请求。
2. BLE interrupt (read/write request from central)
The following is my sequence. Please let me know where can I put DA14580 to sleep and how to wake it up:
1.MCU sends GATT database over UART
2. MCU sends advertisement and scan response data over UART
3.DA14580 starts advertising
-----
Case A:
4. In case of BLE connection, read or write request is received by DA14580 and it forwards it to the MCU to get response.
5.It sends the response to the central device.
6. In case of BLE disconnection, goto step 3
Case B:
4. A event is generated by MCU to the DA14580.
5.DA14580行为appropriately on it (restarts advertisement, sends indication)
6. Goto step 3
Or do we handle wakeup through a GPIO between MCU and DA14580. The state of the GPIO (changed by MCU) will tell DA14580 to goto sleep or stay awake?
Thanks,
Hrishikesh
Hi dhrishi,
1.Yes that is correct, the app_default_state_mode sets a defualt behaviour for the sleep mode of the device.
2. No, if you return KEEP_POWERED even if you have set the default sleep mode in ARCH_.._SLEEP will force the device to cancel sleep and restart the entire while loop, and start all over again the checking for the sleeping procedure. Please have a look at the UM-B-051 Software Platform Reference.pdf
Regarding where you can place the device in sleep, that depends on the application, in BLE applications usually the devices are in sleep mode between advertising intervals and connection intervals (the 580 will handle that on its own depending on the advertising and connection interval that its programmed by the application). Apart from that be aware that the device needs to be awake when you need to operate with the UART (it will also need the XTAL16 to be active and settled for the UART to operate properly), so in each UART interaction you should be in no sleep. Regarding if the external MCU should toogle the device between sleep and no - sleep mode that depends again on how you intent to implement the sleeping feature, apparently the external device should be aware when the 580 is awake in order to send data so if for example the 580 is in sleep mode the external MCU could toggle a GPIO in order to wake up the 580 and wait until the XTAL has settled, the 580 can notify the external device either via a GPIO or a command through UART. Also, instead of waking up the device you could use the flow control of the UART as the DSPS application does. There are different ways to implement this you will have to check which is more suitable for your application.
Thanks MT_dialog
Hi,
Thanks for your response.
When you say:
"apparently the external device should be aware when the 580 is awake in order to send data so if for example the 580 is in sleep mode the external MCU could toggle a GPIO in order to wake up the 580 and wait until the XTAL has settled, the 580 can notify the external device either via a GPIO or a command through UART."
I have a few questions on this:
1.So, if I toggle a GPIO from the external MCU by which I want to wake up DA14580, what is the software code I need to write for this? (bring it out of sleep and wait till XTAL is settled)
2. Once it has woken up, then I can notify the external device, right? Also, when the UART transaction is complete I will need to put the device to sleep again, correct? How do I do that. A sample aplpication demonstrating the same, if any, would be useful.
3.During this case (2.) what will happen about the return value of app_on_system_powered. I mean, if my function returns GOTO_SLEEP, when I wake it up for UART transaction, do I need to return KEEP_POWERED through this function too or it will be taken care of?
Thanks,
Hrishikesh
Hi dhrishi,
1.Yes, before the external MCU starts sending data you will have to be aware that the device is awake and the XTAL16 has settled in order to properly receive data on the UART.
2. Yes, when waking up you should notify the external device either via an additional GPIO or wait for the XTAL to settle. Regarding the sleep back mechanism, there are multiple ways to keep the device active and back to sleep, for example you can return KEEP_POWERED while you have an ongoing transaction and as soon as the transaction is completed you can return GOTO_SLEEP and the device will go back to sleep, also you can cancel the sleep with arch_disable_sleep() function while transaction is on going and restore the sleep mode with arch_set_extended_sleep() function. Regarding an example, you will be able to find the Codeless Serial Link in the reference design section perhaps this will give you some extra hints.
3.我不把问题,从回调t you return GOTO_SLEEP or KEEP_POWERED you can control from your application if the device will go to sleep or not, if you have pending actions from your application side then you need to call keep powered in order for the device to serve those actions then this is what you should do. The device will go through those functions and check what the application would like to do if the application instructs them to KEEP_POWERED then they will perform additional cycles until the functions return GOTO_SLEEP in order for the SDK to continue with the sleeping procedure.
Thanks MT_dialog