Unnecessary pin toggling or interrupts during changing the Port Mode on i.Mx8

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Unnecessary pin toggling or interrupts during changing the Port Mode on i.Mx8

413 Views
SivalingaKumar
Contributor I

Hi Team, We are using i.Mx8 micro for our project. Also we are using the MCAL package which we got from nxp and configured the MCAL with EB tresos tool. When we configure the CAN Rx pin to external interrupt at run time with the below specified sequence, we are getting the ISR detected immediately after configured it as GPIO ICU. The ICU channel is configured to detect the falling edge. Port_SetPinMode(PortConfigSet_0_PortContainer_0_CAN_F_DATA_RX,PORT_ALT4_FUNC_MODE);Port_SetPinDirection(PortConfigSet_0_PortContainer_0_CAN_F_DATA_RX, PORT_PIN_IN); Icu_EnableNotification(IcuChannel); Icu_EnableEdgeDetection(IcuChannel); If we have a given a delay between "Port_SetPinDirection" & "Icu_EnableNotification" APIs, then the false/unintended ISR is not detected and it is working fine. We have probed the CAN Rx line when we update to GPIO mode with "Port_SetPinMode" API. During the execution of this API, the CAN Rx pin is changed from high to low state and retained in low state for 96us duration. Then it is changed back to high state. Don't know why it is happening. Due to this unnecessary port toggling, the unexpected ISR is detected, as interrupt is configured for falling edge detection. On further debugging, we have identified that this unnecessary port toggling is happening during execution of below specified SCU firmware API. sc_err_t sc_pad_set_mux(sc_ipc_t ipc, sc_pad_t pad, uint8_t mux, sc_pad_config_t config, sc_pad_iso_t iso)   Is anyone faced the similar issue? Or any idea why the unnecessary port toggling is happening during execution of above API?

0 Kudos
1 Reply

391 Views
Yuri
NXP Employee
NXP Employee

@SivalingaKumar 
Hello,

  I've sent You message directly.

Regards,
Yuri.

0 Kudos