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]

I went through the Reference Manual and found that if a PDB pretrigger occurs while the lock state is active, the corresponding ERR bit in PDB_CHnS is set. The RM also states that once an ERR condition occurs, further ADC pretriggers are halted until the error flag is cleared by writing 0.
Based on that, I expected that clearing the ERR bits would allow ADC pretriggers to resume. To verify this, I added debugging in the first ADC0 and ADC1 ISRs that occur after the flash erase operation.
• As mentioned earlier, after the flash erase completes and interrupts are re-enabled, I observe one ADC0 ISR and one ADC1 ISR execution. Inside these ISRs:
• I read the ADC result registers, which should clear the COCO status.
• I read the corresponding PDB0_CH[0].S and PDB1_CH[0].S registers.
• If the ERR bits are set, I clear them by writing the status register back to 0.

What I observed is:
Before the flash operation:
PDB0_CH[0].S = 0x700000
PDB1_CH[0].S = 0x700000
After the flash erase:
PDB0_CH[0].S = 0x700010
PDB1_CH[0].S = 0x700010
• In the first ADC ISR after the erase, I clear the ERR condition and both registers return to 0x700000.
• However, after the subsequent 8-byte flash program operation, both PDB status registers again change to 0x700010.
• After this point, no further ADC conversions complete and COCO is not set for either ADC.
Based on the RM description, I expected clearing the ERR condition to allow ADC pretriggers to resume, but that does not appear to happen in this case. Could you please help explain why the ERR condition reappears and whether any additional recovery sequence is required after flash erase/program operations when using PDB-triggered ADC conversions?

Currently, the only workaround that consistently resolves the issue is stopping PDB0/PDB1 before the flash erase/program operation and restarting them afterwards. Is this the recommended solution, or is there a more appropriate recovery sequence that should be used?

[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