Dear Dialog,
I would like to know what reason why DA14580 disconnected while being interrogated. Any condition or trigger for this case occurring?
My code is based on sample128, which works well for most of time. But sometimes this problem happens -- DA14580 can not be connected by my app, and it's reported "The peripheral disconnected while being interrogated." by Light Blue tool. Meanwhile, the advertising works very well -- The advertising data changed dynamically by sensor detecting.
If this case occurs, DA14580 never be connected all the time. The only way to let it work is "power-down reset". After reset, it works well. The problem does rarely happen, and not easy to be reproduced.
Is it caused by calling disconnecting function? I didn't find it from my code, may be somewhere or timing issue? So far, I can't find any clue for it. Please help!
Thanks!
Hello Alex Luo,
to me it sounds like it could be a hardware problem / xtal calibration issue. I have had similar issues. Do you use your own hardware?
Thanks Vesa,
Yes, I used my own hardware. The issue does rarely happen which is fetal issue for my application.
We used our App to track the connection, it looks that after connected the DA14580 disconnected immediately. I added a LED indicator in app_connection_func(), and found the LED light-on that means app_env.conidx == GAP_INVILAD_CONIDX when the issue occurs, but I'm not sure each interrogation goes this point. So, I wonder if there is something wrong with timing? If so, why the issue occurs, the connections are never made until the power down reset?!
By the way, I used RC oscillator for 32.768KHz, not Xtal. I also used to functions for timer: app_sample128_timer_handler() (I set timer for 200ms, 500ms and 2s for applications), and app_rtc_timer_handler() (for 1s fixed timer). I'm not sure if there is any conflict or with other timers in stack.
By the way, the code works very good for most of times, but sometimes this issue happens -- i didn't find where the problem is. Hope you can give me more clue.
Thanks,
Hello Alex,
Read the section 7. carefully
If it is not calibrated precisely, you may encounter strange behavior
Thanks!
Hello Vesa,
Thanks for your sharing your experience and I try to do it. Due to variation of the xtal and components, do you think to trim each of boards or using one trimming to cover all of those boards for production? (reaching 5ppm?)
Could you share with me about the phenomenon of the problem you met? Advertising works well and the connection is never made until reset? If so, the problem was fixed by trimming the Xtal?
Do you thinks if there is something wrong from firmware ?
Thanks a lot,
Hi Alex,
I guess one trim should cover all boards, however, there might be some variation.
For me, wrong calibration caused the advertising to "disappear" sometimes and the device function incorrectly in general. It was impossible to operate it. The problem was fixed my trimming the xtal and also changing the HW design a little. If the frequency is not correct, then the generated RF signal is in the wrong frequency zone.
When you are calibrating the xtal, you may also notice some drifting.
Can't say if there is anything wrong with the firmware.
Tanks Vesa,
I will try to follow your advice, and meanwhile dig-out more from f/w. The interesting thing is that all of the issues occurred when updating advertising data (need app_adv_stop and app_adv_start...)
Thanks,
Alex
Hello,
you may want to double check that you don't access wrong memory addresses, and that your adv packet is valid. Try printing it out in hex.
Hi Vesa,
It seems that is too difficult to find where the root of the problem is. The problem may not happen after running hundreds of times, and I wondering what trigger it. Very strange the connection never recovers after the problem occurs and advertising works very well. I don't know if there is any conflict after calling app_adv_stop and then calling app_adv_start() very close -- I can find more info about it. Do you have any experience on using add_adv_stop() and add_adv_start()? I used those after my advertising data updated in app_rtc_timer_handler() --which I created for RTC use (1sec/step). Hope you can find something there and let me know.
Thanks,
I have the same problem,i use 5V supply,when i change it to 3.3v,everything is fine！hope this help！
Hello cuijinfei,
DA14580 working voltage up to 3.6V, the chip can't work properly at 5V. So, using 3.3V is right.
Hi Dialog,
我遇到了同样的问题,亚历克斯。DA14580保持advertising but cannot be connected any more. Once the problem happens, it'll be always there and the only recovery operation is to restart the chip.
I got the air log when met the problem when using iPhone. But the problem also exists with Android. From the log, disconnection occurs after LLCP Version Exchange and no response from DA14580. The problem is not easy to reproduce but exists.
Could Dialog help to list some protential reasons? This's an urgent bug for me, can anyone give a favor? Thank u very much.
Best Regards
Angie
Hi angelforest,
Is the device disconnected by its own and then you can't reconnect ?Is your connection using any security, maybe something goes wrong there. When you issue the connection request can you tell of the da gets the connection request (in debug mode). Can you use a sniffer in order to see whats in the air ?
Thanks MT_dialog
Hi MT_dialog,
1. Question: Is the device disconnected by its own and then you can't reconnect ?
Answer: I am not sure the disconnection is caused by the device or host. But the connection cannot be established again until reset the DA14580.
2. Q: Is your connection using any security?
A: Yes. Our product involves HID and ANCS profiles.
// IO capabilities
cfm->data.pairing_feat.iocap = GAP_IO_CAP_NO_INPUT_NO_OUTPUT;
// Authentication requirements
cfm->data.pairing_feat.auth = GAP_AUTH_REQ_NO_MITM_BOND;
//Security requirements
// The HID Device shall use LE Security Mode 1 and either Security Level 2 or 3.
// here we use Mode 1, Level 2
cfm->data.pairing_feat.sec_req = GAP_SEC1_NOAUTH_PAIR_ENC;
3. Q: Can you use a sniffer in order to see whats in the air?
A: I used a sniffer. According the capture, disconnection always appears after LLCP Version Exchange. The master sent LLCP_Version(Opcode: LL_VERSION_IND) everytime with 6 tries, but no response from DA14580. Then after around 350ms, the sniffer showed our device turns back to "connectable state".
Have u met this before? Is that caused by security settings? Thank you.
BR
Angelforest
Hi angelforest,
不,据我所知没有这样的一个问题,如果the device can establish the first connection but not a reconnection it must be the key exchanging process in the second connection, maybe the keys aren't stored or exposed properly. Different handlers are used during reconnection, you can have a look in the keyboard reference design in order to see a proper HID connection.
Thanks MT_dialog