Debug bus CAN on a STM32F767 Nucleo 144

[joaquin]

I'd would appreciate any help on this problem, as I've run out of ideas to solve it: I have developed a plugin board for a STM32F767 Nucleo-144; everything worked as designed, except for the CAN bus. I use PD0 (CAN1RX) and PD1 (CAN1TX) pins, and a MCP2551 for the interface.
There are no signals on the bus, but it works when in loopback (I receive frames). According to the reference manual, in loopback mode the TX signals should be shown at the TX pin, however there isn't any signal even with the board unplugged.
It seems a problem with the pin configuration, but I can't see it.

The basic code to test the loopback is:

Code: Select all

static const CANConfig cancfg = {
  CAN_MCR_ABOM | CAN_MCR_AWUM | CAN_MCR_TXFP,
  CAN_BTR_LBKM | CAN_BTR_SJW(0) | CAN_BTR_TS2(1) |
  CAN_BTR_TS1(8) | CAN_BTR_BRP(6)
};
void testCAN(void)
{
   CANTxFrame txmsg;
   float valor = 3.45;
   palClearPad(GPIOD, GPIOD_CAN1_TX);
   palSetPad(GPIOD, GPIOD_CAN1_RX);
   palSetPadMode(GPIOD, GPIOD_CAN1_RX, PAL_STM32_ALTERNATE(9));
   palSetPadMode(GPIOD, GPIOD_CAN1_TX, PAL_STM32_ALTERNATE(9));
   palSetPadMode(GPIOD, GPIOD_CAN1_EN, PAL_MODE_OUTPUT_PUSHPULL);
   palClearPad(GPIOD, GPIOD_CAN1_EN);
   canStart(&CAND1, &cancfg);
   canStart(&CAND2, &cancfg);
   txmsg.IDE = CAN_IDE_STD;
   txmsg.RTR = CAN_RTR_DATA;
   txmsg.DLC = 4;
   txmsg.EID = 7;
   for (;;)
   {
      memcpy(txmsg.data32,(void *) &valor, 4);
      canTransmit(&CAND1, CAN_ANY_MAILBOX, &txmsg, TIME_MS2I(100));
      osalThreadSleepMilliseconds(100);
   }
}

[Giovanni]

Hi,

This is most likely a GPIO settings issue.

You need to make sure that your CAN pins are assigned the proper alternate function in board.h, in addition, make sure that CAN is assigned to only one set of pins (each CAN signal must be assigned to a single GPIO, not multiple).

Giovanni

[joaquin]

Good point, Giovanni: I used to define both at board.h and on the initialization code, the pin configuration; I didn't have duplication, but once I have removed the initialization from the code, I have started to see frames.

It's interesting that for other ports (i2c, USART,..) this method didn't cause me so many headaches.

Thanks a lot, your help has been extremely useful!

[alex31]

It's probably due to the fact that you use the wrong macro, the one to use is PAL_MODE_ALTERNATE (exported, documented) , not PAL_STM32_ALTERNATE (private).

The definition of the macros explain themselves the problem better than i can do

Code: Select all

#define PAL_STM32_ALTERNATE(n)          ((n) << 7U)

/**
 * @brief   Alternate function.
 *
 * @param[in] n         alternate function selector
 */
#define PAL_MODE_ALTERNATE(n)           (PAL_STM32_MODE_ALTERNATE |         \
                                         PAL_STM32_ALTERNATE(n))
/** @} */

Alexandre

[joaquin]

You are right. In the rest of pin initialization I've used the correct macro PAL_MODE_ALTERNATE...