FDCAN with STM32H735

[alex31]

Hello, just tried your driver, saw one problem : there is a call to sleep in a lock zone, which is forbidden and sysHalt at exec when DEBUG is enabled.
Will comment the sleep and try to go further.
Alexandre

Code: Select all

void can_lld_transmit(CANDriver *canp, canmbx_t mailbox, const CANTxFrame *ctfp) {
  uint32_t put_index = 0;
  uint32_t *tx_address = 0;

  (void)mailbox;

  osalDbgCheck(dlc_to_bytes[ctfp->DLC] <= CAN_MAX_DLC_BYTES);

  /* Retrieve the TX FIFO put index.*/
  put_index = ((canp->fdcan->TXFQS & FDCAN_TXFQS_TFQPI) >> FDCAN_TXFQS_TFQPI_Pos);

  /* Writing frame. */
  tx_address = canp->ram_base + (SRAMCAN_TBSA + (put_index * canp->word_size));

  *tx_address++ = ctfp->header32[0];
  *tx_address++ = ctfp->header32[1];
  for (unsigned i = 0U; i < dlc_to_bytes[ctfp->DLC]; i += 4U) {
    *tx_address++ = ctfp->data32[i / 4U];
  }

  /* Starting transmission.*/
  canp->fdcan->TXBAR = ((uint32_t)1 << put_index);
  /*
   * FIXME This sleep not needed if we send two frames with different SID/EID
   *       why?
   */
  osalThreadSleepMilliseconds(1);
}


[Giovanni]

Running the code with the state checker should catch this.

Giovanni

[alex31]

Yes, it does, state checker has saved me so many times it's one of the many cool features of ChibiOS.
I enable it by default.

[Edoardo1982]

Sorry, I committed that workaround by mistake due to testing.
The demo has been tested in loop mode on STM32H750 discovery and I can see the packets. However I will double-check in case I missed any commits.

Edoardo

[Edoardo1982]

Hi, I fixed the bug related to osalThreadSleepMilliseconds.
The demo is written for the STM32H750 discovery board.
CAN1 and CAN2 are linked together.

I can see the outgoing packets correctly, and by setting a breakpoint on reception, I verify that the packets have arrived at their destination correctly.

Which board are you working on?
Maybe the CAN pins are not configured correctly?
Have you checked the hardware connections?

Edoardo

[alex31]

thanks for the info.

I use a custom design, with only pins for fdcan1 available (and I have checked that there no short or cut on the PCB), so I just use CAND1 on PD00, PD01. I can see that I loop in the send thread, but there is nothing on PD00 (CAN1_TX) although both CAN pins are configured in AF9. Today is a bit calm, I will have more time to work on it.

I use stable 21.11, with the H7 example, slightly modified to accommodate the HSE frequency of my board, and the pins used (I use a 100 pins chip).

Alexandre

[alex31]

If I monitor the status returned by canTransmit, it returns 32 times MSG_OK, then MSG_TIMEOUT, so something make the frames to accumulate in the TX fifo until it's full.

voltage levels on TX and RX stay at LEVEL_HIGH, which is the idle level for CAN, so that should not prevent CAN peripheral to transmit.

[alex31]

Found it, hardware error, the transceiver TX and RX are inverted, no rework possible, too narrow, too many layers
the block diagram of the transceiver did not help, pin labeled Rx on the transceiver block diagram is the MCU Rx (so the transceiver Tx)
Hint for hardware designers, check twice before sending your files to the PCB maker

A.

[Giovanni]

Aww, that hurts, it happened to me too in ancient times...

BTW, Edoardo does not show himself much here but he is one of the persons behind commercial ChibiOS, chief of the group doing ports and custom drivers for customers.

Giovanni

[alex31]

found a H7 devboard to continue with H7 FDCAN, and I still have some issues, with 2 nodes, one H7, one F4, H7 node is in CAN mode to be compatible with F4.

For now it works well in one direction : from M4 to F7, when I send a message from the H7, the frame is ill formed with only 8 bits.




will take one week of holidays, so will continue after holidays.
Alexandre