S32K344 - EMIOS - IPM (Input Period Measurement) erroneous data acquisition

fede_ls — Wed, 08 Jul 2026 09:03:02 GMT

Hi,

I'm writing a bare metal driver for the EMIOS module on my S32K3X4EVB-T172 evaluation board.

Currently, I'm using EMIOS_0 configured, with a 256x global prescaler, with channels as follows:

CH_23 -> MC Up Counter ( Timebase for Emios Counter Bus A) @ 625 kHz

CH_17 -> Running in OPWMB mode (using Counter Bus A)

CH_22 -> MC Up Counter ( Timebase for Emios Counter Bus F) @ 156.25 kHz

CH_9 -> Running in IPM mode (using Counter Bus F )

I'm generating a 16.18hz signal with 50% duty cycle, validated by the oscilloscope, that I'm routing from the OPWMB channel (PTA0) to the IPWMB channel (PTA1).

Every 10ms I'm acquiring a IPM sample, which consistently returns 9657/9658, giving me a measured period of 9657 * 0,0000064 = 0,0618048, resulting in a frequency of 1/0,0618048 = 16,18hz.

The Issue I'm having is related the almost periodical acquisition of erroneous values (as shown below).

period[0] UINT16 40017

period[1] UINT16 9658

period[2] UINT16 9657

period[3] UINT16 9658

period[4] UINT16 40017

period[5] UINT16 9658

period[6] UINT16 9657

period[7] UINT16 9658

period[8] UINT16 40017

period[9] UINT16 9658

period[10] UINT16 9657

period[11] UINT16 40018

period[12] UINT16 9657

period[13] UINT16 9658

period[14] UINT16 9657

period[15] UINT16 40018

Here's a code snippet explaining my current polling-based acquisition logic (no dma and no interrupts):

if ((EMIOS0->UC[9].S & 1u) != 0u)

{

UINT16 a1 = (UINT16)EMIOS0->UC[9].A;

UINT16 b1 = (UINT16)EMIOS0->UC[9].B;

UINT16 a2 = (UINT16)EMIOS0->UC[9].A;

UINT16 b2 = (UINT16)EMIOS0->UC[9].B;

if (a1 != a2)

{

if (b1 != b2)

{

period[ Index ] = (UINT16)(a2 - b2);

}

else

{

period[ Index ] = (UINT16)(a1 - b1);

}

else

{

period[ Index ] = (UINT16)(a2 - b2);

}

Index++;

if (Index > 99u)

Index = 0u;

EMIOS0->UC[9].S = EMIOS_UC_CLEAR_STATUS_FLG; /* 80008001u */

}

When testing different frequencies, the appearance of outliers is highly reduced but still present. Here's an example with 303hz:

period[0] UINT16 519
period[1] UINT16 519
period[2] UINT16 519
period[3] UINT16 519
period[4] UINT16 519
period[5] UINT16 519
period[6] UINT16 519
period[7] UINT16 519
period[8] UINT16 519
period[9] UINT16 519
period[10] UINT16 519
period[11] UINT16 519
period[12] UINT16 519
period[13] UINT16 30879
period[14] UINT16 519
period[15] UINT16 519
period[16] UINT16 519
period[17] UINT16 519
period[18] UINT16 519
period[19] UINT16 519
period[20] UINT16 519
period[21] UINT16 519
period[22] UINT16 519
period[23] UINT16 519
period[24] UINT16 519
period[25] UINT16 519
period[26] UINT16 519
period[27] UINT16 519
period[28] UINT16 519
period[29] UINT16 519
period[30] UINT16 519
period[31] UINT16 519
period[32] UINT16 519
period[33] UINT16 519
period[34] UINT16 519
period[35] UINT16 519
period[36] UINT16 519
period[37] UINT16 519
period[38] UINT16 519
period[39] UINT16 519
period[40] UINT16 519
period[41] UINT16 519
period[42] UINT16 519
period[43] UINT16 519
period[44] UINT16 519
period[45] UINT16 519
period[46] UINT16 519
period[47] UINT16 519
period[48] UINT16 519
period[49] UINT16 519
period[50] UINT16 519
period[51] UINT16 519
period[52] UINT16 519
period[53] UINT16 519
period[54] UINT16 519
period[55] UINT16 519
period[56] UINT16 519
period[57] UINT16 519
period[58] UINT16 30879
period[59] UINT16 519

Any help?

Re: S32K344 - EMIOS - IPM (Input Period Measurement) erroneous data acquisition

PavelL — Wed, 08 Jul 2026 12:12:36 GMT

Hello @fede_ls ,

Your polling logic is probably not the primary source of the observed outliers. The values strongly suggest that the period calculation does not handle the rollover of the selected counter bus correctly. The current expression (uint16_t)(A - B) assumes a full 16-bit counter rollover at 65536, but your counter bus F appears to roll over at approximately 35176 ticks. Therefore, whenever the captured period crosses the counter rollover, an additional offset of 65536 - 35176 = 30360 ticks is added, which exactly matches the observed outliers.

Please check the period/modulus configured for CH22, which is used as counter bus F for the IPM channel. The period should be calculated using this actual counter bus modulo value, not using implicit 16-bit unsigned subtraction.

Best regards,

Pavel

topic S32K344 - EMIOS - IPM (Input Period Measurement) erroneous data acquisition in S32K

S32K344 - EMIOS - IPM (Input Period Measurement) erroneous data acquisition

Re: S32K344 - EMIOS - IPM (Input Period Measurement) erroneous data acquisition