cancel
Showing results for 
Search instead for 
Did you mean: 

I can’t start the CAN module on STM32F103C8 in normal mode

SMarc.3.323
Associate II

when I run the CAN module in loopback mode - packets

 transferred to the bus - everything is OK

when I run the CAN module in silent mode I will receive packets - everything is OK

but when I start the CAN module in normal mode - 15 pulses go out on the TX pin and everything stops ... packets are not transmitted ...

what am I doing wrong???

I generated the start configuration using:

STM32CubeMX 5.6.1

Firmwere STM32Cube FW_F1 V1.8.0

Atollic TrueSTUDIO Version: 9.3.0 Build id: 20190212-0734

I've been in conjunction with both ISO1050 and MCP2551 ...

I looked at the bus using a Chinese logic analyzer ....

connected to the parallel of RX and TX pins

Code:

/* Private define ------------------------------------------------------------*/

/* USER CODE BEGIN PD */

#define TxBroadcastVoltagIdentifier 0x5FF400C

#define TxDeviceRegistrationFeedbeckIdentifier 0x5004804

#define TxSetDefaultVoltageIdentifier 0x5FF400C

/* USER CODE END PD */

/* Private variables ---------------------------------------------------------*/

CAN_HandleTypeDef hcan;

/* USER CODE BEGIN PV */

CAN_FilterTypeDef FlatPackRXFilter;

CAN_RxHeaderTypeDef RxHeader;

uint8_t RxData[16];

uint32_t RxFifo;

CAN_TxHeaderTypeDef TxHeader;

uint8_t TxData[16];

uint32_t TxFifo;

uint8_t test;

/* USER CODE END PV */

int main(void)

{

 /* USER CODE BEGIN 1 */

 /* USER CODE END 1 */

 /* MCU Configuration--------------------------------------------------------*/

 /* Reset of all peripherals, Initializes the Flash interface and the Systick. */

 HAL_Init();

 /* USER CODE BEGIN Init */

 /* USER CODE END Init */

 /* Configure the system clock */

 SystemClock_Config();

 /* USER CODE BEGIN SysInit */

// hcan.Instance->BTR &= ~CAN_MCR_SLEEP;

 // hcan.Instance->MSR = CAN_MSR_SLAK;

 /* USER CODE END SysInit */

 /* Initialize all configured peripherals */

 MX_GPIO_Init();

 MX_CAN_Init();

 /* USER CODE BEGIN 2 */

 FlatPackRXFilter.FilterBank = 0;

 FlatPackRXFilter.FilterActivation = CAN_FILTER_ENABLE ;

 FlatPackRXFilter.FilterFIFOAssignment = CAN_FILTER_FIFO0;

 FlatPackRXFilter.FilterIdHigh = 0;

 FlatPackRXFilter.FilterIdLow = 0;

 FlatPackRXFilter.FilterMaskIdHigh = 0;

 FlatPackRXFilter.FilterMaskIdLow = 0;

 FlatPackRXFilter.FilterMode = CAN_FILTERMODE_IDMASK;

 FlatPackRXFilter.FilterScale = CAN_FILTERSCALE_32BIT;

 if (HAL_CAN_ConfigFilter(&hcan, &FlatPackRXFilter) != HAL_OK)

 {

  Error_Handler();

 }

 if (HAL_CAN_Start(&hcan) != HAL_OK)

 {

  Error_Handler();

 }

 if (HAL_CAN_ActivateNotification(&hcan, CAN_IT_RX_FIFO0_MSG_PENDING) != HAL_OK)

 {

  Error_Handler();

 }

 if (HAL_CAN_ActivateNotification(&hcan, CAN_IT_RX_FIFO0_OVERRUN) != HAL_OK)

 {

Error_Handler();

 }

 TxHeader.ExtId = TxBroadcastVoltagIdentifier;

 TxHeader.DLC = 8;

 TxHeader.IDE = CAN_ID_EXT;

 TxHeader.RTR = CAN_RTR_DATA;

 TxHeader.TransmitGlobalTime = DISABLE;

 HAL_Delay(100);

 TxData[0]=0x32;

 TxData[0]=0xF0;

 if (HAL_CAN_AddTxMessage(&hcan, &TxHeader, TxData, &TxFifo) != HAL_OK)

 {

  Error_Handler();

 }

 /* USER CODE END 2 */

 /* Infinite loop */

 /* USER CODE BEGIN WHILE */

 while (1)

 {

  /* USER CODE END WHILE */

  /* USER CODE BEGIN 3 */

 test = HAL_CAN_AddTxMessage(&hcan, &TxHeader, TxData, &TxFifo);

 if (test != HAL_OK)

 {

  Error_Handler();

 }

 HAL_Delay(100);

 }

 /* USER CODE END 3 */

}

/* USER CODE BEGIN 4 */

void HAL_CAN_RxFifo0MsgPendingCallback(CAN_HandleTypeDef *hcan)

{

if (HAL_CAN_GetRxMessage(hcan, RxFifo, &RxHeader, RxData) != HAL_OK)

{

Error_Handler();

}

}

/* USER CODE END 4 */

1 ACCEPTED SOLUTION

Accepted Solutions
SMarc.3.323
Associate II

found what was the problem ... my mistake with the power supply of the can transceivers (MCP2551 needs 5V, ISO1050 needs power from both sides)

since all that comes to the input of TX CAN tansiver is immediately "exits" from the output of the RX CAN transceiver, then when the microcontroller sends a Packet to the TX channel, he expects to see this parcel at the RX input .... if it does not see this packet (the first bit of the packet) it immediately interrupts the transmission and sets the "Bit dominant Error" flag, which is not described in any way in the Reference manual on STM32f103

View solution in original post

4 REPLIES 4
Jack Peacock_2
Senior III

Check the CAN status registers to determine why TX stopped. You may have a problem with bit timing.

Does the HAL routine check for an available TX mailbox? I don't use HAL or LL drivers.

Jack Peacock

SMarc.3.323
Associate II

in CAN_ESR register the error "Bit dominant Error"

I did not find the description of this error in a datas ...

CAN_ESR 0xf80057

REC 0x0

TEC 0xF8

LEC 0x5

BOFF 0x1

EPVF 0x1

EWGF 0x1

the drawdowns that I observed (screenshot in the first post) are attempts to send messages ... it's clearly visible if you run the commands step by step in the debugger mode ... if you run the program on a looped execution then an error occurs sending messages in all buffers ... which causes the transmitter to stop .... it is not clear why, instead of normal messages, only one pulse passes ...

there is an assumption that due to the fact that the transceiver is on a separate board and connects to the microcontroller via wires, the synchronization process with ... the receiver ?? .... failed ... maybe there is a problem in the length of the wires between the receiver and the MCU (approximately 2000 mm)....

from datasheet:

"Once 11 consecutive recessive bits have been monitored on the Rx signal the CAN hardware is synchronized and

ready for transmission and reception. "

SMarc.3.323
Associate II
SMarc.3.323
Associate II

found what was the problem ... my mistake with the power supply of the can transceivers (MCP2551 needs 5V, ISO1050 needs power from both sides)

since all that comes to the input of TX CAN tansiver is immediately "exits" from the output of the RX CAN transceiver, then when the microcontroller sends a Packet to the TX channel, he expects to see this parcel at the RX input .... if it does not see this packet (the first bit of the packet) it immediately interrupts the transmission and sets the "Bit dominant Error" flag, which is not described in any way in the Reference manual on STM32f103