MX init, USER CODE AREA

[thehilde]

There are two regions to initialize but none before the call. The best solution is to use Init 0, write everything yourself and use return to skip the rest. In this case you are no longer syncron to the Cube project settings. Are there suggestions to make the initialization parameterizable, for example changing the baud rate? Maybe a init struct that you can adjust to your needs instead of void. I have the same problem with Ethernet when dynamically changing the IP address

static void MX_CAN2_Init(void) { / USER CODE BEGIN CAN2_Init 0 /

/ USER CODE END CAN2_Init 0 /

/ USER CODE BEGIN CAN2_Init 1 /

/ USER CODE END CAN2_Init 1 / hcan2.Instance = CAN2; hcan2.Init.Prescaler = 42; hcan2.Init.Mode = CAN_MODE_NORMAL; hcan2.Init.SyncJumpWidth = CAN_SJW_3TQ; hcan2.Init.TimeSeg1 = CAN_BS1_5TQ; hcan2.Init.TimeSeg2 = CAN_BS2_2TQ; hcan2.Init.TimeTriggeredMode = DISABLE; hcan2.Init.AutoBusOff = ENABLE; hcan2.Init.AutoWakeUp = DISABLE; hcan2.Init.AutoRetransmission = ENABLE; hcan2.Init.ReceiveFifoLocked = DISABLE; hcan2.Init.TransmitFifoPriority = DISABLE; if (HAL_CAN_Init(&hcan2) != HAL_OK) { Error_Handler(); } / USER CODE BEGIN CAN2_Init 2 /

/ USER CODE END CAN2_Init 2 /

---

Sugestion: double slash comment for USER CODE Area to disable a block of Cube code

// USER CODE BEGIN CAN2_Init 1 /* // USER CODE END CAN2_Init 1

Cubic Code disableb by USER

// USER CODE BEGIN CAN2_Init 1 */

my code // USER CODE END CAN2_Init 1

[DeeFuse]

I like the idea of using double slasch comments for the USER CODE.

You can use #if statements in the meantime:

/* USER CODE BEGIN CAN2_Init 1 */
#if 0
/* USER CODE END CAN2_Init 1 */

Cubic Code disableb by USER

/* USER CODE BEGIN CAN2_Init 1 */
#endif

my code
/* USER CODE END CAN2_Init 1 */

[ASELSTM]

Hi @thehilde,

The point you reported is actually related to the CubeMX generation problem and not to the firmware published in this repository. Unfortunately, we don't treat aspect related to CubeMX tool in our GitHub repositories. They are rather treated at the STM32CubeMX dedicated page of the ST Community .

Since this issue is not directly related to the STM32Cube firmware but rather to our ecosystem, please allow me then to close this thread. Thank you for your comprehension.

With regards,