Issue with setting CAN pins

[brentgreenwald]

Can someone explain why the "SetPinMux" function works correctly for PORTD but not PORTA. The attempt to SetPinMux for PORTA gives a hard fault. Also, what is a hard fault?

void BOARD_InitPins(void)

{

    /* Initialize UART1 pins below */

    /* Ungate the port clock */

    CLOCK_EnableClock(kCLOCK_PortD);

    /* Affects PORTD_PCR8 register */

    PORT_SetPinMux(PORTD, 8u, kPORT_MuxAlt3);

    /* Affects PORTD_PCR9 register */

    PORT_SetPinMux(PORTD, 9u, kPORT_MuxAlt3);

    /*Set CAN0 */

    PORT_SetPinMux(PORTA,12u,kPORT_MuxAlt2);

    PORT_SetPinMux(PORTA,13u,kPORT_MuxAlt2);

}

P.S.

I attached main.c in case you need to look at it.

Original Attachment has been moved to: main.c.zip

[BlackNight]

Hi Brent,

As Charles responded, you need to clock peripherals first before using it, otherwise a hard fault will happen.

In case you need to find out what is causing the hard fault, the following might help you:

https://mcuoneclipse.com/2012/11/24/debugging-hard-faults-on-arm-cortex-m/

Basically it means that you install a custom handler where you can get PC/cause of the fault.

As for the muxing: there is the NXP (Kinetis Expert) Pins tool which does the additional checks and as well turns on the clocks for you. See https://mcuoneclipse.com/2016/07/19/nxp-pins-tool-clock-gates-and-controlling-the-bits/  and https://mcuoneclipse.com/2016/06/08/tutorial-muxing-with-the-new-nxp-pins-tool/ .

I hope this helps,

Erich

[charlesasquith · Accepted solution]

Hi Brent,

you need to enable the clock for Port A, similarly to how it is done for Port D. That is (probably) why Port D works, but Port A is giving a hard fault.

Just add this line of code in before you mux your pins:

CLOCK_EnableClock(kCLOCK_PortA);

Now a hard fault, simply put, is essentially something that happens when the ARM Cortex-M core recognizes that a set of error conditions have been fulfilled. You can think of it like an interrupt. When an ARM core detects an interrupt, it goes to an interrupt service routine. On a similar note, when an ARM core detects an error, it goes to a hard fault handler. This is why a hard fault is called an "unhandled interrupt", because an error "interrupts" the ARM core, which then tells the ARM core that it needs to go an interrupt service routine, which is in this case the hard fault.

It really helps to step through your code and determine exactly what line of code is causing your hard fault, and from there you can work to debug it.

Hope this helps,

Charles