ADC0/ADC1 Interrupts Stop After Runtime Flash Erase/Program Operation on S32K144

[Jarvis_vk]

Hello NXP Community,

Controller: S32K144

Scenario:

ADC0 and ADC1 are configured in hardware trigger mode using PDB and are running continuously as part of the application. During runtime, a 4 KB flash sector erase is performed in a reserved flash memory region, followed by programming of new data into the same sector. To avoid execution issues during flash erase, interrupts are disabled before starting the flash operation and re-enabled after the erase/program sequence is completed.

Observed Behavior:

When interrupts are re-enabled after the flash operation, the application continues to run normally. Other interrupt sources continue to execute as expected, indicating that global interrupt functionality is restored correctly. However, ADC0 and ADC1 interrupt handlers are no longer triggered after the flash erase/program operation. As a result, ADC sampling stops and the application no longer receives ADC conversion updates. The issue is observed consistently whenever a flash sector erase is performed during runtime.

Additional Observation: ADC operation can be restored by forcing a software-triggered ADC conversion, after which ADC interrupts start occurring again and normal operation resumes.

Query: Is there any known interaction between flash erase/program operations and PDB-triggered ADC conversions on S32K144? Are there any recommended steps to re-synchronize or recover the ADC/PDB trigger chain after a flash operation so that ADC conversions and interrupts resume normally?

[PetrS · Accepted solution]

Hi,

Looks like typical PDB/ADC chain stuck after flash operation. The fact that a software-triggered conversion restores operation suggests the ADC/PDB state machine is not dead, only out of sync after the flash sequence. 

• During flash erase/program, if interrupts are disabled but PDB triggering is still active, ADC conversions may complete while results are not serviced/read, so COCO remains set. 
• That can lead to PDB pretrigger lock / sequence error, after which further hardware-triggered conversions may stop. 
• So it is worth asking whether ADC sampling is really needed during flash update. If not, the safer approach may be to stop/disable PDB triggering before flash operation and restart/re-sync it afterwards. 

Recommended checks/workaround:

• check PDB error/lock flags after flash 
• if sampling is not needed during flash, stop PDB before erase/program and enable it again afterwards
• otherwise after flash do explicit recovery: stop PDB → clear ADC status/read pending results → clear PDB flags → restart trigger chain

So likely root cause is not NVIC itself, but unserviced ADC/PDB state during flash operation.

BR, Petr

[Jarvis_vk]

Thanks for your reply, Petrs.

I implemented the suggested approach by stopping PDB0 and PDB1 before the flash erase/program operation and restarting them afterwards. After making this change, ADC0 and ADC1 interrupts resumed normal operation and the issue was resolved.
I would like to understand the root cause in more detail. Since interrupts were already disabled during the flash operation, I initially assumed that stopping PDB would not be necessary. Could you please explain why explicitly stopping PDB before the flash operation prevents this issue?
Also, is there any application note, reference manual section, or other supporting documentation that describes this behavior or the recommended handling of PDB-triggered ADC conversions during flash erase/program operations? I would like to understand the underlying mechanism and best practice for future implementations.

Thank you.

[PetrS]

Hi,

PDB pretrigger lock mechanism is described in chapter 46.4.1 PDB pre-trigger and trigger outputs of the device RM.

BR, Petr

[Jarvis_vk]

One more observation:
After enabling the Global ISR when P flash erase complete, I have one cycle of triggering sequence
PDB ISR call back --> ADC 1 --->ADC 0 After that ADC ISR call back function is not triggered