Skip to main content
ajaygargnsit
ajaygargnsit
Associate II
February 13, 2018
Solved

Hello-World for CAN-Communication (with minimal setup) on Nucleo-f091rc

  • February 13, 2018
  • 7 replies
  • 1973 views
Posted on February 13, 2018 at 08:34

Hi All.

We have been trying to set up CAN-communication, and have been unsuccessful so far.

So, we are wishing to proceed in baby-steps.

As a first step, we intend to get the sending-CAN-packet working.

Firstly, is it possible to get it working with just one node on the CAN-bus?

Right now, with one board + one controller + one transceiver + one level-shifter,  we receive timeout while doing HAL_CAN_Transmit.

I can present more details, but I would be grateful for an answer to the following question first ::

Is it possible to have HAL_CAN_Transmit working without any timeout,  with just one node (the transmitting node itself) on the CAN-bus?

 

Thanks and Regards,

Ajay

    This topic has been closed for replies.
    Best answer by T J
    Posted on February 13, 2018 at 08:45

    Hi, Yes, you can have one node on a canbus network.

    Generally Nodes only transmit their data, so its quite normal for the node to transmit only.

    However,

    it is much better for you, to buy a known good transmitter, like CanDo, and set it up to send frames every 10mS,

    then you should work on the receiver first.

    I have the CanBus systems running on my '091 and '767 boards.

    I used the cube and the CanDo unit to start.

    if you don't have a canbus line driver connected, the board will hang, you need a pullup on the Rx pin.

    Rule: no two units should be able to transmit the same message ID.

    set ABOM true.

    7 replies

    T J
    T JBest answer
    Senior III
    February 13, 2018
    Posted on February 13, 2018 at 08:45

    Hi, Yes, you can have one node on a canbus network.

    Generally Nodes only transmit their data, so its quite normal for the node to transmit only.

    However,

    it is much better for you, to buy a known good transmitter, like CanDo, and set it up to send frames every 10mS,

    then you should work on the receiver first.

    I have the CanBus systems running on my '091 and '767 boards.

    I used the cube and the CanDo unit to start.

    if you don't have a canbus line driver connected, the board will hang, you need a pullup on the Rx pin.

    Rule: no two units should be able to transmit the same message ID.

    set ABOM true.

    ajaygargnsit
    ajaygargnsitAuthor
    Associate II
    February 13, 2018
    Posted on February 13, 2018 at 10:09

    Thanks T J.

    You have arrived as our Saviour !!

    Setting ABOM to ENABLE, we have made a great deal of progress.

    Earlier, when ABOM was DISABLE, we were seeing absolutely nothing on the controller/transceiver pins when sending the CAN-packet.

    Now, with ABOM set to ENABLE, we see the waveform on the controller as well the transceiver pin upon sending the CAN-packet.

    So, courtesy you, we have been able to move forward after 36 hours of slogging.

    However, HAL_CAN_Transmit (with 5-seconds timeout argument) still results in HAL_TIMEOUT.

    What could be the possible issue for this?

    Following are the two init-functions being used ::

    ###############################################################

    void MX_CAN_Init(void)

    { 

      hcan.Instance = CAN;

      hcan.Init.Prescaler = 16;

      hcan.Init.Mode = CAN_MODE_NORMAL;

      hcan.Init.SJW = CAN_SJW_1TQ;

      hcan.Init.BS1 = CAN_BS1_1TQ;

      hcan.Init.BS2 = CAN_BS2_1TQ;

      hcan.Init.TTCM = DISABLE;

      hcan.Init.ABOM = ENABLE;

      hcan.Init.AWUM = DISABLE;

      hcan.Init.NART = DISABLE;

      hcan.Init.RFLM = DISABLE;

      hcan.Init.TXFP = DISABLE;

      if (HAL_CAN_Init(&hcan) != HAL_OK)

      {

        _Error_Handler(__FILE__, __LINE__);

      } 

    }

     

    void HAL_CAN_MspInit(CAN_HandleTypeDef* canHandle)

    { 

      GPIO_InitTypeDef GPIO_InitStruct;

      if(canHandle->Instance==CAN)

      {

        __HAL_RCC_CAN1_CLK_ENABLE();

       

        /* PA11     ------> CAN_RX, PA12     ------> CAN_TX  */

        GPIO_InitStruct.Pin = GPIO_PIN_11| GPIO_PIN_12;

        GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;

        GPIO_InitStruct.Pull = GPIO_NOPULL;

        GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH;

        GPIO_InitStruct.Alternate = GPIO_AF4_CAN;

        HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

      }

    }

    ########################################################################

    Once again, thanks a ton for the quick reply, and you have re-instilled hope in us

    Will be grateful to listen more from you.

    Thanks and Regards,

    Ajay

    T J
    T J
    Senior III
    February 13, 2018
    Posted on February 13, 2018 at 13:25

    The original post was too long to process during our migration. Please click on the provided URL to read the original post. https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I6uU&d=%2Fa%2F0X0000000bxo%2F7VRNDwgTY00gXdaVr4uG9bL5eoRb5QU5PYrIPZe41h8&asPdf=false
    ajaygargnsit
    ajaygargnsitAuthor
    Associate II
    February 14, 2018
    Posted on February 14, 2018 at 07:02

    Hi T J.

    Thanks for the reply.

    So, if I understand correctly,

    * HAL_CAN_Transmit cannot be used, it will always result in timeout, right?

    * HAL_CAN_Trasnmit_IT has to be used, which need relying on interrupts (even for a purely transmitting-mode), right?

    Now, we are unable to obtain ANY interrupts, even after enabling CEC/CAN interrupt-handler.

    Absolutely nothing is being observed in CEC_CAN_IRQHandler

    Anyhow, it looks very counter-intuitive, for interrupts to be required even for pure transmitting-mode.

    It kind of defeats the purpose of HAL_CAN_Transmit method completely.

    Thanks again T J.

    Terms & ConditionsAccessibility statement