Sub-IoT-Stack icon indicating copy to clipboard operation
Sub-IoT-Stack copied to clipboard

Bug scheduling messages in the unsollicited response callback

Open Dond96 opened this issue 3 years ago • 8 comments

I ran into a bug where it's not possible to schedule a message from the unscollicited response callback. The message was sent in a function that was scheduled in the unsollicited response callback. In the scheduled function the d7ap_send function was called and returned code 0 (SUCCESS) the message would be scheduled but never send. When scheduling the function with the timer_post_task_delay function the message would be sent.

Dond96 avatar Dec 07 '21 09:12 Dond96

Example:

void scheduled_function() { d7ap_send(message); // Returns 0 in both cases }

bool unsolicited_cb(args) { sched_post_task(&scheduled_function); // Doesn't work timer_post_task_delay(&scheduled_function, delay); // Does work return false; }

Dond96 avatar Dec 07 '21 09:12 Dond96

this is a bit of a weird use case to me, you want to transmit a message when getting an unsolicited message, but you don't want to answer it in the same dialog? I think now you're trying to start a new dialog while the previous one is still wrapping up, however it should indeed not return SUCCESS.

LOorts-Aloxy avatar Dec 07 '21 09:12 LOorts-Aloxy

I don't respond in the dialog because I'm switching access classes to go from background scanning to continious forground scanning.

Dond96 avatar Dec 07 '21 11:12 Dond96

won't it be better to first answer and then switch classes? I think you still want to transmit to the same device?

LOorts-Aloxy avatar Dec 07 '21 11:12 LOorts-Aloxy

I do answer first. The scheduled function just sends the next message using the new access class.

Dond96 avatar Dec 07 '21 12:12 Dond96

so you're scheduling two d7 messages at the same time? Sorry, just trying to get a grasp of the situation. alp never directly schedules an independent answer right after it got some unsollicited message

LOorts-Aloxy avatar Dec 07 '21 12:12 LOorts-Aloxy

Well the message gets send in a function thats called by the scheduler so it should be send outside the scope of the unsolicited callback. I think the message did end up in the message queue but it didn't get send. I could trigger the function by pressing a button on another board and after pressing it a couple of times the d7ap_send funciton would return an error code but the messages were never transmitted. (I think the error code was caused because the buffer was full)

Dond96 avatar Dec 07 '21 12:12 Dond96

ok, weird, we'll have to look into that. We haven't seen this happen using alp above d7.

LOorts-Aloxy avatar Dec 07 '21 13:12 LOorts-Aloxy