Hi,
We got "Disconnect" after link establishment in few seconds. We use extented sleep and fully hosted design.
But if we use arch_ble_force_wakeup(), the disconnection does not occur...
Is it proper usage of arch_ble_force_wakeup() ?? I think arch_ble_force_wakeup() should not be used periodically (for example, before sleep, make arch_ble_force_wakeup() called ).
And I think coder does not need to care about the relationship among extended sleep, wake up and connection....
If I could get any comments, it would be much appreciated!
Thanks for your support in advance.
Best regards,
CD
Device:
Hi CD,
The arch_ble_force_wakeup() shouldn't be used in order for a device to sustain a connection. The function forces the BLE to wake up when it isn't programmed to wake up (meaning that if you want your device to be awaken from an external wake up then this function should be used). The BLE will know when to wake up either for advertising or for a connection event without having to program anything.
Thanks MT_dialog
Hi MT,
Thanks for your quick reply.
Please let me confirm your comment above. An external wake up = Full Embedded solution design??
My design is Fully hosted (Integrated processor model), so we should not use this function(arch_ble_force_wakeup) at all, shouldn't we?! Means, fully hosted models knows when BLE core have to wake up and so on... Is it correct??
然后,我们应该有问题在我们使用SDK . .... We also use other functions in Sleep API. They are arch_set_extended_sleep() and arch_disable_sleep(). Can we use these functions for Fully Hosted design?? In the "DA1458x Software platform reference (Revision 1.0)", p.p. 42, there is a note which should be very important:
But, is it misprint or typo, is it?? Which/What solution?? Available for Full Embedded solution? or Fully hosted solution? I can't find the answer even in the source code...
我们应该如何代码当我想DA1458x系统客ep awake for a while in Fully hosted solution?? Can I use "arch_set_extended_sleep()" and "arch_disable_sleep()" for Integrated Processor design?
Thank you very much for your cooperation again.
Best regard,
CD
Hi CD,
An external wake up can exist in a fully hosted system (wake up from a button press) and yes if you want the BLE to be activated when the button is pressed you have to force the BLE to wake up. Other than that the system knows when it should wake up to keep a connection alive and the BLE will be awaken at that time. Yes you can use all the sleeping functions in a fully hosted solution, you can also have a look at the reference designs how many of those functions are implemented (many of those functions have different names since the ref des are implemented in previous SDKs).
Thanks MT_dialog
Hi MT,
Thanks very much!
Now, I'm getting to understand it. Please let me confirm the usage for arch_ble_force_wakeup();
I attached the excel file to visualize my image... Please refer it.
There are some confirmation questions in the file.
Thank you very much again for your support.
Best regards,
CD
Hi CD,
1) Yes, thats correct if you use external interrupts and you want your BLE to be active you have to force it.
2) When you use arch_disable_sleep() your device isn't going to sleep and when you invoke the arch_set_extended_sleep() the sleeping mechanism is going to be enabled.
3) Since you disable sleep when your button is hit you must not see any sleeping activity between the connection intervals, that doesn't mean that your device is going to keep on sending data, the intervals will stil remain the same but the da wont get to the lowest power mode it can get. From the image in question 3 it seems that you expect for the da to continiously transmit. It will just consume more power between the connection intervals.
Thanks MT_dialog
Hi MT,
Thanks a lot!! I can understand the architecture around sleep API.
Regarding the image in Usage C, this is a just example for the question and I do not want to do this. I just wanted to know how functions in Sleep API works.
Thank you very much for your support again. All questions about sleep API are clear now.
Best regards,
CD