Associate III

Question

My data are being send in loop despite the datas are ACK.

Forum|Forum|7 years ago
February 6, 2019
8 replies
1805 views

static void FDCAN_Config(void)
{
	FDCAN_FilterTypeDef sFilterConfig;
 
	hfdcan.Instance = FDCAN2;
	hfdcan.Init.FrameFormat = FDCAN_FRAME_CLASSIC;
	hfdcan.Init.Mode = FDCAN_MODE_NORMAL;
	hfdcan.Init.AutoRetransmission = ENABLE;
	hfdcan.Init.TransmitPause = ENABLE;
	hfdcan.Init.ProtocolException = ENABLE;
 
	hfdcan.Init.NominalPrescaler = 100;
	hfdcan.Init.NominalSyncJumpWidth = 0x8;
	hfdcan.Init.NominalTimeSeg1 = 0x0D;
	hfdcan.Init.NominalTimeSeg2 = 0x2;
 
	hfdcan.Init.MessageRAMOffset = 0;
	hfdcan.Init.StdFiltersNbr = 1;
	hfdcan.Init.ExtFiltersNbr = 0;
 
	hfdcan.Init.RxFifo0ElmtsNbr = 1;
	hfdcan.Init.RxFifo0ElmtSize = FDCAN_DATA_BYTES_8;
	hfdcan.Init.RxFifo1ElmtsNbr = 1;
	hfdcan.Init.RxFifo1ElmtSize = FDCAN_DATA_BYTES_8;
	hfdcan.Init.RxBuffersNbr = 0;
	hfdcan.Init.RxBufferSize = FDCAN_DATA_BYTES_8;
 
	hfdcan.Init.TxEventsNbr = 2;
	hfdcan.Init.TxBuffersNbr = 0;
	hfdcan.Init.TxFifoQueueElmtsNbr = 2;
	hfdcan.Init.TxFifoQueueMode = FDCAN_TX_FIFO_OPERATION;
	hfdcan.Init.TxElmtSize = FDCAN_DATA_BYTES_8;
 
	if (HAL_FDCAN_Init(&hfdcan) != HAL_OK)
	{
		/* Initialization Error */
		Error_Handler();
	}
 
	HAL_FDCAN_ConfigGlobalFilter(&hfdcan, FDCAN_ACCEPT_IN_RX_FIFO0, FDCAN_ACCEPT_IN_RX_FIFO0, ENABLE, ENABLE);
 
	/* Configure Rx filter */
	sFilterConfig.IdType = FDCAN_STANDARD_ID;
	sFilterConfig.FilterIndex = 0;
	sFilterConfig.FilterType = FDCAN_FILTER_DUAL;
	sFilterConfig.FilterConfig = FDCAN_FILTER_TO_RXFIFO1;
	sFilterConfig.FilterID1 = 0x1AA;
	sFilterConfig.FilterID2 = 0x72A;
	if (HAL_FDCAN_ConfigFilter(&hfdcan, &sFilterConfig) != HAL_OK)
	{
		/* Filter configuration Error */
		Error_Handler();
	}
 
	/* Start the FDCAN module */
	if (HAL_FDCAN_Start(&hfdcan) != HAL_OK)
	{
		/* Start Error */
		Error_Handler();
	}
 
	hfdcan.Instance->IE = 0xFFFFFFFF;
	HAL_FDCAN_ConfigInterruptLines(&hfdcan, 0xFFFFFFFF, FDCAN_INTERRUPT_LINE1);
 
	if (HAL_FDCAN_ActivateNotification(&hfdcan, 0x3FFFFFFF, 0) != HAL_OK)
	{
		/* Notification Error */
		Error_Handler();
	}
 
 
	/* Prepare Tx Header */
	TxHeader.Identifier = 0x01A;
	TxHeader.IdType = FDCAN_STANDARD_ID;
	TxHeader.TxFrameType = FDCAN_DATA_FRAME;
	TxHeader.DataLength = FDCAN_DLC_BYTES_2;
	TxHeader.ErrorStateIndicator = FDCAN_ESI_ACTIVE;
	TxHeader.BitRateSwitch = FDCAN_BRS_OFF;
	TxHeader.FDFormat = FDCAN_CLASSIC_CAN;
	TxHeader.TxEventFifoControl = FDCAN_NO_TX_EVENTS;
	TxHeader.MessageMarker = 0;
}
 
 
uint8_t BSP_CAN_Send_Data(uint8_t * data)
{
	HAL_StatusTypeDef err;
	uint32_t interruptRegister;
	/* Set the data to be transmitted */
 
	TxData[0] = *data;
	TxData[1] = 0xAE;
 
	TxData[0] = *data;
	TxData[1] = 0xAD;
	/* Start the Transmission process */
	err = HAL_FDCAN_AddMessageToTxFifoQ(&hfdcan, &TxHeader, TxData);
	if (err != HAL_OK)
	{
		/* Transmission request Error */
		printf("error HAL_FDCAN_AddMessageToTxFifoQ %d\r\n", err);
		HAL_Delay(3000);
		Error_Handler();
	}
 
}
 
void BSP_CAN_Test()
{
	uint8_t data = 0;
 
	while (1)
	{
		BSP_CAN_Send_Data(&data);
		HAL_Delay(3000);
 
		while (HAL_FDCAN_GetTxFifoFreeLevel(&hfdcan) != 2)
		{
			HAL_Delay(100);	// Stuck here as data is not considered send
		}
		data++;
	}
}

Hello,

I do have some issue having my FDCAN bus up and running. I am using STM32H750 IC with MCP2542 CAN transceiver chip. I am trying to communicate with another device on the CAN bus. I am debuggging the bus with a salae device both RxD/TxD and CANH/CANL.

I do see my data sending out and data from the other device coming in on the bus.

Here is the problem.

My data are being send in a loop despite the fact there are ACK on the bus.

I configure all interruption, and enable all callback, none is trigger except when after a long time when I deInit/Reinit the FDCAN module. In this case, TXEmpty callback is called.

I try to unplug the other device and run in Internal or External loopback mode, but it is exactly the same thing. No callback, no error, but my data being send in loop.

The other problem I am facing, is that I am enable to receive the keepalive send by the other module on the bus. I have tried so many configuration of the filters that I am pretty sure it is not the issue. Does not work in loopback mode too.

I may have miss something huge, so if you can help.

My starting code is based on the FDCAN example Classic mode of the STM32H743I_EVAL Cube example code.

Here is an extract of my code, excluded of the GPIO configuration.

FDCAN

This topic has been closed for replies.

SBACOAuthor

Associate III

here is a capture of the slaeae tool for the bus CAN. 0x1A is my data being send in loop. 72A is the data I am trying to catch.

SBACOAuthor

Associate III

Seems that I found the issue. The values for the timings were not good. I was using a website for the configuration that was posting on another post on this forum, but apparently either I do not properly understand or it does not work in my case. Anyway, I lower the frequency of the BUS CAN to 40MHz, and use those values :

hfdcan.Init.NominalPrescaler = 4; /* tq = NominalPrescaler x (1/fdcan_ker_ck) */

hfdcan.Init.NominalSyncJumpWidth = 0x8;

hfdcan.Init.NominalTimeSeg1 = 0x1F; /* NominalTimeSeg1 = Propagation_segment + Phase_segment_1 */

hfdcan.Init.NominalTimeSeg2 = 0x8;

It is now working as expected.

@ST : I am pretty that integrating a tool for this configuration in CubeMX is really good idea, it has been requested for so long... datasheet on this part is also really missing.

Regards,

arnold2

Associate

Hi,

I have the same effect here. My environment is:

STM32H743VI on a custom board
Keil uVision 5.22
H7 Cube package 1.3.0 (I have used the example FDCAN_Classic_Frame_Networking in the STM32H743I_EVAL folder and modified the controller ports)

I am not able to get the CAN controller working with 80 MHz kernel clock. The effect I see is, that the message is reepated endlessly, although it is acknowledged on the bus. The initial recommendation of the CiA was to use 80 MHz for CANFD. This is not possible with the H7. For that reason and because I have spent 2 days locating the reason for this bug, I would like to know more details related to this issue:

Is this bug known to ST? (at least it is not yet listed in the errata sheet)

Under what circuimstances can this bug occur and do I have to expect more problems (maybe sporadical errors???)

SBACOAuthor

Associate III

Did you double check the timing settings ? on my side the bit sampling time was not good, and so the HW was not able to see the ACK on the bus. Despite the frame is well formed and so ACK by the other devices on the channel. The uC needs to be able to read this ACK properly. Good luck in your research.

arnold2

Associate

I have done the same as you. I have used the bit timings calculated by the website http://www.bittiming.can-wiki.info. So bit timing shoud be ok. And it is only the prescaler, that needs to be adapted, when changing the CAN controller's kernel clock from 80 MHz to 40 MHz, so bit-timing and sample-point should be identical in both cases. In my opinion it is just the resynchronization behaviour, that is different, when using different kernel clock (jump width can be smaller with higher clock).

arnold2

Associate

I have more details.

In non-working configurations the ACT bitfield of FDCAN_PSR stays on 0x0, if INIT bit of CCCR register is cleared. This means, that the CAN controller is in a state, where it is synchronizing to the CAN bus (whatever that means in detail, maybe it is waiting for 11 recessive bits???). Neither the controller itself nor the HAL takes this into account. Both allow writing to the FIFO without error and the telegram is sent although CAN controller is still synchronizing. In working configurations the ACT bitfield changes from 0x0 to 0x1, when the INIT bit is cleared.

When I attempt to send a CAN telegram in this state, where INIT bit has been cleared, but ACT field is still 0x0, the telegram is sent repeatedly on the CAN bus, although it has been acknowledged. The TXFQS register tells me, that the telegram has not yet been removed from the FIFO, so my guess is, that for any reason the controller does not see the acknowledge bit and thus attempts to resend the telegram endlessly.

I have had a configuration, where both the CPU and the CAN controller were running on 96 MHz. If I clocked both from the same PLL (PLL1), the telegram was repeated endlessly. If CPU was running on PLL1 with 96 MHz and the CAN controller was running on PLL2 with 96 MHz, the telegram was repeated "only" 500 to 4000 times. I would guess, that both cases should behave identically, but they don't. Maybe a clock synchronization issue??

And I have had another very strange effect: CPU running on 80 MHz (PLL1) and CAN on 96 MHz (PLL2), CAN controller configured for 250 kBit with the timings from the website mentioned in one of my earlier posts. The baudrate prescaler must be 24 in this case. But that doesn't work (ACT bitfield stays 0x0). But: With a prescaler of 23 and with a prescaler of 25 the ACT bitfield changed from 0x0 to 0x1! Further investigations showed up, that the ACT bitfield seems to only change from 0x0 to 0x1, if the prescaler is NOT an integer multiple of 6 (I have not tested all values, but for 12, 24, 30 and 48 it is true)!! Unfortunately I could not reproduce this behaviour with the small Cube example, but only in the complete firmware project, I am working on.

One of my colleagues has written a firmware for the same controller, where none of those problems occured, but he ran the CPU on 384 MHz and the CAN controller on 96 MHz. I don't have the time for further investigations on this issue (there are too many configuration options). I would be interested in a statement from ST instead.

puzzles

Visitor II

Please excuse the necrobump, but I hope this helps someone.

I experienced this issue when my FDCAN clock was set too high. I erroneously believed the FDCAN peripheral was clocked by APB1, but its clock source is selected by its own mux. In my case, it defaulted to PLL1Q, which was 480 MHz. I brought that down to 120 MHz and CAN messages started being sent only once.

rammit

Senior

Thanks puzzles! You helped me fix my similar issue. I had the APB1 clock set too low.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded