This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

I can't get CANRX to work in PF0

Expert 2730 points
Other Parts Discussed in Thread: TM4C123AH6PM

Hi,

Why I'm not able to get CAN to work in PF0? I'm able to change the PF0 to normal GPIO output  and also to PWM port but I can't get the CAN working. Or at least I don't get any messages or  get any interrupts for sending something. The initialization, receiving and sending works with other pins (I have made the code first for launchpad CAN0 PE4,PE5) for CAN0 and also for CAN1.

// Enable CAN0 pins PF0 and PF3
	ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF);

	// Enable CAN peripheral
	ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_CAN0);

	// Enable port PF0 for CAN0 CAN0RX
	// First open the lock and select the bits we want to modify in the GPIO commit register.
	//
	GPIO_PORTF_LOCK_R = GPIO_LOCK_KEY;
	GPIO_PORTF_CR_R = GPIO_PIN_0;
	// Enable CAN
	ROM_GPIOPinConfigure(GPIO_PF0_CAN0RX);
	// Lock the pin
	GPIO_PORTF_LOCK_R = 0;

	ROM_GPIOPinTypeCAN(GPIO_PORTF_BASE, GPIO_PIN_0);

	// Enable port PF3 for CAN0 CAN0TX
	ROM_GPIOPinConfigure(GPIO_PF3_CAN0TX);
	ROM_GPIOPinTypeCAN(GPIO_PORTF_BASE, GPIO_PIN_3);

	// Enable CAN peripheral
	ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_CAN0);

	// Initialize the CAN controller.
	ROM_CANInit(CAN0_BASE);

	// Set up the bit rate for the CAN bus.
	ROM_CANBitRateSet(CAN0_BASE, ROM_SysCtlClockGet(), baudrate);

	// Enable interrupts on the CAN peripheral.
	ROM_CANIntEnable(CAN0_BASE, CAN_INT_MASTER | CAN_INT_ERROR | CAN_INT_STATUS);

	// Enable the CAN interrupt on the processor (NVIC).
	ROM_IntEnable(INT_CAN0);

	// Enable the CAN for operation.
	ROM_CANEnable(CAN0_BASE);

What I'm doing wrong? Is there somthing missing? I'm using TM4C123AH6PM controller.

BR

JHi

  • JHi said:
    What I'm doing wrong?

    Failing to read and/or understand the GPIO section w/in MCU manual - which details the, "special default" behavior of PF0 and PD7.   You are not alone in this misfortune...

    Manual describes the necessity for - and procedure to, "unlock" that pin - so it may be repurposed to your desire.

    Or - you may avoid this extra work by using another pin (not so default encumbered)  to provide that CAN capability.   (assumes other pins carry that CAN functionality...)

  • Hi,

    Did you read my post at all? I said, I'm able to change the function to GPIO or PWM but CANRX doesn't work. I'm aware that I need to unlock the pin which you can see from the code I wrote in my post.

    BR

    JHi

  • If that unlock code was present initially - I'm completely wrong and apologize.  (I did quickly scan for unlock mention)  And - as well over 100 have past landed here - w/that exact NMI default nightmare - perhaps some of your venom should be directed to the inadequacy of the MCU manual - and not targeted to me exclusively...

    Looking again at your code - suggest:

    a) remove the initial GPIOPinConfigure from the unlock process

    b) move "ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_CAN0);" to the top of your CAN sequence

    Update: see now that you have multiple appearances of "ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_CAN0" - my fear is that the 2nd occurrence disrupts the earlier GPIOPinType & GPIOPinConfigure calls.

    c) employ your 2 GPIOPinConfigure()s back to back (only 1 pin per PinConfigure allowed

    d) then employ 1 GPIOPinType()  // you can mix multiple pins in this funct

    e) we also employ "ROM_CANBitRateSet," "ROM_CANIntEnable," "ROM_IntEnable" & "ROM_CANEnable" w/values very similar to yours.  Note that we did not employ the "ROM" version for all CAN function calls - you may wish to use the Flash version of those functions should this function continue to fail...  (I don't know if CAN functs made it safely/completely into ROM - that specific MCU)  You may also insert CANDisable() prior to any/all CAN set-up calls - to be in best compliance w/MCU safeguards.

    e) done in that manner - that order - your code closely agrees w/our "known good" CAN code.  (confirmed via Kvaser USBCan CAN Tool.

    As you report success w/CAN upon other MCUs - other boards - perhaps CAN (in that CAN0 format) is not present - that MCU - that pin?  Again - your listing - shifted into the order/format herein described - is near identical to ours which works to specification...  And - while "longshot" - certain launchpads route GPIO to GPIO (to maintain older/lesser MCU compatibility) - check board's schematic should yours be in that category...

  • Here an IAR capture (Live Watch) of an 8 byte CAN tool transmission - received by an LX4F MCU - on PF0.  (using the essence of code corrections, post above)  Note: CAN tool only displays in decimal - we set IAR to receive/display via "char."

  • Thanks for helping!

    There must have been something wrong with the hardware. We connected the CANRX pin to PB4 -> PB4 and PF0 are now connected together. I changed my code to supprot PB4 and after that everything worked. Then I tried your solution with PF0 and it was also working. Then I tried again with my original code and it was also working.

    The initialization of  ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_CAN0) two times didn't matter. I checked this and also checked if it matters if I define this at first or later in the code.

    BR

    JHi

  • I got the opposite situation as you did, I can make PF0 & PF3 work for CAN0RX & CAN0TX with two pieces of TM4C123GXL EVBs, but I cannot make PB4 & PB5 and PE4 & PE5 work.

    The possible reason for that is may because all pins on Port F have pull-up and down resistors to make them more reliable.

    Try to use API functions provided by TivaWrae Peripheral Driver Library to do unlock PF0, which is safer and easy.