SAADC t_PWRUP and Burst Mode Sub-Sample Overhead

Hi,

I have a question regarding the SAADC timing parameters.

I could not find an official specification for the SAADC power-up time (t_PWRUP). While measuring it on my device, I consistently observed approximately 10 µs, whereas 3 µs is mentioned in the Designing Low-Power Bluetooth LE Products course here.

Could you please confirm the expected/guaranteed value of t_PWRUP and whether it varies by device family or SAADC configuration?

In addition, when using burst mode, I observed an extra delay of approximately 325 ns per sub-sample on top of the documented t_ACQ and t_CONV timings. In other words, the total burst timing appears to be:

(t_ACQ + t_CONV + ~325 ns) × 2^OVERSAMPLE

Is there any documented sub-sample overhead in burst mode, and if so, could you provide the expected value?

Thanks!

Parents
  • Hello,

    Unfortunately I can't find we have any data on the timing parameters you ask for. I can try to make an internal case so it may be looked at in future.

    Update:

    1. The t_PWRUP is 10us in nRF54L15.

    2. How many channels are there in use? How do you observe the 325ns per sub_sample? By checking the time between task START to event RESULTDONE and divided by 2^OVERSAMPLE, then subtract TACQ 375ns and TCONV 500ns?

    Kenneth

  • Hi Kenneth,

    That's great, thanks!

    1. Perfect, thank you! It would be good to have this documented officially, e.g. in the datasheet.
    2. Three channels are in use. Yes, that's exactly how I measured it. The oversampling factor is 32, with TACQ = 6125 ns and TCONV = 750 ns. I also tried different TACQ values down to 1125 ns, as well as a different oversampling factor (16), and the per-sub-sample overhead was approximately 325 ns in all cases.

    I've attached a scope capture; the red channel shows the START and RESULTDONE events, while the green channel shows the START and RESULT events. Unfortunately, I have to insert a dummy channel in between to keep the CPU asleep, since the SAADC lacks EasyDMA list array mode.

    On that note, may I suggest adding an EasyDMA array list mode to the SAADC in future devices or revisions? For low-power applications that scan multiple channels autonomously, the lack of it forces workarounds like dummy channels or CPU wake-ups between channels, which costs both power and code complexity. It would be a very welcome improvement; happy to file this as a formal feature request if there's a better channel for it.

    Thanks!

    Adnan

Reply
  • Hi Kenneth,

    That's great, thanks!

    1. Perfect, thank you! It would be good to have this documented officially, e.g. in the datasheet.
    2. Three channels are in use. Yes, that's exactly how I measured it. The oversampling factor is 32, with TACQ = 6125 ns and TCONV = 750 ns. I also tried different TACQ values down to 1125 ns, as well as a different oversampling factor (16), and the per-sub-sample overhead was approximately 325 ns in all cases.

    I've attached a scope capture; the red channel shows the START and RESULTDONE events, while the green channel shows the START and RESULT events. Unfortunately, I have to insert a dummy channel in between to keep the CPU asleep, since the SAADC lacks EasyDMA list array mode.

    On that note, may I suggest adding an EasyDMA array list mode to the SAADC in future devices or revisions? For low-power applications that scan multiple channels autonomously, the lack of it forces workarounds like dummy channels or CPU wake-ups between channels, which costs both power and code complexity. It would be a very welcome improvement; happy to file this as a formal feature request if there's a better channel for it.

    Thanks!

    Adnan

Children
No Data
Related