SAADC scan mode with internal timer on nRF54L15

[erwallc]

Hi,

I am attempting to sample multiple channels using the nrfx drivers. Using external timer with PPI over internal timer seemed to provide no benefit so I went for internal timer since the configuration was simpler and more straightforward. Works well for a single channel but adding a second one is unsupported, according to the return value of the function in the HAL.

    if ((p_config->internal_timer_cc) && ((active_ch_count > 1) || (!event_handler)))
    {
        return NRFX_ERROR_NOT_SUPPORTED;
    }

Latest SDK seems to be on nrfx 3.10.0, so source code link to relevant line here.

I have scoured the documentation for the nRF54L15 for any mention of such a restriction but found nothing. A couple of DevZone questions have asked this 5 years ago and 6 years ago and the limitation seems to be documented for older chips. I tried simply ignoring the check for channel count and I get readings for both channels as expected, so the limitation doesn't seem to apply.

Are there any potential problems with working around the restriction in nrfx?

If it's a bug, could it be fixed upstream? I am happy to contribute if so, although it doesn't seem like a quick, file local fix at a glance.

Lastly (out of curiosity), are there any benefits to using external timer with PPI over internal timer on this SoC?

SDK 3.1.1

nRF54L15DK

Regards,

Charlie

[Einar Thorsrud]

Hi Charlie,

This was a limitation in the nRF52 and nRF53 series devices, but I do not see a problem using the internal SAMPLERATE timer with multiple enabled channels on nRF54 series.

The check that prevents it is old and has not been updated lately when adding support for the nRF54 series, which it looks like it should have been. I have created an internal ticket to have the driver updated, but it will for sure not happen for the v3.2 release of the SDK.

For a simple use case with a one to one mapping from a timer to the SAADC I do not see a clear advantage using that instead of the internal samplerate timer. DPPI is quite flexible though, so it is probably possible to think of use cases where that would be a better fit.

Br,

Einar

[erwallc]

Einar Thorsrud said:

timer with multiple enabled channels on nRF54 series.

The check that prevents it is old and has not been updated lately when adding support for the nRF54 series, which it looks like it should have been. I have created an internal ticket to have the driver updated, but it will for sure not happen for the v3.2 release of the SDK.

Einar,

Thank you for the reply. How would you recommend I work around it until a fix is available in an SDK release? Our project is currently set up as a freestanding repo, but I'm guessing a workspace repo and using west patch would be the most straightforward?

I'm also wondering if you have any advice on handling the data. Our setup consists of two differential microphones and I wish to separate the processing of the data (sampled using a double buffer setup) but the data is interleaved in memory. To keep processing time down the initial approach is to pass the full buffer with an offset of 0 and 1 to processing threads. Are there any options in DMA or some efficient way to separate the data or supply separate buffers for each channel?

Best regards,

Charlie

[Einar Thorsrud]

Hi Charlie,

For the first part of the question it is up to you and what fits your need how you want to organize the code and various repositories. A workspace application often makes sense as you are free to point to your own fork of repositories if you have to make changes in some (as an alternative to patching).

For the other question, you can only provide one result buffer for the SAADC at a time. And if using two channels in scan mode, you every second sample will be for one or the other channel. So in this case you will end up with a single buffer holding data for both channels. I do not have a particularly efficient way of handling this. It would be OK to have separate threads that only read from the same buffer and skips every second sample, as long as you ensure that both are done with the data before the buffer is re-used. But if you need the data consecutive for some reason, it has to be copied out and re-assembled in two separate buffers.

[erwallc]

Thank you Einar,

That answers my current questions. I've marked the first reply as Verified Answer, since that answered my original question.

If there is a public issue tracker for the driver update that I can refer to in my commits, it would be nice if you can provide a link to that.

Thanks again for timely and useful replies!

[Einar Thorsrud]

Hi,

I am glad to hear that. The ticket is internal, so there is unfortunately nothing you can refer to (other than perhaps this thread).