The reason for CyU3PGpifDisable is that the CPU is getting blocked with continuous interrupts as soon as the GPIF state machine is paused prior to getting disabled.
This is happening because the PIB/GPIF error interrupts are also enabled in the application due to the BACKFLOW_DETECT being enabled.
CyU3PVicDisableAllInterrupts() API disables all Interrupts at the Vectored Interrupt Controller (VIC) level.
Would you like to keep UART interrupt enabling?
Thank you for your reply.
Is the interrupt that occurs when CyU3PGpifDisable() is executed CYU3P_PIB_INTR_ERROR?
In our execution environment, It seems that the application does not always freeze when CyU3PGpifDisable() is executed.
Is there any other cause for the continuous occurrence of interrupts?
(ex. CyU3PGpifDisable () execution timing, another interrupt occurs at the same time, etc...)
Yes, we need a UART interrupt.
If we mask all interrupts with CyU3PVicDisableAllInterrupts(), the application will freeze as well. (Receiving data from UART)
Instead of the workaround presented in the FAQ, we did the following:
PIB->intr_mask &= ~(CY_U3P_PIB_INTR_PIB_ERR | CY_U3P_PIB_INTR_GPIF_ERR | CY_U3P_PIB_INTR_MMC_ERR );
CyU3PGpifDisable( CyTrue );
PIB->intr_mask |= (CY_U3P_PIB_INTR_PIB_ERR | CY_U3P_PIB_INTR_GPIF_ERR | CY_U3P_PIB_INTR_MMC_ERR );
This process ensures that the application works correctly.
Is this valid as a workaround?
Sorry to trouble you, please give me an answer.
>>Is the interrupt that occurs when CyU3PGpifDisable() is executed CYU3P_PIB_INTR_ERROR?
Yes, we think so.
>>In our execution environment, It seems that the application does not always freeze when CyU3PGpifDisable() is executed.
The execution for GpifDisable() is a very short time (about 20 us). Thus, we think the issue occasionally happens.
If the customer does not want to disable all interrupts, they can selectively disable PIB interrupt alone ( do not affect UART interrupt) by using:
Above is our recommended workaround.
CyU3PVicDisableInt() is used for disabling the interrupt for the specified vector number.
Regarding the detail information of CYU3P_PIB_INTR_ERROR, kindly ask the customer to read PIB Error Indicator Register (PIB_ERROR、address 0xE0010020) on FX3 TRM.
Thank you for your support.
Unfortunately, the proposed workaround did not solve the problem.
We will continue to investigate the cause of the problem.
Is there any difference between disabling interrupt vectors and masking interrupt sources?
Let me know if you have any concerns.
Sorry for the delay.
I understood disabling only CY_U3P_VIC_PIB_CORE_VECTOR does not help to resolve its issue.
You can mask PIB_ERR and GPIF_ERR to resolve its issue, not need to mask MMC_ERR.
PIB->intr_mask &= ~(CY_U3P_PIB_INTR_PIB_ERR | CY_U3P_PIB_INTR_GPIF_ERR );