LM4F232H5QDF - CAN Problem with PORTN and PORTF

Can quickly/easily resolve your Port "F" mystery.   PF0 is a "special" pin - defaults as NMI and thus requires a special, "unlocking" procedure to repurpose.  Believe that PD7 behaves/responds in the identical manner.  PF0/PD7 are covered in the GPIO section of the 1400+ page datasheet - takes some "digging" to absorb...

Thanks for resolving the F0 riddle. It's also in the errata - shame on me.

I haven't tried to configure CAN0 for PORTE (E4/E5) as there is an accelerator sensor connected to those pins and I'm not ready to slaughter my evalkit, yet.

Norbert Melinat said:

I'm not ready to slaughter my evalkit, yet.

Well played, mon ami.  1400+ pgs does "dull" the mind - and who (really) reads errata?   Love your use of the operative word, "yet!"  Slaughter very much in the cards unless hyped new board (I recall only picture of a header - MCU nowhere in evidence/display) may suit your purpose.  Bon chance...

Glanced quickly @ your code - don't like:

ROM_CANIntEnable(CAN0_BASE, CAN_INT_MASTER|CAN_INT_ERROR|CAN_INT_STATUS);
ROM_GPIOPinConfigure(GPIO_PB4_CAN0RX);

Believe it bad form to enable the interrupt in advance of full/proper Port & Pin Set-Ups/Configs.  If I get time later I'll revisit your Port N issue - although as you have one port working you should be able to make that repair...

Further - to reduce your "wear/tear" - you may mingle multiple pins w/in GPIOPinType - but not for GPIOPinConfigure!  (joy of inconsistency...)

ROM_GPIOPinTypeCAN(GPIO_PORTN_BASE, GPIO_PIN_0);
ROM_GPIOPinTypeCAN(GPIO_PORTN_BASE, GPIO_PIN_1);
may be replaced by:
ROM_GPIOPinTypeCAN(GPIO_PORTN_BASE, GPIO_PIN_0 | GPIO_PIN1);

Just noted the following after rapid-fire "read" of SW-DRL-UG:

Also, if the same signal (i.e. CAN0RX)  is assigned to two different GPIO port pins, the signal is assigned to the port with the lowest letter and the assignment to the higher letter port is ignored.   Should your code have been compiled as listed (both Port B and Port N - and this we do not know) - this may explain.

And - have you reviewed Eval Board schematic - to insure that no "other" board use of PN0 may cause conflict?

I tried different PORT configurations separately. I haven't tried to use PORTB and PORTN at the same time. PORTB configuration works, PORTN and PORTF don't. For PORTF I know now why (needs to be unlocked, first). I haven't tried PORTE, yet.

Checked the board schematics, again. The board is the TI LM4F232 eval kit board. PORTN pins are directly routed to header pins on the side of the board, no other on-board peripherals to interfere with. I used an oscilloscope to verify that the TTL-RX/TX signals of the CAN-transceiver actually end up on  the N0/N1 pins of the MCU. They actually do, but somehow that RX-signal is not routed to the CAN peripheral inside. When I enable LOOPBACK mode I do see a TX-signal on N1. There's something wrong with the routing of N0. I also checked the PORTN GPIO register. Looks ok to me.

Has anybody actually made CAN0 work on PORTN?

Not to overly beat this, "dead horse" but would you be good enough to detail just how you test/verified Port_B Can_RX operation?  If possible - I will try to duplicate your set-up - and then report.  Must say - your initial code post does not reveal Port_N to be fully "duplicative" of Port_B.  Would be most useful if you'd provide as exact a listing as possible to insure our optimal test agreement.

Should you have earlier "tested" by "looping back" I suspect failure of the higher lettered CAN Ports is explained by my last post...  (test should have looped CAN0 to CAN1 !)

CAN-Setup: The MCU's CAN interface is connected to a TI-VP232 CAN Transceiver. The Transceiver is powered by the board's 3.3V Vcc line. The Transceiver CAN-H/L line is connected to the CAN-Bus. The CAN-Bus is made by two nodes: First node is the MCU/Transceiver combination, the second node is a Vector CANcaseXL device. The CAN-Bus is terminated by a 120Ohm Resistor. The Baudrate is 500kBit/s. The CANcaseXL device is connected to a PC running the Vector CANoe Application. I use this application to trace CAN activities and run a CAN-Restbus-Simulation that emulates some other ECU that send/receive messages to and from the MCU.

My actual program code for CAN0/PORTB (works!) is

    template<>
    Stellaris_CAN_node<CAN0_BASE, GPIO_PORTB_BASE>::Stellaris_CAN_node(Timer& timer, CAN_transceiver* t, uint32_t btr)
    : Stellaris_CAN_node_base(CAN0_BASE, timer, t, btr)
    {
        if (! s_instance) {
            ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_CAN0);
            ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB);
            ROM_GPIOPinConfigure(GPIO_PB4_CAN0RX);
            ROM_GPIOPinTypeCAN(GPIO_PORTB_BASE, GPIO_PIN_4);
            ROM_GPIOPinConfigure(GPIO_PB5_CAN0TX);
            ROM_GPIOPinTypeCAN(GPIO_PORTB_BASE, GPIO_PIN_5);
            Stellaris_CAN_node_base::reset();
            ROM_IntEnable(INT_CAN0);
            s_instance = this;
        } else {
            std::abort(); // Already instantiated
        }
    }

The code for CAN0/PORTN (does not work) is:

    template<>
    Stellaris_CAN_node<CAN0_BASE, GPIO_PORTN_BASE>::Stellaris_CAN_node(Timer& timer, CAN_transceiver* t, uint32_t btr)
    : Stellaris_CAN_node_base(CAN0_BASE, timer, t, btr)
    {
        if (! s_instance) {
            ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_CAN0);
            ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPION);
            ROM_GPIOPinConfigure(GPIO_PN0_CAN0RX);
            ROM_GPIOPinTypeCAN(GPIO_PORTN_BASE, GPIO_PIN_0);
            ROM_GPIOPinConfigure(GPIO_PN1_CAN0TX);
            ROM_GPIOPinTypeCAN(GPIO_PORTN_BASE, GPIO_PIN_1);
            Stellaris_CAN_node_base::reset();

          HWREG(CAN0_BASE + CAN_O_CTL) |= CAN_CTL_TEST;
          HWREG(CAN0_BASE + CAN_O_TST) |= CAN_TST_LBACK; // Enable loopback to see any TX messages on the bus
            ROM_IntEnable(INT_CAN0);
            s_instance = this;
        } else {
            std::abort(); // Already instantiated
        }
    }

The reset() function is the same for both cases and is:

    void Stellaris_CAN_node_base::reset(void) {
        ROM_CANInit(get_base_addr());
        ROM_CANBitRateSet(get_base_addr(), ROM_SysCtlClockGet(), get_bitrate());
        ROM_CANIntEnable(get_base_addr(), CAN_INT_MASTER|CAN_INT_ERROR|CAN_INT_STATUS);
        ROM_CANEnable(get_base_addr());
    }

My personal theory on why the loopback trick is working, is that the CAN-Controller waits to detect a recessive state on the bus before sending any messages. Without a loopback the CAN-controller detects only a dominant state, that prevents any messages to send. With loopback enabled the CAN-Controller detects a recessive state and actually start to send messages on the bus. Then I see the messages on the bus. Anyway, even with loopback enabled, I do not receive any messages sent by other nodes on the BUS. Pin N0 does not seem to be connected internally to the CAN0 peripheral.

Norbert Melinat said:

I have pulled a Stop-Loss on this issue

That's probably wise - and too rarely seen this/other forums.  Business case should always intrude - too often is afterthought - firms/individuals thus suffer.

Thanks your kindness - this reporter became aware of, "Peripheral satisfaction via multi-port, pin harvest" after close, repeated read of ARM (non MCU vendor specific) docs - and achieved/confirmed such capability - first on another vendor's ARM.  Few months later, "red garbed FAE's arrived" - I duly "asked" about this technique - silence - very limited vendor recognition - "no comment"...  thus "first such recognition" awards to famed, "NIH"!   (this is documented w/in multiple emails) 

Such thoughtful, "Peripheral Pin Selection" is a powerful technique - can enable much smaller, lower cost MCUs to replace, "less crafted" larger ones.