Transfer In Progress Returned From sd_ant_burst_handler_request() On Initial Call (SoftDevice v6.1.1)

RE: Transfer In Progress Returned From sd_ant_burst_handler_request() On Initial Call (SoftDevice v6.1.1)

kpreiss — Tue, 12 May 2020 13:38:44 GMT

That is my understanding as well...no migration changes.

The buffers are static as they needed to be for v2.0.0 to work as well. No errors are being returned on any sd_ant_burst_handler_request() calls until the channel gets stuck in "Transfer In Progress" state. What is curious is that when configuring the radio application to be a Master and send shared channel broadcast messages everything works as expected.

I have posted this same question on the ANT forum and haven't received any feedback yet.

There must be a finite number of situations that would keep the ANT stack from transmitting a burst...I just don't know what they are.

RE: Transfer In Progress Returned From sd_ant_burst_handler_request() On Initial Call (SoftDevice v6.1.1)

Kenneth — Tue, 12 May 2020 13:31:09 GMT

From the description of the api between v2.0.0 and v6.1.1 they are identical:

https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s332.api.v2.0.0/group__ant__interface.html#gaa09761cfc5e7373048e90e2dca208e6a

https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s332.api.v6.1.1/group__ant__interface.html#gaa09761cfc5e7373048e90e2dca208e6a

Maybe check if you have defined the buffer as static and that it doesn't change, I assume that there are no error message from sd_ant_burst_handler_request() either.

Have you tried to reach out on https://www.thisisant.com/forum/ for this question also?

Best regards,
Kenneth

RE: Transfer In Progress Returned From sd_ant_burst_handler_request() On Initial Call (SoftDevice v6.1.1)

kpreiss — Tue, 12 May 2020 11:04:32 GMT

I have reviewed both those examples, and remember, I am starting from a working implementation on v2.0.0. The original implementation was to submit the burst segments separately using the the conclusion of the Master broadcast message reception for initiation and the succeeding EVENT_TRANSFER_NEXT_DATA_BLOCK events (4 segments total). The segment identifiers (BURST_SEGMENT_START, BURST_SEGMENT_CONTINUE, BURST_SEGMENT_END) are set properly in this case.

During experiments yesterday, I collapsed the implementation to submit the entire 4 segments at once (I have a 128 byte burst queue configured) with the BURST_SEGMENT_START and BURST_SEGMENT_END notifiers set. I did notice a single EVENT_TRANSFER_NEXT_DATA_BLOCK event occurred after submitting the complete burst which I wouldn't have expected.

I did this just to see if the behavior changed. I can see the burst data present in the memory block allocated for ANT stack usage (nrf_sdh_ant_enable()) after the call to sd_ant_burst_handler_request(). The ANT stack just doesn't appear to transmit the burst and the channel remains in the "Transfer in Progress" state. The channel status is "Tracking".

RE: Transfer In Progress Returned From sd_ant_burst_handler_request() On Initial Call (SoftDevice v6.1.1)

Kenneth — Mon, 11 May 2020 21:00:49 GMT

I can see from the ANT_s332_nrf52832_6.1.1.migration_document.pdf when downloading the S332 softdevice that there is no difference from v2.0.0->v6.1.1 that should explain this.

Have you looked at the two examples in SDKv16 that I can find use sd_ant_burst_handler_request()?

\examples\ant\ant_message_types\master\ant_message_types_master.c
\examples\ant\ant_advanced_burst\ant_advanced_burst.c

For instance are you using BURST_SEGMENT_END?