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

[kpreiss]

I am upgrading to SDK 15.3.0 and SoftDevice v6.1.1 from SoftDevice v2.0.0 (S332 stack). Most of functionality has been ported (BLE and ANT) and validated. This particular functionality involves a shared channel with a single Master and multiple Slaves. The Slave channel is configured as a CHANNEL_TYPE_SHARED_SLAVE. Testing a simple case with just one Slave trying to burst response data back to the master after receiving a command.

This functionality worked fine when using the v2.0.0 SoftDevice, but frequently the first call to the sd_ant_burst_handler_request() function returns Transfer in Progress. Not much changed in the migration so I'm not sure what could be happening. I have confirmed the previous v2.0.0 implementation works with the same Master that is failing with the v6.1.1 implemenation. I am never able to deliver a complete 4 segment burst as things stand.

Perhaps I'm missing something related to the migration for v2.0.0 to v6.1.1. Any help would be appreciated.

Further Information:

The issue is that all 4 segments of the burst are submitted via the sd_ant_burst_handler_request() successfully , but that no EVENT_TRANSFER_TX_COMPLETED or EVENT_TRANSFER_TX_FAILED (or any other Txevent) is generated after the 4th segment. So when the application goes to send the next burst transfer the channel returns a Transfer In Progress error. The shared channel address in the burst is set to 0x00.

Using an ANT packet sniffer I can see the Master broadcast command, but I never seen any of the Slave burst command segments get transmitted. When using a Slave running the v2.0.0 implementation, I see the Slave burst command segments being transmitted. So this explains why there is no Tx event. Why isn't the transmission ocurring. Running the same v6.1.1 in Master mode all transmission are visible.

[Kenneth]

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?

[kpreiss]

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".

[Kenneth]

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

[kpreiss]

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.