嗨对话框，
I have a peripheral application that requires me to update advertisement rapidly by stopping current advertisement
and then restarting it with a new data after GAPM_CMP_EVT (undirected/non_connectable adv complete) callback came.
However, I have been observing a strange behavior on DA14580 (packaged by Murata) that
in statistically small chance, there is a time when GAPM doesn't return my app_easy_gap_advertise_stop().
And continue to do so after this happen (the problem can only be fixed after a hardware reset).
It is hard to reproduce this, that's why I can't tell exactly what kind of condition when this happen. Still trying to.
My question is, is there any similar known bugs (GAPM doesn't send back adv complete's GAPM_CMP_EVT even though TASK_LLM is on LLM_ADVERTISING) on
SDK 5.0.3 ?
Thanks
FYI,
After this happen, task statuses seem normal.
GAPM at GAPM_IDLE, TASK_LLM at LLM_ADVERTISING (and actually advertising a non_conn adv), TASK_LLC is at LLC_FREE.
However, GAPM doesn't return GAPM_CMP_EVT in response of app_easy_gap_advertise_stop().
Even timers are working..
嗨meriororen,
Your issue is that, after stopping the advertising by issuing the app_easy_gap_advertising_stop() the advertising never stops so the handler with the GAPM_CMP_EVT never triggers ? We dont have any reports for this kind of behaviour. Perhaps you can give me some more information regarding how fast you start and stop the advertising procedure and how you implement this functionallity? Also can you please let me know about the SDK that you are using (SDK5 which version) and on which example your project is based on, also how often this happens ?
谢谢mt_dialog.
Yes. I have 2 kinds of advertisements,
1.Undirected (connectable) advertisement that has 50ms (intv 80) interval, data updated every 400ms.
2. Non-connectable (beacon) advertisement that has 100ms (intv 160) interval, data updated every 150ms.
Yes, I know, I am pushing the intervals to the limit.
These 2 advertisements has 2 modes of operations, during connection, only beacon is advertised (beacon-only mode), and during disconnection, the advertisement toggles between 1 and 2 (toggle mode).
To update the advertisement data, first I check if the advertisement is up by checking TASK_LLM, if it is LLM_ADVERTISING, I send a cancel (stop) message,
waits for GAPM_CMP_EVT message (adv_complete with GAPP_ERR_CANCELLED status), and then start advertising again immediately.
The problem arises after disconnection, after a disconnection happens, I switch to toggle mode (this is done asyncly by sending a UART message from another microcontroller),
like usual, the switching to toggle mode happens: It sees if now I am advertising, stops it when it does by sending app_easy_gap_advertising_stop(), and then starts again when
a GAPM_CMP_EVT (adv_complete w/ GAP_ERR_CANCELLED) cues. But sometimes the cue didn't even came.
在再次调试一下进一步时，我知道几件事：
1.这之后发生的,而不是returning GAPM_CMP_EVT adv_complete, the stop command instead is returned with GAPM_CMP_EVT gapm_cancel with GAPM_ERR_COMMAND_DISALLOWED (0x43). No matter how many time we try.
2. Right before this happens, suddenly there is a GAPM_CMP_EVT adv_complete with GAPM_ERR_PROTOCOL_PROBLEM (0x41). Somewhere in the forum I checked that there is similar problem with directed advertising regarding this where the reason was advertising interval, it wasn't that. And I doubt that this will cause problem no.1 arises. However, in my case, after 0x41 came, problem no.1 did arise.
3. Sometimes, GAPM would even stuck at GAPM_BUSY_AIR, and stops responding to any command.
We are using SDK 5.0.3, from barebone example. And the problem happens about 3 to 4 time among 100 disconnection.
Oh yeah, throughout the 100 disconnection, the 0x41 status only came out once. After that, my advertisement stop command is always returned with 0x43 status.
Thanks
您可以做的第一件事是尽量避免检查Task_LLM的任务状态。由于分层体系结构和消息传递，您的App任务所看到的状态根据检索到的最新消息可能不会与内部任务同步。你应该让自己追踪州。例如，如果您开始通告您设置了一个广告正在进行的变量，并且一旦您获得GapM_CMP_EVT告诉广告已停止，您可以清除该变量。
嗨meriororen,
You can try a variable defined by you, as Joacimwe suggested, or you can try to check the state of the application TASK_APP with ke_state_get() when the device is advertising you should be in APP_CONNECTABLE mode. From the replies of the stack i suppose that you are sending commands that the stack can not execute at the current mode of operation.
谢谢mt_dialog.