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

[ajaygargnsit]

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

[T J · Accepted solution]

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]

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]

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]

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.

[ajaygargnsit]

Posted on February 14, 2018 at 07:47

Hi T J.

The CEC_CAN_IRQHandler is being hit now (earlier there were some eclipse-breakpoints issue; sorry for the noise).

Now, after calling HAL_CAN_Trasnmit_IT, the CEC_CAN_IRQHandler is hit once (as expected), but we get the following (ORed) errors ::

HAL_CAN_ERROR_EWG

HAL_CAN_ERROR_EPV

HAL_CAN_ERROR_BOF

HAL_CAN_ERROR_BD

As a result, transmission-complete is not being marked.

What can be done at hardware/software to not have these errors. and mark the transmission as successful?

Once again, thanks for your quick replies and help.

Thanks and Regards,

Ajay

[T J]

Posted on February 15, 2018 at 02:42

Hi, are you still using just one unit on the canbus ?

do you have a line driver ?

is it terminated with at least 1 resistor 120R ?

Then everything worked, I actually didn't enable all those interrupts.

HAL_CAN_ERROR_EWG

HAL_CAN_ERROR_EPV

HAL_CAN_ERROR_BOF

HAL_CAN_ERROR_BD

[ajaygargnsit]

Posted on February 15, 2018 at 07:50

Hi T J.

Now, CAN-packet sending is working.

We setup a board as the receiving-node. This board has Linux-Kernel with Flexcan1-controller enabled. And we use SocketCAN APIs to receive CAN-frames.

With the above (correctly working) receiving-node set up, HAL_CAN_Transmit (synchronous version only) returned success, and the packet was successfully received at the receiving-node.

If this receiving-node is not set up, we get HAL_TIMEOUT in HAL_CAN_Transmit as usual on the transmitting-node.

T J,

We are really grateful for your sincere, quick, to-the-point help.

Thanksss a tonnnnn !!!

Thanks and Regards,

Ajay