2026-04-03 1:51 AM
According to the manual, I cannot determine under what conditions the INFIFO will assert the interrupt. The interrupt-related registers only provide two status flags: empty and not full. The IN FIFO has a depth of 8 words (8×32 bits). However, the later description states that the interrupt will be asserted when there are fewer than 4 words in the IN FIFO. How is this interrupt actually generated?
Solved! Go to Solution.
2026-04-03 5:45 AM
Hello @afa_leo, and welcome to ST Community!
On STM32H757, the input FIFO service interrupt is not generated directly from the IFNF (input FIFO not full) or IFEM (input FIFO empty) status flags, and this is where the misunderstanding comes from. The bits IFNF and IFEM in CRYP_SR are simple status indicators: IFEM tells you the FIFO is empty, and IFNF tells you it is not full (there is at least one free slot in the 8‑word FIFO).
In contrast, the interrupt condition is defined separately in the manual text: “The input FIFO service interrupt is asserted when there are less than four words in the input FIFO. It is cleared by performing write operations to the input FIFO until it holds four or more words.” This means the CRYP hardware maintains an internal count of FIFO words and compares it to a fixed watermark of 4.
The raw interrupt is asserted when the FIFO level is 0-3 words and automatically de‑asserted once you have written enough data so that the FIFO contains at least 4 words (or you disable the interrupt/peripheral). The table that labels the event as “Input FIFO not full / Input FIFO empty” is only a coarse description; the exact trigger is this “fewer than four words” rule.
Therefore, the interrupt is generated by an internal threshold of fewer than 4 words, while IFNF and IFEM merely reflect full/empty status and do not themselves define when the interrupt fires.
Best regards,
2026-04-03 1:57 AM
STM32H757...
2026-04-03 5:45 AM
Hello @afa_leo, and welcome to ST Community!
On STM32H757, the input FIFO service interrupt is not generated directly from the IFNF (input FIFO not full) or IFEM (input FIFO empty) status flags, and this is where the misunderstanding comes from. The bits IFNF and IFEM in CRYP_SR are simple status indicators: IFEM tells you the FIFO is empty, and IFNF tells you it is not full (there is at least one free slot in the 8‑word FIFO).
In contrast, the interrupt condition is defined separately in the manual text: “The input FIFO service interrupt is asserted when there are less than four words in the input FIFO. It is cleared by performing write operations to the input FIFO until it holds four or more words.” This means the CRYP hardware maintains an internal count of FIFO words and compares it to a fixed watermark of 4.
The raw interrupt is asserted when the FIFO level is 0-3 words and automatically de‑asserted once you have written enough data so that the FIFO contains at least 4 words (or you disable the interrupt/peripheral). The table that labels the event as “Input FIFO not full / Input FIFO empty” is only a coarse description; the exact trigger is this “fewer than four words” rule.
Therefore, the interrupt is generated by an internal threshold of fewer than 4 words, while IFNF and IFEM merely reflect full/empty status and do not themselves define when the interrupt fires.
Best regards,
2026-04-06 6:20 PM
Thank you for your response,I would like to double-check the following:
1.INRIS and INMIS are only related to the threshold of 4, and are independent of whether the IN FIFO is empty or full.
2.INMIS and OUTMIS are logically ORed to produce the interrupt signal for the CPU.
Is my understanding of the above two points correct?
2026-04-07 7:19 AM
INRIS and INMIS relate only to the threshold of 4 and are not derived from IFEM/IFNF. However, note that when the IN FIFO is empty (0 < 4), INRIS and INMIS will also be set. Therefore, emptiness is effectively a special case of the <4 threshold condition, rather than a separate factor.
Yes, INMIS and OUTMIS are logically ORed internally to generate the interrupt signal sent to the CPU.
2026-04-08 6:01 PM
Thanks for your answers.