ADC with interrupts for NXP MIMXRT1062

[Shruuts]

Hello,

I am using Zephyr 3.4 for my MIMXRT1062 system. I am trying to enable ADC interrupts and am not able to. I have the following code:

prj.conf:
CONFIG_ADC=y
CONFIG_ADC_ASYNC=y

Overlay file:
/ {
zephyr,user {
io-channels = <&adc1 0>, <&adc1 15>;
};
};
&pinctrl {
pinmux_adc1: pinmux_adc1 {
group0 {
pinmux = <&iomuxc_gpio_ad_b1_11_adc1_in0>,
<&iomuxc_gpio_ad_b1_10_adc1_in15>;
bias-disable;
drive-strength = "r0-6";
slew-rate = "slow";
nxp,speed = "100-mhz";
};
};
};

&adc1 {
status = "okay";
pinctrl-0 = <&pinmux_adc1>;
pinctrl-names = "default";
#address-cells = <1>;
#size-cells = <0>;

channel@0 {
	reg = <0>;
	zephyr,gain = "ADC_GAIN_1";
	zephyr,reference = "ADC_REF_INTERNAL";
	zephyr,acquisition-time = <ADC_ACQ_TIME_DEFAULT>;
	zephyr,resolution = <12>;
};
channel@15 {
	reg = <15>;
	zephyr,gain = "ADC_GAIN_1";
	zephyr,reference = "ADC_REF_INTERNAL";
	zephyr,acquisition-time = <ADC_ACQ_TIME_DEFAULT>;
	zephyr,resolution = <12>;
};

};

In my main code, since I don't see an API for adding interrupts, I have the following:
status_t err = EnableIRQ(ADC1_IRQn);
NVIC_SetPriority(ADC1_IRQn, 0);

adc_config_t adcConfigStruct;
ADC_GetDefaultConfig(&adcConfigStruct);
ADC_Init(ADC1, &adcConfigStruct);

adc_channel_config_t adcChannelConfigStruct;
adcChannelConfigStruct.channelNumber = 0;
adcChannelConfigStruct.enableInterruptOnConversionCompleted = true;

while (1) {
ADC_SetChannelConfig(ADC1, 0, &adcChannelConfigStruct);
k_sleep(K_SECONDS(1));
printk("%d\n", adc_counter);
// val = ADC_GetChannelConversionValue(ADC1, 0);
}

I have the following defined as well:
extern "C" {
void ADC1_IRQHandler(void) {
adc_counter++;
}
}

I am printing the config registers of ADC1:
HC[0] = 80, HC[1] = 1f, HC[2] = 1f, HC[3] = 1f
HC[4] = 1f, HC[5] = 1f, HC[6] = 1f, HC[7] = 1f
CAL = 8, CFG = b, CV= 0, GC = 1, GS = 0, HS = 0, OFS = 0
R[0-7] = 2af, 0, 0, 0, 0, 0, 0, 0

I got this code the an example from MCUexpresso and have this code running in that example (evkbmimxrt1060_adc_12b1msps_sar_interrupt). All my register values map with MCUexpresso. The behavior I observe is that "ADC1_IRQHandler" is never called. I looked into startup_mimxrt1062.c code as well, where ADC1_IRQHandler is declared, and the weak definition of ADC1_IRQHandler is also never called. So it looks like interrupts are not being triggered.

Can you please help with what I might be missing to trigger interrupts?

Thank you.
Shruti

[decsny]

As for interrupts generally, please read the Zephyr interrupt documentation to understand the context

But more specific to this case, the interrupt for the ADC is already enabled and associated with the ADC driver. Is there something that you are trying to accomplish that is not covered by the Zephyr API? Please see the ADC API documentation, maybe the ADC sequence callback meets your needs

[Shruuts]

Hey Declan,

Thanks for your response. I need to be able to continuously read ADC conversions on a channel (as fast as the processor allows) and process them in a separate thread. Ideally, I would have liked to set up the interrupt function to read and then swap buffers and/or channels as needed for my application for as long as the application is running. The advantage of the bare-metal implementation is that I can write ADC1_IRQHandler as needed.

With the Zephyr ADC driver, it looks like this API is not exposed to the user. I am looking at functions like:
mcux_12b1msps_sar_adc_start_channel
mcux_12b1msps_sar_adc_isr

Stepping through the code, it seems like even if I give the following options:
uint16_t buf[128] = {0};
struct adc_sequence_options seq_options = {.extra_samplings = 127};
struct adc_sequence sequence = {
.options = &seq_options,
.buffer = &buf,
// buffer size in bytes, not number of samples
.buffer_size = sizeof(buf),
};
The code will jump to adc_context_on_sampling_done for every sample, which adds delay. I still have to characterize how much delay it adds.

For the swapping buffer fix, I can use the sequence callback to swap buffers, but I will still need to call adc_read again in a thread. But this is still workable. The delay I mentioned above might be a gating factor.

Is there something I am not understanding correctly?

[Shruuts]

An update here, adc_read takes ~530us with the above configuration. That is a delay of ~4.14us between samples. This is about 4x what the hardware can support. How can I make this delay less?

[Shruuts]

Another update:
I hacked into adc_mcux_12b1msps_sar.c and changed the ISR code to call ADC_SetChannelConfig directly multiple times and got the latency down to ~1.8us per sample. I also set adc_config.enableHighSpeed = true. It would be great is this was exposed to the user so I don't have to change Zephyr. But it seems for now I will need to patch Zephyr for my application.

[decsny]

@Shruuts I have seen this limitation on other platforms with other ADC as well. Perhaps you can make an enhancement request in the issues tab, and ask for the ADC context to be enhanced so that it doesn't need so much cpu intervention after each sample. Issues are much more likely to get attention from developers than discussions. This is not really an issue with the user-facing zephyr API or the 12b1msps_sar ADC driver specifically; it is an issue with the common driver code in adc_context that has severe implications for performance in certain use cases like the one you describe.

In addition to this use case, there are also some ADCs I have seen with hardware features that cannot be supported with this current adc_context, such as DMA driven buffer filling, and ADCs with hardware fifos that cannot be fully taken advantage of since they must be limited to a size of 1 sample to meet this adc_context api.

Alternative is to re-write the driver not to use adc_context, but this should not be what happens in the tree because the point of adc_context is to save work for driver development since there are some common operations that need done. So we should just be improving adc_context first.

Another alternative specifically for you for now is to just disable the zephyr ADC driver with kconfig and use the mcuxpresso sdk adc driver from your application. You can connect the interrupt to an isr with IRQ_CONNECT as mentioned in the documentation I linked above. But this is more awkward, obviously, defeats the point of having zephyr drivers, and not what we want people to have to do. I would prefer to extend adc_context functionality than for this to be the norm.

[decsny]

@Shruuts before this though, can you confirm that the most delay is from the adc context/driver code and not user callback, also, calling adc_read is not necessary except after all of the sequence extra samplings complete.

as for enableHighSpeed, I suppose this could be a configuration option for this specific ADC, so you can make an issue about that too or contribute it yourself if you wish

[Shruuts]

Hey Declan,

I haven't looked at the DMA functionality for this chip, so I don't have comments on that for now.

As you suggested, for now I am disabling adc from my overlay file and calling NXP functions directly. This works as expected now! The latency per sample is ~1.7us (I am reaching out to NXP to try and reach their minimum of 0.7us). The same sample reading takes ~4us if I use the adc_context API by setting the 'extra_samplings` option in adc options (with the high-speed option enabled).

Here are the enhancement requests I have made:
#63328
#63329