Hal can stm32 обработка ошибок

Один из немаловажных аспектов работы CAN шины является обработка прерываний bxCan. Их не так уж и много, но при правильной их настройке и обработке мы сможем обеспечить максимальную работоспособность и высокую отказоустойчивость нашего устройства. Поэтому следует обратить наше внимание на то, как это сделать правильно — создать необходимый минимум.

Теория

Начнем опять с теории и обратимся к Reference Maanual от ST Microelectronics.

Для начала мы попытаемся разобраться с механизмом прерываний микроконтроллера STM32F103C6, затем пройдемся по регистрам контроллера и, затем, выстроим некий шаблон, который мы сможем использовать в своих проектах.

Прерывания

Для bxCan может быть назначено четыре прерывания. Каждый из источников прерываний может быть включен или выключен независимо друг от друга в регистре CAN_IER (CAN Interrupt Enable Register).

Вот схема отработки прерываний приведенная в мануале:

Рис. 1. Флаги событий и формирование прерываний

Как видим на рисунке 1, прерывания сгруппированы в четыре группы:

• Transmit interrupt  (Прерывание при передаче сообщения) — может быть вызвано следующими событиями:

— Выполнена передача и освобожден mailbox 0. Бит RQCP0 в регистре CAN_TSR установлен;
— Выполнена передача и освобожден mailbox 1. Бит RQCP1 в регистре CAN_TSR установлен;
— Выполнена передача и освобожден mailbox 2. Бит RQCP2 в регистре CAN_TSR установлен.

• FIFO0 interrupt (Прерывание связанное с входящим буфером FIFO0) — вызывается по следующим событиям:

— Прием нового сообщения, биты FMP0 в регистре CAN_RF0R не равны «00». В принципе значение этого регистра говорит нем о том, сколько сообщений в буфере FIFO еще не обработано программой;
— Буфер FIFO0 заполнен. Бит FULL0  в регистре CAN_RF0R установлен — сообщает нам о том, что в буфере FIFO0 больше нет свободного места;
— Переполнение буфера FIFO0. Бит FOVR0 в регистре CAN_RF0R установлен — возникает в случае когда буфер FIFO0 заполнен и по шине принято еще одно сообщение. Что с этим сообщением произойдет, мы указываем в настройках инициализации CAN (параметр CAN_RFLM).

• FIFO1 interrupt (Прерывание связанное с входящим буфером FIFO1) — вызывается по следующим событиям:

— Прием нового сообщения, биты FMP1 в регистре CAN_RF1R не равны «00». В принципе значение этого регистра говорит нем о том, сколько сообщений в буфере FIFO еще не обработано программой;
— Буфер FIFO1 заполнен. Бит FULL1  в регистре CAN_RF0R установлен — сообщает нам о том, что в буфере FIFO1 больше нет свободного места;
— Переполнение буфера FIFO1. Бит FOVR1 в регистре CAN_RF0R установлен — возникает в случае когда буфер FIFO1 заполнен и по шине принято еще одно сообщение. Что с этим сообщением произойдет, мы указываем в настройках инициализации CAN (параметр CAN_RFLM).

 • Error and Status change Interrupt (Прерывание по возникновению ошибок и изменению состояния bxCAN) — вызывается по следующим событиям:

— Возникновение ошибки. Информация об ошибке хранится в регистре CAN Error (CAN_ESR);
— «Просыпание» контроллера — выход из режима сна, когда на Rx появился сигнал CAN шины;
— Переход в спящий режим.

Четвертая группа отвечает за прерывания не только ошибок, но, как видно из названия, и за изменения статуса (режима) bxCan. 

Регистры

Полное описание регистров bxCan я приведу в отдельной статье, здесь же мы коснемся лишь некоторых из них, которые непосредственно рассматриваются в рамках данной статьи.

Для того, чтобы мы смогли программно обработать прерывания bxCan, необходимо изучить регистры микроконтроллера, которые непосредственно связаны с этими прерываниями. Разработчики ST Microelectronix постарались для нас и большинство функционала для работы CAN шины возложили на аппаратную часть микроконтроллера, но все же нам придется выполнить некоторые действия самостоятельно.

За обработку ошибок, включение/выключение прерываний CAN шины, а также за информацию о текущем статусе шины и ошибок в bxCan отвечают шесть регистров, которые мы сейчас и изучим:

CAN master status register (CAN_MSR)

Один из основных регистров bxCAN. Он отображает текущее состояние CAN устройства и позволяет программному обеспечению контролировать более детально работу bxCan. 
В большинстве случаев нет необходимости досконально контролировать аппаратную часть, сама bxCan превосходно с этим справляется, но в некоторых случаях будет полезно понимать предоставленные нам возможности и инструменты.

CAN Master Status Register предоставляет нам информацию о том, в каком состоянии находится bxCan и сообщает нам о прерываниях, если они установлены.

Рис. 2. CAN master status register.

Address offset: 0x04
Reset value: 0x0000 0C02

CAN transmit status register (CAN_TSR)

Этот регистр позволяет нам узнать текущее состояние передачи данных в шину. Из него мы можем получить информацию о количестве исходящих сообщений, заполненности почтовых ящиков, узнать о том, отправлено ли нами сообщение или произошла ошибка, а также позволяет нам прервать отправку пакета, если мы почему-то передумали это делать.

Рис. 3. CAN transmit status register.

Address offset: 0x08
Reset value: 0x1C00 0000

Как правило необходимости напрямую обращаться к этому регистру у нас не будет — можно полностью доверится bxCan. Я вижу потребность в его чтении только в очень сложных проектах, где часть функционала ложится не только на аппаратную часть, но и на программную. Также может потребоваться в случаях, когда необходимо использовать парсер CAN-шины — необходимо более детальное изучение ошибок передачи данных, логирование всего и вся.

Для обработки прерываний передачи сообщений необходимо разрешить прерывание при отправке почтового сообщения (CAN_IT_TME) и, соответственно, добавить это обработчик этого прерывания в тело программы (USB_HP_CAN1_TX_IRQHandler()).

CAN receive FIFO 0 register (CAN_RF0R)

Первый из двух регистров, отвечающих за буфер входящих сообщений FIFO 0.

Из этого регистра мы можем узнать количество почтовых сообщений, а также текущее состояние буфера FIFO 0.

Рис. 4. CAN receive FIFO 0 register.

Address offset: 0x0C
Reset value: 0x0000 0000

Обработка прерываний для буфера FIFO 0 происходит в функции USB_LP_CAN1_RX0_IRQHandler(). В ней необходимо обработать получение почтовых сообщений, а также проверить состояние ошибок (заполнение или переполнение буфера FIFO 0). Естественно, необходимо включить эти прерывания при настройке bxCan.

Необходимо помнить, что биты FOVR0 и FULL0 сбрасываются вручную. 

CAN receive FIFO 1 register (CAN_RF1R)

А это второй регистр, предназначенный для чтения состояния буфера входящих сообщений, но уже для FIFO 1.

Из него мы также можем почерпнуть информацию о  том, сколько сообщений у нас хранится и текущий статус самого буфера FIFO 1.

Рис. 5. CAN receive FIFO 1 register.

Address offset: 0x10
Reset value: 0x0000 0000

Для обработки прерываний для буфера FIFO 1 необходимо включить обработку этих прерываний при настройке bxCan и вставить в модуль функцию CAN1_RX1_IRQHandler(). Также как и с буфером FIFO 0, мы можем в обработчике прерываний выполнить обработку получения почтового сообщения в буфер FIFO 1, а также проверить состояние ошибок буфера и сбросить их после обработки.

Также напомню о необходимости сбрасывать биты FOVR1 и FULL1 вручную.

CAN interrupt enable register (CAN_IER)

Мы добрались до регистра, который непосредственно отвечает за включение прерываний bxCAN. Установив необходимые нам биты, мы сможем выполнить обработку прерываний. Напомню, что включение прерываний само по себе недостаточно, необходимо еще и включить сами прерывания и добавить их обработчики в тело программы, иначе наша программа при возникновении прерывания перейдет в прерывание по умолчанию и просто «зависнет». Но об этом поговорим чуть ниже, где я приведу несколько примеров.

Итак, нам необходимо включить прерывания. Сделать это мы можем установив соответствующие биты в регистре CAN interrupt enable register (CAN_IER).

Рис. 6. CAN interrupt enable register.

Address offset: 0x14
Reset value: 0x0000 0000

Если Вы новичок и только начинаете изучать протокол CAN  и его использование на микроконтроллерах семейства STM32, то можно ограничиться одним прерыванием FMPIE0 (FIFO 0 message pending interrupt) и TMEIE (Transmit mailbox empty interrupt), которые отвечает за обработку получения входящего пакета в буфер FIFO 0, а также за обработку окончания отправки пакета в шину соответственно. Для первоначального изучения и тестирования этого вполне хватит, а дальше уже требуется более глубокое понимание физики процессов и специфики работы CAN шины.

CAN error status register (CAN_ESR)

Регистр отвечает за состояние ошибок при работе с bxCan.

Управление ошибками, как описано в протоколе CAN, обрабатывается полностью аппаратными средствами с помощью счетчиков ошибок передачи (TEC — Transmit error counter) и счетчиков ошибок приема сообщений (REC — Receive error counter), которые увеличивают или уменьшают свое значение в соответствии с состоянием ошибки.

Оба счетчика могут быть прочитаны с помощью программного обеспечения, чтобы определить стабильность сети.

Кроме того, аппаратное обеспечение может предоставлять более подробную информацию о текущем состоянии ошибок (LEC — Last error code).

Рис. 7. CAN error status register.

Address offset: 0x18
Reset value: 0x0000 0000

Согласно описанию протокола CAN принято увеличивать счетчик ошибок REC (Receive error counter) на одну единицу при каждой обнаруженной ошибке приема на шине, а счетчик ошибок TEC (Transmit error counter) увеличивать на 8 при каждой ошибке передачи пакетов. Это связано стем, что существует предположение о том, что с наибольшей вероятностью источником ошибок на шине является передающий узел. 

Уменьшение счетчика ошибок происходит автоматически на единицу при каждом успешном приеме или передаче сообщений по шине для счетчиков REC и TEC соответственно.

Восстановление BUS-OFF

Состояние шины Bus-Off устанавливается, когда счетчик ошибок передачи превышает 255, при этом устанавливается бит BOFF регистра CAN_ESR. В этом режиме bxCan фактически перестает принимать и передавать пакеты по шине.

При настройке bxCAN можно установить бит ABOM, который отвечает за то, что если шина перейдет в режим Bus-off, то bxCan автоматически начнет проверять сигнал CAN_RX для восстановления шины. Если бит ABOM не установлен, то разработчику необходимо контролировать этот процесс самостоятельно и в случае возникновения ошибки и перехода в режим Bus-off необходимо заново проинициализировать bxCan.

Обратите внимание, что bxCan слушает порт CAN_RX только в нормальном режиме работы. Если bxCan находится в режиме инициализации, то автоматического восстановления шины не произойдет.

Долгое время не мог понять, что это за 11 рецессивных бит 128 раз подряд и где их необходимо взять и куда подать. Путем гугления и раскурки мануалов понял, что это указывается время, через которое контроллер CAN шины автоматически выйдет из режима Bus-Off и оно равно времени, которое потребуется для передачи 11 рецессивных бит 128 раз подряд.

Другими словами, контроллер автоматически выйдет из режима Bus-Off, когда на CAN шине будет «тишина» в течении времени, равному времени передачи 11 бит * 128 раз. Естественно, если в настройках контроллера мы ему указали, что он может автоматически выходить из этого режима (установлен бит ABOM регистра CAN_MCR).

Практика

Вроде все моменты, которые касаются обработки прерываний bxCan мы рассмотрели. Текста очень много, но как это применить на практике?

Давайте разбираться.

Для начала нам необходимо определится с тем, какие прерывания bxCan мы будем использовать. Конечно можно ограничиться прерыванием на получение сообщения в буфер FIFO, но мы же не ищем легких путей, поэтому проинициализируем сразу все.

За включение/отключение прерываний bxCan отвечает функция CAN_ITConfig, эти действия выполняются в модуле инициализации can шины совместно с настройкой прерываний NVIC:

Листинг №1. Включение прерываний bxCan
	// CAN Transmit mailbox empty Interrupt enable
	// Обрабатывается в прерывании USB_HP_CAN1_TX_IRQHandler
	CAN_ITConfig(CAN1, CAN_IT_TME, ENABLE);         // Прерывание при освобождении исходящего почтового ящика
	// CAN Receive Interrupt enable
	// Обрабатывается в прерывании USB_LP_CAN1_RX0_IRQHandler
	CAN_ITConfig(CAN1, CAN_IT_FMP0, ENABLE);        // Прерывание получения пакета в буфер FIFO 0
	CAN_ITConfig(CAN1, CAN_IT_FF0, ENABLE);         // Прерывание при заполнении буфера FIFO 0
	CAN_ITConfig(CAN1, CAN_IT_FOV0, ENABLE);        // Прерывание при переполнении буфера FIFO 0
 
	// Обрабатывается в прерывании CAN1_RX1_IRQHandler
	CAN_ITConfig(CAN1, CAN_IT_FMP1, ENABLE);        // Прерывание получения пакета в буфер FIFO 1
	CAN_ITConfig(CAN1, CAN_IT_FF1, ENABLE);         // Прерывание при заполнении буфера FIFO 1
	CAN_ITConfig(CAN1, CAN_IT_FOV1, ENABLE);        // Прерывание при переполнении буфера FIFO 1
 
	// CAN Operating Mode Interrupt enable
	// Обрабатывается в прерывании CAN1_SCE_IRQHandler
	CAN_ITConfig(CAN1, CAN_IT_WKU, ENABLE);         // Прерывание при "пробуждении" - выход из "спящего" режима
	CAN_ITConfig(CAN1, CAN_IT_SLK, ENABLE);         // Прерывание при переходе в "спящий" режим
 
	// CAN Error Interrupts
	// Обрабатывается в прерывании CAN1_SCE_IRQHandler
	CAN_ITConfig(CAN1, CAN_IT_EWG, ENABLE);         // Error warning Interrupt (error counter >= 96)
	CAN_ITConfig(CAN1, CAN_IT_EPV, ENABLE);         // Error passive Interrupt (error counter > 127)
	CAN_ITConfig(CAN1, CAN_IT_BOF, ENABLE);         // Bus-off Interrupt (error counter > 255)
	CAN_ITConfig(CAN1, CAN_IT_LEC, ENABLE);         // Last error code - при возникновении ошибок приема-передачи
	CAN_ITConfig(CAN1, CAN_IT_ERR, ENABLE);         // Прерывание при возникновении ошибок bxCan


	// NVIC Configuration
	NVIC_InitTypeDef NVIC_InitStructure;

	// Enable CAN1 TX0 interrupt IRQ channel
	NVIC_InitStructure.NVIC_IRQChannel = USB_HP_CAN1_TX_IRQn;
	NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0;
	NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0;
	NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
	NVIC_Init(&NVIC_InitStructure);

	// Enable CAN1 RX0 interrupt IRQ channel
	NVIC_InitStructure.NVIC_IRQChannel = USB_LP_CAN1_RX0_IRQn;
	NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0;
	NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0;
	NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
	NVIC_Init(&NVIC_InitStructure);

	// Enable CAN1 RX1 interrupt IRQ channel
	NVIC_InitStructure.NVIC_IRQChannel = CAN1_RX1_IRQn;
	NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0;
	NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0;
	NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
	NVIC_Init(&NVIC_InitStructure);

	// Enable CAN1 SCE (Status Change Error) interrupt IRQ channel
	NVIC_InitStructure.NVIC_IRQChannel = CAN1_SCE_IRQn;
	NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0;
	NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0;
	NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
	NVIC_Init(&NVIC_InitStructure);

После того, как с помощью функции CAN_ITConfig() мы проинициализировали необходимые нам прерывания, необходимо включить обработчики этих прерываний. Делается это через NVIC. Если мы забудем хотя бы одно из них включить, то микроконтроллер при возникновении прерывания, которое мы забыли обработать, выкинет нас в стандартный обработчик прерываний и просто зависнет. Поможет только перезагрузка процессора, так как он будет сидеть в «вечном» цикле и ни на что больше реагировать не будет.

А теперь, чтобы этого не произошло, нам необходимо вставить в наш программный код функции обработки прерываний. Всего их четыре: прерывание при освобождении исходящего почтового ящика, два прерывания для буферов FIFO 1 и 2, а также прерывание по обработке ошибок и входа/выхода в «режим сна».

Обработка прерываний при освобождении исходящего почтового ящика

За обработку прерывания при освобождении исходящего почтового ящика отвечает функция USB_HP_CAN1_TX_IRQHandler(). Нам необходимо проверить флаг прерывания и, если он установлен, сбросить его и выполнить код обработки прерывания:

Листинг №2. Обработка прерываний bxCan для исходящего почтового ящика
void USB_HP_CAN1_TX_IRQHandler(void)
{
	// CAN Transmit mailbox empty Interrupt enable
	// Обработаем прерывания при освобождении исходящего почтового ящика
	if (CAN_GetITStatus(CAN1, CAN_IT_TME)==SET) {       // Прерывание при освобождении исходящего почтового ящика
		CAN_ClearITPendingBit(CAN1, CAN_IT_TME);
   
		// Вставляем свой код по обработке прерывания
	}
}

Функция CAN_GetITStatus() возвращает текущее состояние флага прерывания, значение может быть равным SET или RESET («Установлен» или «сброшен» соответственно). Значение SET говорит нам о том, что бит установлен и нам необходимо обработать это прерывание и не забыть сбросить его флаг.

Следует помнить о том, что необходимо всегда производить сброс флага прерывания, иначе оно будет вызываться постоянно. Исключение составляют только флаги прерываний ошибок, они почти все сбрасываются аппаратно, подробнее можно посмотреть в описании функции CAN_ClearITPendingBit().

Проверять освобождение исходящего почтового ящика имеет смысл, если Вы пересылаете большой объем данных по Can-шине: при обработке отправки сообщения выставляется флаг отправки сообщения, а в прерывании проверяется была выполнена отправка данных или нет. Если отправка была завершена без ошибок, то устанавливаем в флаг значение без ошибок и отправляем следующий пакет данных, иначе устанавливаем в флаг код ошибки и обрабатываем ее в модуле программы.

Несмотря на то, что исходящих почтовых ящиков у нас три, проверять отправку сообщений я все же рекомендую, иначе вполне вероятны ситуации, когда в результате проигрыша арбитража или возникновении ошибок на линии bxCan не сможет отправить сообщения, а мы в этот момент, не проверив статус отправки, будем давать ему новые на отправку. Возникнет сбой, который нам не нужен.

Проверить статус отправки сообщения можно не только с помощью прерываний, но и в момент отправки сообщения (это наверное самый оптимальный вариант):

Листинг №3. Отправка сообщения с проверкой статуса отправки
	uint32_t i = 0;
	uint8_t TransmitMailbox = 0;
	
	...
	
	TransmitMailbox = CAN_Transmit(CAN1, &TxMessage);
	i = 0;
	while ((CAN_TransmitStatus(CAN1, TransmitMailbox) != CANTXOK) && (i != 0xFF)) 	{
		i++;
	}

При передаче сообщения через функцию CAN_Transmit, она нам возвращает номер исходящего почтового ящика, в который помещено сообщение. Затем мы в цикле проверяем, отправил ли bxCan наше сообщение или нет. Если отправка прошла успешно, то статус отправки сообщения из почтового ящика будет равен CANTXOK.

По окончанию цикла while() проверяем значение переменной «i». Если оно у нас равно 0xFF, значит отправка не удалась и тут мы уже думаем что сделать: то ли сбросить отправку сообщения, то ли обработать ошибку.

Вообщем все на усмотрение разработчика.

Обработка прерываний входящего буфера сообщений FIFO 0

За прерывания для входящего буфера сообщений FIFO 0 отвечают флаги CAN_IT_FMP0, CAN_IT_FF0 и CAN_IT_FOV0.

Таб. 1. Прерывания  буфера FIFO 0

Заполнение, а тем более переполнение буфера входящих сообщений говорит о том, что Ваша программа не успевает их обрабатывать. Здесь уже необходимо искать причину в организации работы CAN шины и поиграться с установкой фильтров сообщений.

Фильтры помогут на аппаратном уровне отсеивать пакеты с ненужными нам данными, чтобы не тратить время и ресурсы процессора на обработку ненужной информации. Подробнее работу с фильтрами я описал в статье STM32. Почтовые ящики. Фильтры пакетов CAN.

Действия по обработке данных прерываний возлагаются на разработчика и описываются в функции USB_LP_CAN1_RX0_IRQHandler().

Листинг №4. Обработка прерываний bxCan для буфера FIFO 0
void USB_LP_CAN1_RX0_IRQHandler(void)
{
	CanRxMsg RxMessage;
	
	// CAN Receive Interrupt enable FIFO 0
	// Обработаем прерывания приемного буфера FIFO 0
	if (CAN_GetITStatus(CAN1, CAN_IT_FMP0) == SET) {                   // Прерывание получения пакета в буфер FIFO 0
		// Флаг сбрасывается автоматически после прочтения последнего сообщения
   
		// Обнулим данные пакета
		RxMessage.DLC =     0x00;
		RxMessage.ExtId =   0x00;
		RxMessage.FMI =     0x00;
		RxMessage.IDE =     0x00;
		RxMessage.RTR =     0x00;
		RxMessage.StdId =   0x00;
		RxMessage.Data [0] = 0x00;
		RxMessage.Data [1] = 0x00;
		RxMessage.Data [2] = 0x00;
		RxMessage.Data [3] = 0x00;
		RxMessage.Data [4] = 0x00;
		RxMessage.Data [5] = 0x00;
		RxMessage.Data [6] = 0x00;
		RxMessage.Data [7] = 0x00;
		
		CAN_Receive(CAN1, CAN_FIFO0, &RxMessage);                   // Получим сообщение
   
		// Вставляем любой свой код обработки входящего пакета
   
		}
   
	if (CAN_GetITStatus(CAN1, CAN_IT_FF0)==SET) {                       // Прерывание при заполнении буфера FIFO 0
		CAN_ClearITPendingBit(CAN1, CAN_IT_FF0);
		
		// Вставляем свой код по обработке прерывания
 		
		// Не забываем после обработки сбросить флаг ошибки
		CAN_ClearFlag(CAN1, CAN_FLAG_FF0);
	}
	
	if (CAN_GetITStatus(CAN1, CAN_IT_FOV0)==SET) {                      // Прерывание при переполнении буфера FIFO 0
		CAN_ClearITPendingBit(CAN1, CAN_IT_FOV0);
		
		// Вставляем свой код по обработке прерывания
   
		// Не забываем после обработки сбросить флаг ошибки
		CAN_ClearFlag(CAN1, CAN_FLAG_FOV0);
	}
}

Следует обратить внимание на то, что функция USB_LP_CAN1_RX0_IRQHandler() предназначена как для обработки прерываний bxCan так и для обработки прерываний USB. Если Вы будете использовать USB в своем проекте, то нужно внимательно подойти к этому моменту, чтобы правильно обрабатывать сообщения для каждого устройства.

Обратите внимание, что в обработчике прерываний мы сбрасываем не только флаг прерывания, но также сбрасываем флаг ошибки bxCan. Это немного (точнее очень много) разные вещи: флаг прерывания отвечает за то, что мы попадем в обработчик прерывания при его установке и если его не сбросить, то мы можем сидеть вечно в этом обработчике. А флаг ошибки сигнализирует нам о том, что есть ошибка и его нужно снять после того, как мы обработали эту ошибку. Соответственно, если по какой-либо причине мы ее не обработали — этот флаг снимать не следует.

Напомню, что часть флагов прерываний (и ошибок) снимаются автоматически, здесь нужно внимательно изучать руководство.

Обработка прерываний входящего буфера сообщений FIFO 1

За прерывания для входящего буфера сообщений FIFO 1 отвечают флаги CAN_IT_FMP1, CAN_IT_FF1 и CAN_IT_FOV1. Описание и действие аналогично с обработкой прерывания для буфера FIFO 0.

Таб. 2. Прерывания  буфера FIFO 1

В отличии от буфера FIFO 0, обработка этих прерываний происходит в функции CAN1_RX1_IRQHandler().

Листинг №5. Обработка прерываний bxCan для буфера FIFO 1
void CAN1_RX1_IRQHandler(void)
{
	CanRxMsg RxMessage;
   
	// CAN Receive Interrupt enable FIFO 1
	// Обработаем прерывания приеного буфера FIFO 1
	if (CAN_GetITStatus(CAN1, CAN_IT_FMP1) == SET) {              // Прерывание получения пакета в буфер FIFO 1
		// Флаг сбрасывается автоматически после прочтения последнего сообщения
   
		// Обнулим данные пакета
		RxMessage.DLC =     0x00;
		RxMessage.ExtId =   0x00;
		RxMessage.FMI =     0x00;
		RxMessage.IDE =     0x00;
		RxMessage.RTR =     0x00;
		RxMessage.StdId =   0x00;
		RxMessage.Data [0] = 0x00;
		RxMessage.Data [1] = 0x00;
		RxMessage.Data [2] = 0x00;
		RxMessage.Data [3] = 0x00;
		RxMessage.Data [4] = 0x00;
		RxMessage.Data [5] = 0x00;
		RxMessage.Data [6] = 0x00;
		RxMessage.Data [7] = 0x00;
   
		CAN_Receive(CAN1, CAN_FIFO1, &RxMessage);               // Получим сообщение
   
		// Вставляем любой свой код обработки входящего пакета
   
	}
   
	if (CAN_GetITStatus(CAN1, CAN_IT_FF1)==SET) {                   // Прерывание при заполнении буфера FIFO 1
		CAN_ClearITPendingBit(CAN1, CAN_IT_FF1);
   
		// Вставляем свой код по обработке прерывания
   
		// Не забываем после обработки сбросить флаг ошибки
		CAN_ClearFlag(CAN1, CAN_FLAG_FF1);
	}

	if (CAN_GetITStatus(CAN1, CAN_IT_FOV1)==SET) {                  // Прерывание при переполнении буфера FIFO 1
		CAN_ClearITPendingBit(CAN1, CAN_IT_FOV1);

		/ Вставляем свой код по обработке прерывания
   
		// Не забываем после обработки сбросить флаг ошибки
		CAN_ClearFlag(CAN1, CAN_FLAG_FF1);
	}
}

Обработчик для буфера FIFO 1 ничем не отличается от обработчика для буфера FIFO 0, разница есть только в наименовании функции обработчика и флагов, которые мы проверяем. Наполнение буфера FIFO 1 (как и FIFO 0) зависит исключительно от настроек фильтрации пакетов и в них же указывается какие сообщения в какой буфер будут попадать.

Подробно я о фильтрах рассказывал в статье STM32. Почтовые ящики. Фильтры пакетов CAN.

В своем проекте управления умным домом я с помощью фильтрации разделяю управляющие пакеты и пакеты с данными по разным буферам: сообщения данных попадают исключительно в буфер FIFO 0, а системные и приоритетные сообщения я помещаю в буфер FIFO 1.

Если у Вас нет задачи такой фильтрации сообщений, то можно вполне обойтись одним буфером FIFO 0  и в принципе не использовать буфер FIFO 1 (или наоборот, роли никакой не играет). Для большинства задач это будет вполне достаточно и сэкономит Вам несколько сотен байт прошивки.

Обработка прерываний по ошибкам и «спящему» режиму

Обработчик прерываний ошибок bxCan позволяет нам определить насколько стабильно работает наше устройство с протоколом CAN и вовремя принять меры для достижения максимально стабильного режима работы.

За обработку ошибок отвечают следующие флаги:

Таб. 3. Прерывания ошибок и режима шины

Прерывание по флагам CAN_IT_WKU и CAN_IT_SLK срабатывают при входе или выходе в/из спящего режима. При этом флаг CAN_IT_ERR не устанавливается. А если же срабатывает прерывание по флагам CAN_IT_EWG, CAN_IT_EPV, CAN_IT_BOF или CAN_IT_LEC, то одновременно с ними устанавливается и флаг CAN_IT_ERR.

Флаги CAN_IT_EWG, CAN_IT_EPV и CAN_IT_BOF предназначены для контроля количества ошибок приема передачи по шине. Механизм bxxCan не только увеличивает счетчик ошибок, например когда на линии возникает помеха и счетчик ошибок увеличивается, но и уменьшает его, когда работа шины нормализуется. Флаги CAN_IT_EWG и CAN_IT_EPV являются предупреждающими о том, что идет рост ошибок и необходимо выявить причину их возникновения, а вот флаг CAN_IT_BOF нам сообщает, что счетчик ошибок достиг своего максимума и шина перешла в режим Bus-off. Выход из этого режима может произойти автоматически (при получении 128 раз 11 рецессивных бит подряд по шине) или принудительно — заново проинициализировав bxCan.

Напомню, что за автоматический выход из режима Bus-Off отвечает бит ABOM в регистре CAN_MCR. Рекомендую его устанавливать в Ваших проектах, тогда bxCan этот функционал возьмет на себя.

Флаг CAN_IT_LEC срабатывает, когда происходит ошибка приема или передачи пакета, при его обработке мы можем узнать последнюю ошибку шины или устройства.

С тем что обрабатывать — мы определились, теперь необходимо вставить в программный модуль и саму функцию обработки прерываний ошибок CAN1_SCE_IRQHandler().

В ней мы сформируем шаблон обработки исключений, возникающих при работе bxCan:

Листинг №6. Обработка прерываний засыпания/пробуждения и ошибок bxCan
void CAN1_SCE_IRQHandler(void)
{
	uint8_t errorcode = 0;

	if (CAN_GetITStatus(CAN1, CAN_IT_ERR)==SET)    {                   // Прерывание при возникновении ошибки
		CAN_ClearITPendingBit(CAN1, CAN_IT_ERR);

		// CAN Error Interrupts
		// Обработка прерываний по ошибке
		if (CAN_GetITStatus(CAN1, CAN_IT_EWG)==SET) {              // Error warning Interrupt (счетчик ошибок >= 96)
			CAN_ClearITPendingBit(CAN1, CAN_IT_EWG);

			// Вставляем свой код по обработке прерывания
		}
   
		if (CAN_GetITStatus(CAN1, CAN_IT_EPV)==SET) {              // Error passive Interrupt  (счетчик ошибок > 127)
			CAN_ClearITPendingBit(CAN1, CAN_IT_EPV);

			// Вставляем свой код по обработке прерывания
		}
   
		if (CAN_GetITStatus(CAN1, CAN_IT_BOF)==SET) {              // Bus-off. Прерывание при переполнении счетчика ошибок (>255)
			CAN_ClearITPendingBit(CAN1, CAN_IT_BOF);           // bxCan уходит в режим Bus-OFF

			// Вставляем свой код по обработке прерывания
		}
   
		if (CAN_GetITStatus(CAN1, CAN_IT_LEC)==SET) {              // Прерывание при ошибке приема передачи сообщения
			CAN_ClearITPendingBit(CAN1, CAN_IT_LEC);
			errorcode = CAN_GetLastErrorCode(CAN1);            // Получим код ошибки
   
			// Вставляем свой код по обработке прерывания

			// Не забываем после обработки сбросить флаг ошибки
			CAN_ClearFlag(CAN1, CAN_FLAG_LEC);
		}

	} else {

		// CAN Operating Mode Interrupt
		// Обработка прерываний по режимам сна/пробуждения
		if (CAN_GetITStatus(CAN1, CAN_IT_WKU)==SET) {             // Прерывание при "пробуждении" - выход из "спящего" режима
			CAN_ClearITPendingBit(CAN1, CAN_IT_WKU);

			// Вставляем свой код по обработке прерывания
   
			// Не забываем после обработки сбросить флаг ошибки
			CAN_ClearFlag(CAN1, CAN_FLAG_WKU);
		}

		if (CAN_GetITStatus(CAN1, CAN_IT_SLK)==SET) {             // Прерывание при переходе в "спящий" режим
			CAN_ClearITPendingBit(CAN1, CAN_IT_SLK);

			// Вставляем свой код по обработке прерывания
   
			// Не забываем после обработки сбросить флаг ошибки
			CAN_ClearFlag(CAN1, CAN_FLAG_SLAK);
		}
	}
}

Также как мы сбрасываем флаги прерываний, нам необходимо сбрасывать и флаги ошибок после их обработки. Но если обратить внимание на описание регистров, то мы видим, что часть флагов ошибок сбрасываются автоматически аппаратными средствами bxCan, а часть мы должны очищать вручную. Вот и сейчас при обработке ошибок мы можем сбросить только флаги CAN_IT_LEC, CAN_IT_WKU и CAN_IT_SLK, а остальные флаги ошибок в данном обработчике прерываний сбрасываются автоматически.

Не стоит забывать и о том, что перед сбросом флага ошибки мы должны ее (ошибку) обработать и уже потом менять флаг.

Еще стоит обратить внимание на обработку прерывания CAN_IT_LEC (Last Error Code), которая появляется при возникновении ошибок ввода-вывода.

В обработчике  с помощью функции CAN_GetLastErrorCode() мы заполняем переменную errorcode данными о последней ошибке. Она может принимать следующие значения:

 Таб. 4. Виды ошибок, возвращаемые при вызове функции CAN_GetLastErrorCode()

Таким образом, обрабатывая флаг CAN_IT_LEC и изучая ошибки, которые происходят при работе с CAN, мы можем заблаговременно выявить причину и предпринять некоторые действия для того, что бы предотвратить рост ошибок и сваливание CAN контроллера в режим Bus-Off.

Заключение

В этой статье я постарался подробно описать механизмы обработки прерываний bxCan, а также механизмы связанные с обработкой ошибок и методы по их сокращению. Напомню, что все тестирование кода производилось на базе микроконтроллера STM32F103C6.

Вполне вероятно, что я что-то упустил, где то наоборот ошибся и был не точен. Поэтому если есть какие-либо замечания и/или предложения к статье — добро пожаловать в комменты и я исправлюсь.

Как обычно, во вложениях весь исходный код, который рассматривается в рамках данной статьи. Но в отличие от предыдущих постов, исходный код для этой статьи представляет собой некий шаблон, который предполагается использовать в разных проектах.

З.Ы. Простите за много букафф )))

Недавно мы разбирались с теоретическими аспектами работы протокола CAN – контролем ошибок, организацией арбитража сообщений на шине и т. д. Так вот, сегодня, как и обещал, займемся практической стороной вопроса – реализуем прием и передачу данных по CAN на микроконтроллере STM32.

Для настройки периферии будем использовать STM32CubeMx, в качестве среды разработки я, как обычно, беру IAR. Осталось упомянуть про выбранный контроллер – им сегодня будет STM32F103VE. Но, как вы помните, при работе с STM32 нет никакой проблемы в том, чтобы перейти на другой микроконтроллер или другую IDE 👍

Итак, первый шаг заключается в настройке в CubeMx всей имеющейся периферии. Не буду подробно останавливаться на том, что не касается непосредственно CAN, все можно найти в нашем курсе по этой вот ссылке.

В итоге у нас оказываются задействованы следующие пины контроллера:

Здесь мы уже активировали модуль CAN:

Но пока мы его только включили, необходимо еще выполнить настройку. И самым важным параметром является, конечно, скорость обмена данными. В случае с CAN ситуация не совсем такая, как с другими модулями STM32, для задания скорости мы должны настроить временные характеристики интерфейса, а не просто задать конкретное число:

Давайте разберемся, что это за значения и за что они отвечают. Время передачи одного бита в CAN складывается из:

Все длительности оцениваются через понятие кванта времени, для задания которого мы устанавливаем значение предделителя (в этом проекте он равен 8). Таким образом, мы получаем длительность 1 кванта:

T_{q}  = 222.2medspace нс

Первый сегмент на этой схеме – SYNC_SEG – используется для синхронизации всех узлов сети CAN. Ожидается, что фронт сигнала должен находиться внутри именно этого сегмента.

Второй сегмент — BS1 (Bit segment 1). Стандарт CAN включает в себя два сегмента — PROP_SEG и PHASE_SEG1. Оба этих сегмента в STM32 относятся к сегменту BS1. PROP_SEG нужен для компенсации физических задержек в сети, а PHASE_SEG1 используется для компенсации ошибки смещения фазы сигнала.

Сегмент BS1 определяет положение sample point (точки захвата). В этой точке модуль CAN анализирует уровень сигнала на шине, то есть определяет, принят рецессивный или доминантный бит.

И третий сегмент — BS2 (Bit segment 2). Он представляет из себя сегмент PHASE_SEG2 интерфейса CAN. Его назначение такое же как и у PHASE_SEG1.

Сегмент BS2 определяет положение transmit point (точки передачи), то есть того момента времени, когда модуль CAN выдает на линию определенный бит.

Длительности этих сегментов таковы:

• SYNC_SEG: 1 квант времени
• Bit segment 1 (BS1): 1 — 16 квантов
• Bit segment 2 (BS2): 1 – 8 квантов

Устанавливая длительности различных сегментов, мы получаем время передачи одного бита в квантах. Зная длительность самого кванта, мы легко получаем время передачи бита в секундах. А уже из этого мы рассчитываем скорость передачи данных по шине. Только при настройке CAN нужно пройти в обратном направлении.

Пусть мы хотим задать скорость обмена равной 500 Кбит/с. Тогда время передачи одного бита:

T_{bit}  = frac{1medspace с}{500000medspace} = 2000medspace нс

Длительность одного кванта мы уже задали равной 222,2 нс. Таким образом, время 1-го бита в квантах:

T = frac{T_{bit}}{T_{q}} = 9

Эти 9 квантов нужно распределить между тремя сегментами. SYNC_SEG фиксирован (1 квант), значит остается 8 квантов на сегменты BS1 и BS2. Ставим в этом примере поровну – по 4 кванта и получаем нужную нам скорость обмена данными. И, наконец, можем двигаться дальше — включаем прерывания и генерируем код:

В main() находим функцию инициализации CAN:

  /* Initialize all configured peripherals */
  MX_GPIO_Init();
  MX_CAN_Init();

Но на самом деле, на этом настройка не заканчивается. Дело в том, что в STM32 есть очень полезная функция фильтрации сообщений по ID. Как вы помните, ID в CAN относится не к устройству в сети, а к сообщению. То есть одно и то же устройство может рассылать сообщения с разными ID. А поскольку сеть является широковещательной, то приемник будет получать кучу сообщений, среди которых ему нужны только некоторые. И вот для этого и существует фильтрация сообщений. Благодаря аппаратной поддержке не нужно программно проверять ID всех принятых сообщений, можно всего лишь изначально настроить периферию на прием только нужных сообщений.

Настраивается этот механизм следующим образом:

CAN_FilterTypeDef canFilterConfig;
canFilterConfig.FilterBank = 0;
canFilterConfig.FilterMode = CAN_FILTERMODE_IDMASK;
canFilterConfig.FilterScale = CAN_FILTERSCALE_32BIT;
canFilterConfig.FilterIdHigh = 0x0000;
canFilterConfig.FilterIdLow = 0x0000;
canFilterConfig.FilterMaskIdHigh = 0x0000;
canFilterConfig.FilterMaskIdLow = 0x0000;
canFilterConfig.FilterFIFOAssignment = CAN_RX_FIFO0;
canFilterConfig.FilterActivation = ENABLE;
canFilterConfig.SlaveStartFilterBank = 14;
HAL_CAN_ConfigFilter(&hcan, &canFilterConfig);

Собственно, за «пропускаемые» через фильтр ID отвечают эти поля структуры CAN_FilterTypeDef:

canFilterConfig.FilterIdHigh = 0x0000;
canFilterConfig.FilterIdLow = 0x0000;
canFilterConfig.FilterMaskIdHigh = 0x0000;
canFilterConfig.FilterMaskIdLow = 0x0000;

• FilterIdHigh – старшая часть ID
• FilterIdLow– младшая часть ID
• FilterMaskIdHigh– старшая часть маски
• FilterMaskIdLow– младшая часть маски

В данном случае все значения равны 0x0000, это означает, что абсолютно все сообщения будут проходить через фильтр.

Значения FilterIdHigh и FilterIdLow определяют идентификатор, с которым будет сравниваться ID принятого сообщения. А FilterMaskIdHigh и FilterMaskIdLow отвечают за битовую маску, которая, в свою очередь, определяет, какие биты идентификатора будут проверяться, а какие – нет. Единица в маске означает, что бит, который соответствует положению этой единицы, будет проверен. Сейчас на примере все станет окончательно понятно.

Итак, пусть мы хотим принимать только сообщения с ID из диапазона – 0x200 – 0x20F. Тогда настройка будет такой:

canFilterConfig.FilterIdHigh = 0x200 << 5;
canFilterConfig.FilterIdLow = 0x0000;
canFilterConfig.FilterMaskIdHigh = 0x7F0 << 5;
canFilterConfig.FilterMaskIdLow = 0x0000;

Обратите внимание, что для стандартного идентификатора значения  необходимо сместить влево  на 5 бит. Запишем в двоичном виде значения 0x200 – 0x20F, смещенные на 5 битов:

Получается, что мы должны проверять 7 старших битов ID, одинаковые во всех идентификаторах. И, в итоге, получаем значение битов маски равным 0x7F0 << 5 (единицы соответствуют тем битам, которые должны соответствовать заданному в FilterIdHigh значению).

После настройки фильтра мы включаем модуль CAN и разрешаем прерывания по приему данных в FIFO0:

HAL_CAN_Start(&hcan);
HAL_CAN_ActivateNotification(&hcan, CAN_IT_RX_FIFO0_MSG_PENDING);

Теперь для приема сообщений CAN мы просто переопределяем соответствующую callback-функцию:

void HAL_CAN_RxFifo0MsgPendingCallback(CAN_HandleTypeDef *hcan)
{
  CAN_RxHeaderTypeDef msgHeader;
  uint32_t msgId = 0;
  uint8_t msgData[8];
  
  HAL_CAN_GetRxMessage(hcan, CAN_RX_FIFO0, &msgHeader, msgData);
    
  if (msgHeader.IDE == CAN_ID_EXT)
  {
    msgId = msgHeader.ExtId;
  }
  else
  {
    msgId = msgHeader.StdId;
  }
}

В самой функции мы вызываем HAL_CAN_GetRxMessage() для получения принятых данных и, например, проверяем тип идентификатора (расширенный или стандартный). Дальше уже можно использовать принятые данные по назначению. С приемом все понятно, давайте рассмотрим и процесс передачи.

В STM32F10x реализованы 3 так называемых mailbox’а, то есть по сути «почтовых ящика», в которые мы можем складывать наши сообщения. Далее микроконтроллер аппаратно выбирает, какое сообщение отправить в линию. Можно настроить механизм аналогичный FIFO, то есть первое помещенное в mailbox сообщение и отправлено будет первым. А можно настроить периферию на отправку сообщений в соответствии с приоритетом самих сообщений.

Для каждого из mailbox’ов есть соответствующий callback, который вызывается по окончанию передачи:

• void HAL_CAN_TxMailbox0CompleteCallback(CAN_HandleTypeDef *hcan)
• void HAL_CAN_TxMailbox1CompleteCallback(CAN_HandleTypeDef *hcan)
• void HAL_CAN_TxMailbox2CompleteCallback(CAN_HandleTypeDef *hcan)

Отправим тестовое сообщение:

if (HAL_CAN_GetTxMailboxesFreeLevel(&hcan) != 0)
{
  CAN_TxHeaderTypeDef msgHeader;
  uint8_t msgData[8];

  msgHeader.StdId = 0x200;
  msgHeader.DLC = 8;
  msgHeader.TransmitGlobalTime = DISABLE;
  msgHeader.RTR = CAN_RTR_DATA;
  msgHeader.IDE = CAN_ID_STD;
  
  uint32_t mailBoxNum = 0;
  
  for (uint8_t i = 0; i < 8; i++)
  {
    msgData[i] = i;
  }
  
  HAL_CAN_AddTxMessage(&hcan, &msgHeader, msgData, &mailBoxNum);
}

Первым делом вызываем HAL_CAN_GetTxMailboxesFreeLevel(&hcan). Функция возвращает количество свободных mailbox’ов. Если есть хоть один свободный mailbox, то начинаем формировать сообщение на передачу — устанавливаем параметры сообщения, идентификатор и, конечно же, непосредственно данные. Затем вызываем функцию HAL_CAN_AddTxMessage(), которая поместит наше новое сообщение в один из mailbox’ов и активирует соответствующий запрос на передачу.

Обратите внимание, что помимо данных сообщения мы передаем в эту функцию адрес переменной mailBoxNum. Здесь функция сохранит номер почтового ящика, в который отправлено сообщение, этот номер можно использовать для дальнейшей работы, например, в callback’е по окончанию передачи.

Итак, в общем-то, на этом все — CAN настроили, прием и передачу осуществили ) Проект для статьи доступен по ссылке — MT CAN Example.

До скорых встреч и спасибо за внимание 🤝

8. CAN

8.1 Основные понятия

Полное название — Controller Area Network, что представляет собой полудуплексную асинхронную связь. Аргумента «главный-подчиненный» нет, каждое устройство может отправлять и получать.

8.1.1 Физический уровень

Две сигнальные линии, CAN_High и CAN_Low две дифференциальные сигнальные линии, обмениваются данными в дифференциальной форме

Два типа сетей:

Замкнутый контур: длина шины может составлять до 40 м, а максимальная скорость составляет 1 Мбит / с.

​

∘

circ

На каждом конце шины есть резистор 120 Ом.

​

∘

circ

Контроллер CAN является контроллером каждого устройства, подключенного к шине, и обычно должен быть оснащен трансивером CAN (например, трансивер CAN на кодовом диске нашей команды использует TJA1050) для преобразования потока двоичного кода контроллера CAN в Дифференциальный уровень шины CAN, передача данных по двум кабелям шины с дифференциальным напряжением

Открытый цикл: максимальное расстояние передачи составляет 1 км, максимальная скорость — 125 кбит / с.

∘

circ

Укажите последовательно резистор 2,2 кОм для каждого провода.

Дифференциальный сигнал протокола CAN

∘

circ

Доминирующий уровень соответствует «0», а рецессивный уровень соответствует «1». Рецессивный уровень (1) оба линейных напряжения составляют 2,5 В, то есть разность напряжений равна 0; доминирующий уровень (0) CAN_High и CAN_Low составляют 3,5 В и 1,5 В соответственно, а разница напряжений составляет 2 В.

∘

circ

На шине, пока один узел выводит доминирующий уровень, шина находится на доминирующем уровне; только когда все узлы находятся на рецессивном уровне, шина находится на рецессивном уровне

∘

circ

Поскольку CAN является полудуплексным, отправка и получение выполняются отдельно, и это связь по шине, поэтому только один узел может отправлять одновременно, а другие узлы могут только получать в это время.

8.1.2 Уровень протокола

Битовая синхронизация

Значение: для достижения правильной выборки на уровне шины, чтобы обеспечить нормальную связь. Самая маленькая единица — Tq (Time Quantum), полный бит состоит из 8 ~ 25 Tq.

Состав: раздел SS, раздел PTS, раздел PBS1, раздел PBS2

Например

Расчет скорости передачи данных: линия синхронизации, используемая CAN, — это периферийные часы APB1 (при условии APC), что обычно составляет четверть частоты SYSCLK. И связь CAN также должна предварительно масштабировать это (при условии, что это Prescaler), тогда Tq — это Prescaler / APC (unit s). И один бит данных занимает (SS + PTS + PBS1 + PBS2 + SJW) Tq. Тогда количество битов, которые могут быть переданы за одну секунду, равно

1

T

q

∗

Один

А

Немного

Получить

T

q

число

frac {1} {Tq * Tq число на цифру}

Например: в дереве тактовых импульсов частота периферийных часов APB1 составляет 45 МГц, а предделитель равен 5, тогда Tq — это

4

45

M

H

z

=

111.1111

…

(

n

s

)

frac{4}{45MHz}=111.1111dots(ns)

, На рисунке выше 19 Tqs, тогда скорость передачи равна

1

19

∗

111.11

∗

1

0

−

9

≈

473689

(

b

p

s

)

frac{1}{19*111.11*10^{-9}}approx473689(bps)

Сообщение

Тип кадра:

Структура кадра данных:

Начинается с доминирующего бита (0) и заканчивается 7 последовательными невидимыми битами (1). Посередине расположены секция арбитража, секция управления, секция данных, секция CRC и секция ACK последовательно, всего 7 секций.

Начало кадра (SOF): доминирующий уровень. Используется для уведомления каждого узла о передаче данных

Раздел арбитража: используется для указания приоритета. Разница между стандартным форматом и расширенным форматом здесь, идентификатор стандартного формата составляет 11 бит, а расширенный формат — 11 + 18 = 29 бит. RTR (бит запроса удаленной передачи) использует явный рецессивный уровень, чтобы отличать кадры данных от кадров удаленного управления.

IDR (Identifier Extension Bit), доминантная — стандартная форма, рецессивная — расширенная.

SSR, стандартный формат RTR, является рецессивным битом.

Идентификатор определяет приоритет кадра данных. Когда два узла конкурируют за шину одновременно, узел с рецессивным уровнем сначала теряет свое владение и переходит в состояние приема.

Сегмент управления: r1 и r0 являются зарезервированными битами и по умолчанию являются доминирующими. DLC, длина массива данных, 0 ~ 8

Сегмент данных: 0_{8 байт (0}64 бит)

Сегмент CRC: всего 16 бит. 15-битный контрольный код CRC, 1-битный разделитель, рецессивный

Сегмент ACK: всего 2 бита. Один бит — это слот ACK, отправитель отправляет рецессивный, а получатель отправляет доминирующий, чтобы указать ответ; один бит является разделителем конца кадра

Конец кадра (ROF): 7 невидимых бит

8.1.3 Фильтр

Цель: отфильтровать неинтересные сообщения, то есть сообщения, не имеющие отношения к этому узлу

Два режима: режим списка и режим маски

Количество фильтров: необязательно 0 при использовании CAN_{№ 13 фильтр; использовать два CAN да, опционально 0}№ 37 фильтр

Режим

Режим списка: составьте таблицу идентификаторов интересующих сообщений. Когда полученный идентификатор сообщения совпадает, оно будет получено, в противном случае оно не будет получено

Преимущества, точные, могут полностью отфильтровать нежелательные сообщения

Недостатки, количество списков ограничено, а когда интересующих сообщений слишком много, их нельзя включить.

В режиме маски пакеты с частичными идентификаторами получают через операцию И.

Преимущества, круг интересов может быть больше

Недостатки, возможно, не удастся полностью отфильтровать незаинтересованные сообщения, точность зависит от кода маскировки.

Битовая ширина

Фильтр доступен в 32-битном и 16-битном вариантах. Среди них 16 бит могут фильтровать только стандартные кадры, но не расширенные кадры.

8.2 STM32 CAN

STM32 имеет два набора контроллеров CAN, CAN1 — это главное устройство, отвечающее за управление bxCAN (базовая расширенная CAN, то есть CAN) и 512 байтов SRAM. CAN2 является подчиненным контроллером и не может напрямую обращаться к SRAM. Периферийные часы CAN1 должны быть включены для использования CAN2

В STM32, когда фильтр приема CAN использует 32 бита, маска и проверочный код разделяются на два регистра, каждый по 16 бит, представляющих старшие 16 бит и младшие 16 бит.

8.3 Шаги настройки CubeMX

1. Список слева_{>Connectivity}> Нажмите CAN1 / CAN2 ~> Проверка режима Master Mode / Slave Mode

2. Параметры конфигурации имеют следующие значения:
   

   параметр	имея в виду
   Prescaler	Предделитель, то есть периферийные часы APB1, упомянутые в битовой синхронизации, продолжают делиться один раз
   Time Quantum	Минимальная единица времени Tq, рассчитывается автоматически, вводить не нужно
   Time Quanta in Bit Segment 1	Длина сегмента PBS1
   Time Quanta in Bit Segment 2	Длина секции PBS2
   ReSynchronization Jump Width	Ширина скачка ресинхронизации, то есть SJW, упомянутая в битовой синхронизации
   Time Triggered Communication Mode	Включить ли триггер времени
   Automatic Bus-Off Management	Следует ли включать автоматическое автономное управление
   Automatic Wake-Up Mode	Включать ли автоматическое пробуждение
   Qutomatic Retransmission	Включать ли автоматическую повторную передачу
   Receive Fifo Locked Mode	Включить ли блокировку FIFO
   Transmit Fifo Priority	Метод суждения для настройки приоритета сообщения
   Oprating Mode	Режим работы

   Эти параметры также можно изменить в can.c

3. Настройки прерывания (NVIC), установленные по мере необходимости, обычно проверяют прерывание CAN1 RX0

8.4 Программирование

Все определения функций и структуры библиотеки HAL о CAN находятся в stm32f4xx_HAL_Driver.c и stm32f4xx_HAL_Driver.h в папке Drivers / STM32F4xx_HAL_Driver соответственно

Вот несколько основных и часто используемых

8.4.1 Базовая структура CAN

Структура определения отправки сообщения (CAN_TxHeaderTypeDef)

typedef struct
{
  uint32_t StdId;    / *! Стандартный ID. Значение параметра может быть только от 0 до 0x7FF (11 бит 1 в двоичном формате) * /

  uint32_t ExtId;    / *! Идентификатор расширения. Значение параметра может быть только от 0 до 0x1FFFFFFF (29 бит 1 в двоичном формате) * /

  uint32_t IDE;      / *! IDE. При программировании библиотеки HAL укажите CAN_ID_STD для стандартных кадров и CAN_ID_EXT для расширенных кадров * /

  uint32_t RTR;      / *! RTR. При программировании библиотеки HAL заполните CAN_RTR_DATA во фрейме данных и заполните CAN_RTR_REMOTE во фрейме дистанционного управления * /

  uint32_t DLC;      / *! DLC. Длина данных, значение параметра может быть только от 0 до 8 * /

  FunctionalState TransmitGlobalTime; /*!< Specifies whether the timestamp counter value captured on start
                          of frame transmission, is sent in DATA6 and DATA7 replacing pData[6] and pData[7].
                          @note: Time Triggered Communication Mode must be enabled.
                          @note: DLC must be programmed as 8 bytes, in order these 2 bytes are sent.
                          This parameter can be set to ENABLE or DISABLE. */

} CAN_TxHeaderTypeDef;

Структура определения сообщения приема（CAN_RxHeaderTypeDef）

typedef struct
{
  uint32_t StdId;   

  uint32_t ExtId;    

  uint32_t IDE;      

  uint32_t RTR;      

  uint32_t DLC;      

  uint32_t Timestamp; /*!< Specifies the timestamp counter value captured on start of frame reception.
                          @note: Time Triggered Communication Mode must be enabled.
                          This parameter must be a number between Min_Data = 0 and Max_Data = 0xFFFF. */

  uint32_t FilterMatchIndex; /*!< Specifies the index of matching acceptance filter element.
                          This parameter must be a number between Min_Data = 0 and Max_Data = 0xFF. */

} CAN_RxHeaderTypeDef;

Структура определения типа фильтра приема (CAN_FilterTypeDef)

typedef struct
{
  uint32_t FilterIdHigh;          / *! Старшие 16 цифр идентификатора кода проверки фильтра могут заполнять только значение от 0 до 0xFFFF * /

  uint32_t FilterIdLow;           / *! Младшие 16 бит идентификатора фильтра, вы можете ввести только значение от 0 до 0xFFFF * /

  uint32_t FilterMaskIdHigh;      / *! Старшие 16 бит идентификатора маски фильтра могут заполнять только значение от 0 до 0xFFFF * /

  uint32_t FilterMaskIdLow;       / *! Младшие 16 бит идентификатора маски фильтра могут заполнять только значение от 0 до 0xFFFF * /

  uint32_t FilterFIF(x)Assignment;  / *! В какой FIFOx поместить переданное сообщение и заполнить FIFO (x) * /

  uint32_t FilterBank;            / *! Использовать номер фильтра. Если вы используете одну CAN, вы можете выбрать 0 ~ 13; если вы используете две CAN, вы можете выбрать 0 ~ 27 * /

  uint32_t FilterMode;            / *! Выбор режима фильтрации. Заполните CAN_FILTERMODE_IDMASK для режима маски и заполните режим списка
                                                                           Заполните CAN_FILTERMODE_IDLIST * /

  uint32_t FilterScale;           / *! Разрядность фильтра, 32 бита CAN_FILTERSCALE_32BIT,
                                                                                               16 бит - CAN_FILTERSCALE_16BIT * /

  uint32_t FilterActivation;      / *! Включить ли фильтр, ОТКЛЮЧИТЬ или ВКЛЮЧИТЬ * /

  uint32_t SlaveStartFilterBank;  /*!< Select the start filter bank for the slave CAN instance.
                                       For single CAN instances, this parameter is meaningless.
                                       For dual CAN instances, all filter banks with lower index are assigned to master
                                       CAN instance, whereas all filter banks with greater index are assigned to slave
                                       CAN instance.
                                       This parameter must be a number between Min_Data = 0 and Max_Data = 27. */

} CAN_FilterTypeDef;

Примечание. Четыре члена FilterIdHigh, FilterIdLow, FilterMaskIdLow и FilterMaskIdLow не так просты, как их имена.

Их функция зависит от используемого режима фильтрации. Если это режим списка, неважно, FilterId или FilterMaskId, это столбец

Члены таблицы.

Вышеупомянутые четыре члена — все 16 бит, обязательно обратите внимание на операцию сдвига, упомянутую ниже.

В 32-битном фильтре группа High и Low проверяет один и тот же CAN ID; 16-битный фильтр, вы можете независимо тестировать ID

Регистры фильтра следующие: (При использовании библиотеки HAL не нужно копаться в конкретных регистрах, просто обратите внимание на содержимое каждого бита сопоставления)

32-битный режим списка

16-битный режим списка

32-битный режим маски
Режим 16-битной маски

Стандартный кадр представлен 16-битным фильтром: FilterIdHigh, FilterIdLow, FilterMaskIdLow, FilterMaskIdLow может представлять член списка. Поскольку идентификатор стандартного кадра составляет 11 бит, необходимо сдвинуть идентификатор на 5 бит влево.

Стандартный кадр представлен 32-битным фильтром: FilterIdHigh и FilterIdLow вместе представляют идентификатор, а FilterMaskIdLow и FilterMaskIdLow вместе представляют идентификатор. Поскольку стандартный идентификатор кадра составляет 11 бит, его идентификатор необходимо сдвинуть влево на 5 бит и сохранить в High, когда он отображается, а LOW = 0 | CAN_ID_STD (что означает, что позиция IDE равна 0)

Расширенный кадр представлен 32-битным фильтром: идентификатор расширенного кадра составляет 29 бит, поэтому расширенный идентификатор кадра сначала сдвигается влево на 3 бита, и 32 бита выравниваются с высоким битом, а затем сдвигаются на 16 бит вправо, а младшие 16 бит берутся и сохраняются в высоком уровне Сдвиньте расширенный идентификатор кадра влево на 3 бита, чтобы выровнять его с 32 битами, а затем возьмите младшие 16 бит и сохраните их в низком. Конкретная операция выглядит следующим образом

CAN_FilterTypeDef sFilterConfig                                 // Определение переменной структуры настройки фильтра
uint32_t StdId =0x321;				                            // Стандартный CAN ID
uint32_t ExtId =0x1800f001;			                            // Расширенный CAN ID

sFilterConfig.FilterIdHigh = StdId<<5;			                // Стандартный идентификатор помещается в FilterIdHigh
sFilterConfig.FilterIdLow = 0|CAN_ID_STD;			            // Стандартный идентификатор, поэтому установите бит IDE в 0

sFilterConfig.FilterMaskIdHigh = ((ExtId<<3)>>16)&0xffff;       // Старшие 16 бит расширенного идентификатора кадра помещаются в FilterMaskIdHigh
sFilterConfig.FilterMaskIdLow = (ExtId<<3)&0xffff|CAN_ID_EXT;	// Старшие 16 бит расширенного идентификатора кадра помещаются в FilterMaskIdLow, а бит IDE устанавливается в 1

Что касается проверочного кода и маски: предположим, что есть список наблюдения, полный интересных сообщений. Код подтверждения может быть идентификатором любого члена в списке наблюдения (после вышеупомянутой обработки), а маска является результатом XOR всех заинтересованных членов.

Таким образом, существует две разрядности, два режима и в общей сложности четыре режима фильтрации. Характеристики суммируются следующим образом:

8.4.2 Основные функции CAN

Функции управления следующие

HAL_StatusTypeDef HAL_CAN_Start(CAN_HandleTypeDef *hcan)**

Функция: включить CAN, обычно в начале
Параметры: указатель дескриптора CAN, & hcan1 или & hcan2
Возвращаемое значение: возвращаемое значение: статус HAL

HAL_StatusTypeDef HAL_CAN_ConfigFilter(CAN_HandleTypeDef *hcan, CAN_FilterTypeDef *sFilterConfig)

Функция: настройка фильтра CAN
Параметр: первый, указатель дескриптора CAN, & hcan1 или & hcan2
Второй, указатель на структуру конфигурации CAN.
Возвращаемое значение: возвращаемое значение: статус HAL

HAL_StatusTypeDef HAL_CAN_ActivateNotification(CAN_HandleTypeDef *hcan, uint32_t ActiveITs)

Функция: разрешить прерывание
Параметр: первый, указатель дескриптора CAN, & hcan1 или & hcan2
Второй, прерывание которого разрешено, в stm32f4xx_HAL_Driver.h, ищите прерывания приема, чтобы найти каждое определение макроса
Возвращаемое значение: возвращаемое значение: статус HAL

void HAL_CAN_RxFifo0MsgPendingCallback(CAN_HandleTypeDef *hcan)(Согласно использованию0Может быть заменен на1）

Функция: функция обратного вызова приема, работа после обратного вызова CAN. Обычно получают данные здесь
Параметр: первый, указатель на дескриптор CAN
Возвращаемое значение: void

HAL_StatusTypeDef HAL_CAN_AddTxMessage(CAN_HandleTypeDef *hcan, CAN_TxHeaderTypeDef *pHeader, uint8_t aData[], uint32_t *pTxMailbox)**

Функция: добавить сообщение в первый бесплатный почтовый ящик Tx и активировать соответствующий запрос на передачу

Параметры: первый, указатель CAN-дескриптора, & hcan1 или & hcan2
Второй, указатель на структуру определения отправленного сообщения.
Третье, содержимое массива фрейма данных, длина не может превышать заданную длину
Четвертый, почтовый ящик Tx, может заполнять (uint32_t *) CAN_TX_MAILBOX0, CAN_TX_MAILBOX1, CAN_TX_MAILBOX3
Возвращаемое значение: статус HAL

HAL_StatusTypeDef HAL_CAN_GetRxMessage(CAN_HandleTypeDef *hcan, uint32_t RxFifo, CAN_RxHeaderTypeDef *pHeader, uint8_t aData[])

Функция: получение кадра CAN от Rx FIFO
Параметры: первый, указатель дескриптора CAN, & hcan1 или & hcan2
Второй, Rx FIFO, можно заполнить CAN_RX_FIFO0, CAN_RX_FIFO1
Третий — указатель на структуру определения полученного сообщения.
В-четвертых, принять массив данных
Возвращаемое значение: статус HAL

HAL_StatusTypeDef HAL_CAN_ConfigFilter(CAN_HandleTypeDef *hcan, CAN_FilterTypeDef *sFilterConfig)

Функция: Установить фильтр приема
Параметр: первый, указатель дескриптора CAN, & hcan1 или & hcan2
Второй, указатель на структуру определения типа фильтра.
Возвращаемое значение: статус HAL

8.4.3 Пример шагов программирования CAN

1. Определите переменную структуры определения типа принимающего фильтра (CAN_FilterTypeDef)

2. Настроить фильтр приема CAN HAL_CAN_ConfigFilter

3. Включите CAN, HAL_CAN_Start

4. Отправить, HAL_CAN_AddTxMessage

5. Для получения нужно сначала включить прерывание HAL_CAN_ActivateNotification, а второй параметр установить на CAN_IT_RX_FIFO0_MSG_PENDING

   Функция обратного вызова прерывания HAL_CAN_RxFifo0MsgPendingCallback, которая определяет структурную переменную структуры определения полученного сообщения (CAN_RxHeaderTypeDef). Прием с функцией приема HAL_CAN_GetRxMessage

Базовое расширенное периферийное устройство CAN (Basic Extended CAN, которое сокращенно называется bxCAN), позволяет подключить MCU STM32 с сети CAN. Поддерживаются CAN протоколы версий 2.0A и 2.0B. Контролер CAN был разработан для эффективного обслуживания большого количества входящих сообщений с минимальной нагрузкой на вычислительное ядро CPU. Также он удовлетворяет требованиям приоритета для передачи сообщений.

Примечание: информация в этой статье (перевод раздела «32 Controller area network (bxCAN)» даташита [1]) относится ко всем представителям MCU семейства STM32F4xx, если специально не указано что-то иное.

В критически важных для безопасности приложениях контроллер CAN предоставляет все аппаратные функции для поддержки опции обмена CAN Time Triggered Communication.

Основные функции и возможности bxCAN:

• Имеется два интерфейса CAN: CAN1 и CAN2.
• Поддерживается протокол CAN версий 2.0A, B Active.
• Скорости до 1 мегабит/сек.
• Поддерживается опция Time Triggered Communication.

Передача:

• 3 передающих mailbox.
• Конфигурируемый приоритет передачи.
• Метка времени (Time Stamp) на передаче SOF.

Прием:

• 2 принимающих FIFO с тремя уровнями.
• Масштабируемые банки фильтра: 28 банков фильтра, используемые совместно CAN1 и CAN2.
• Функция идентификатора списка.
• Конфигурируемый порог переполнения FIFO (FIFO overrun).
• Метка времени (Time Stamp) на приеме SOF.

Опция коммуникации Time-triggered:

• Запрет режима автоматической ретрансмиссии.
• 16-разрядный свободно считающий таймер.
• Метка времени (Time Stamp) в последних двух байтах данных.

Управление:

• Маскируемые прерывания.
• Эффективное для программы отображение mailbox на уникальный адрес.

Одновременная работа двух CAN (Dual CAN):

• CAN1: Master bxCAN для управления коммуникацией между Slave bxCAN и 512 байтами памяти SRAM.
• CAN2: Slave bxCAN, без прямого доступа к памяти SRAM.
• Два bxCAN используют общую память 512 байт SRAM (см. рис. 335).

Рис. 335. Блок-схема Dual CAN.

Примечание: начальный банк фильтров CAN2 номер n конфигурируется записью CAN2SB[5:0] бит в регистре CAN_FMR.

[Общее описание bxCAN]

В современных приложениях CAN количество узлов сети увеличивается, и часто сети соединяются друг с другом через шлюзы (gateway). Обычно количество сообщений в системе (и таким образом обрабатываемых каждым узлом) значительно увеличивается. В дополнение к сообщениям приложения были введены сообщения управления сетью и диагностики (Network Management and Diagnostic messages).

• Для обработки каждого типа сообщения требуется расширенный механизм фильтрации.

Кроме того, задачи приложения требуют большего времени CPU, поэтому должны быть уменьшены ограничения по реальному времени обработки, вызванные приемом сообщения.

• Схема FIFO приема позволяет переключить CPU на задачи приложения на долгое время без потери принимаемых сообщений.

Стандартный высокоуровневый протокол HLP (аббревиатура от Higher Layer Protocol), основанный на стандартных драйверах CAN, требует эффективного интерфейса с контроллером CAN.

Рис. 334. Топология сети CAN.

Активное ядро CAN 2.0B. Модуль bxCAN полностью автономно обрабатывает передачу и прием сообщений CAN. Стандартные идентификаторы (11 бит) и расширенные идентификаторы (29 бит) полностью поддерживаются аппаратурой контроллера.

Регистры управления, статуса и конфигурации. Приложение использует эти регистры для следующих целей:

• Конфигурирования параметров CAN, например скорости передачи/приема (baud rate).
• Запрос передач.
• Обработка приема.
• Управление прерываниями.
• Получение информации диагностики.

Передающие ящики (Tx mailboxes). Предоставлены 3 передающих mailbox, чтобы настраивать отправку сообщений. Планировщик передачи (transmission Scheduler) принимает решение, какой mailbox должен быть передан первым.

Фильтры приема (Acceptance filters). bxCAN предоставляет 28 масштабируемых / конфигурируемых банков фильтров по идентификатору, чтобы выделять из принимаемых данных нужные сообщения и отбрасывать другие.

FIFO приема. Для сохранения поступающих сообщений используются 2 приемных FIFO. В каждом FIFO можно сохранить 3 полных сообщения. FIFO полностью обслуживаются аппаратурой контроллера CAN.

[Рабочие режимы bxCAN]

У bxCAN есть 3 основных рабочих режима: initialization (инициализация), normal (активная работа) и Sleep (сон, приостановка). После аппаратного сброса bxCAN находится в режиме Sleep, чтобы снизить потребление энергии, и на CANTX активен внутренний pull-up (верхний подтягивающий резистор). Программа запрашивает bxCAN на вход в режим initialization или Sleep установкой бит INRQ или SLEEP в регистре CAN_MCR. Как только произошел вход в режим, bxCAN подтверждает это установкой бит INAK или SLAK в регистре CAN_MSR, и внутренний pull-up запрещается. Когда ни один из бит INAK и SLAK не установлен, bxCAN находится в режиме normal. Перед входом в режим normal bxCAN всегда должен быть синхронизирован с шиной CAN. Для синхронизации bxCAN ждет, пока шина CAN не освободится (перейдет в состояние idle), это означает, что отслеживается появление 11 следующих друг за другом рецессивных бита на сигнале CANRX.

Режим инициализации. Программная инициализация может быть осуществлена, когда железо CAN находится в режиме инициализации (Initialization mode). Чтобы войти в этот режим, программа устанавливает бит INRQ в регистре CAN_MCR и ждет, пока железо подтвердит этот запрос установкой бита INAK в регистре статуса CAN_MSR.

Чтобы покинуть режим инициализации, программа очищает бит INQR. bxCAN покинет режим инициализации, когда бит INAK очистится аппаратурой.

Во время режима инициализации останавливаются все входящие и исходящие транзакции сообщений CAN, и статус шины CAN на выходе CANTX сохраняется рецессивным (лог. 1).

Вход в режим инициализации не меняет ни один регистр конфигурации.

Чтобы инициализировать контроллер CAN, программа должна установить длительность бита (Bit Timing, регистр CAN_BTR) и опции CAN (регистр управления CAN_MCR).

Чтобы инициализировать регистры, связанные с банками фильтров CAN (mode, scale, FIFO assignment, activation и значения фильтраand filter values), программа должна установить бит FINIT (в регистре CAN_FMR). Инициализация фильтра также может быть осуществлена вне режима инициализации.

Примечание: когда FINIT=1, прием CAN деактивирован. Значения фильтра также можно модифицировать сбросом соответствующих бит активации (в регистре CAN_FA1R). Если банк фильтра не используется, то рекомендуется оставить его в неактивном режиме (т. е. оставить его соответствующий бит FACTx очищенным).

Нормальный режим (normal mode). Как только инициализация завершена, программа должна запросить у аппаратуры вход в нормальный режим, чтобы она могла засинхронизироваться с шиной CAN, и начать прием и передачу.

Запрос входа в Normal mode выдается очисткой бита INRQ в регистре управления CAN_MCR. Блок bxCAN входит в режим Normal и готов принять участие в активности на шине, когда он синхронизирован с передачей данных по шине CAN. Это осуществляется ожиданием появления на шине 11 следующих друг за другом рецессивных бит (состояние ожидания Bus Idle). Переключение в Normal mode подтверждается аппаратурой, когда она сбрасывает бит INAK в регистре статуса CAN_MSR.

Инициализация значений фильтра не зависит от режима инициализации, однако должна осуществляться, когда инициализируемый фильтр не активен (его соответствующий бит FACTx сброшен). Параметры фильтра scale и mode должны конфигурироваться перед входом в режим Normal.

Режим Sleep (малое потребление мощности). Чтобы уменьшить энергопотребление, у bxCAN есть режим пониженного потребления мощности (low-power mode), который называется режим сна (Sleep mode). В этот режим осуществляется вход по запросу программы установкой бита SLEEP в регистре CAN_MCR. В этом режиме тактирование bxCAN останавливается, однако программа все еще имеет доступ к ящикам (mailboxes) bxCAN.

Если программа запрашивает вход в режим инициализации установкой бита INRQ, когда bxCAN находится в Sleep mode, она также должна очистить бит SLEEP.

Блок bxCAN может быть разбужен (выведен из Sleep mode) либо программно путем очистки бита SLEEP, или когда была детектирована активность шины CAN.

Когда была определена активность на шине CAN, аппаратура автоматически выполняет последовательность пробуждения очисткой бита SLEEP, если установлен бит AWUM в регистре CAN_MCR. Если бит AWUM очищен, то программа должна очистить бит SLEEP, когда произошло прерывание пробуждения (wakeup interrupt), чтобы bxCAN вышел из Sleep mode.

Примечание: если разрешено прерывание пробуждения (wakeup interrupt, установлен бит WKUIE в регистре CAN_IER), то будет генерироваться прерывание пробуждения, когда была определена активность шины CAN, даже если bxCAN автоматически выполняет последовательность пробуждения.

После того, как бит SLEEP был очищен, произойдет выход из Sleep mode, когда bxCAN засинхронизировался с шиной CAN, см. рис. 336. Из режима Sleep mode произойдет выход, когда аппаратура очистила бит SLAK.

Рис. 336. Режимы bxCAN.

Примечания:

(1) ACK = состояние ожидания (wait state), во время которого аппаратура подтверждает запрос установкой бит INAK или SLAK в регистре CAN_MSR.
(2) SYNC = состояние, во время которого bxCAN ожидает состояния ожидания шины CAN (idle state, когда прошло 11 следующих друг за другом рецессивных бита на CANRX).

[Режим тестирования]

Режим тестирования может быть выбран битами SILM и LBKM в регистре CAN_BTR. Эти биты должны быть сконфигурированы, когда bxCAN находится в Initialization mode. Как только был выбран режим тестирования, для входа в режим Normal должен быть сброшен бит INRQ в регистре CAN_MCR.

Silent mode. Блок bxCAN может быть переведен в «тихий режим» (Silent mode) установкой бита SILM в регистре CAN_BTR.

В тихом режиме bxCAN может принимать правильные фреймы данных и правильные фреймы remote, однако bxCAN передает только рецессивные биты на шине CAN, и не может начать передачу. Если bxCAN должен отправить доминантный бит (бит ACK, флаг overload, флаг active error), то бит перемашрутизируется внутри таким образом, что ядро CAN мониторит этот доминантный бит, хотя шина CAN может оставаться в рецессивном состоянии. Silent mode может использоваться для анализа трафика на шине CAN без влияния на шину передачей доминантных бит (доминантные биты Acknowledge, фреймы ошибки Error Frame физически не передаются).

Рис. 337. Блок bxCAN в Silent Mode.

Loop back mode. Блок bxCAN может быть установлен в режим зацикливания (Loop Back Mode) установкой бита LBKM в регистре CAN_BTR. В Loop Back Mode блок bxCAN обрабатывает свои собственные передаваемые сообщения как принимаемые, и сохраняет их (если они прошли фильтрацию, acceptance filtering) в ящиках приема (Receive mailbox).

Рис. 338. Блок bxCAN в режиме зацикливания.

Этот режим предоставлен для функций самотестирования. Чтобы быть независимым от внешних событий, ядро CAN игнорирует ошибки подтверждения (acknowledge errors, отсутствие доминантного бита, оцифрованного в слоте подтверждения данных фрейма data / remote), в режиме Loop Back. В этом режиме bxCAN соединяет выход Tx со входом Rx внутри чипа. Актуальное значение входа на выводе CANRX игнорируется блоком bxCAN. Передаваемые сообщения могут мониториться на выводе CANTX.

Комбинация режимов Loop back и silent. Можно также скомбинировать режимы Loop Back и Silent установкой бит LBKM и SILM в регистре CAN_BTR. Это может использоваться для «горячего самотестирования», т. е. bxCAN может быть проверен в режиме Loop Back, но без влияния на работающую систему CAN, подключенную к выводам CANTX и CANRX. В этом режиме вывод CANRX отключен от bxCAN, и вывод CANTX удерживается в рецессивном состоянии.

Рис. 339. Блок bxCAN в комбинированном режиме.

[Debug mode]

Когда MCU вошел в отладочный режим debug mode (приостановлено ядро Cortex®-M4 с FPU), блок bxCAN продолжит нормально работать или останавливается, в зависимости от:

• Бита DBG_CAN1_STOP для CAN1 или бита DBG_CAN2_STOP для CAN2 в модуле DBG. Для получения подробностей см. секцию «38.16.2 Debug support for timers, watchdog, bxCAN and I2C» даташита [1].
• Бита DBF в регистре CAN_MCR. Для дополнительной информации см. секцию 32.9.2 даташита [1].

[Функциональное описание bxCAN]

Обработка передачи. Чтобы передать сообщение, приложение должно выбрать пустой transmit mailbox, установить идентификатор, код длины данных (data length code, DLC) и передаваемые данные перед тем, как запросить передачу установкой соответствующего бита TXRQ в регистре CAN_TIxR. Как только mailbox покинул состояние опустошенности (empty state), программа больше не может получить доступ на запись в его регистры. Сразу после установки бита TXRQ mailbox входит в состояние ожидания отправки (enters pending), и ждет, когда он станет самым приоритетным для передачи, см. врезку «Приоритет передачи». Как только mailbox получил самый высокий приоритет, он будет запланирован на передачу. Передача сообщения запланированного mailbox начнется (произойдет вход в состояние передачи), когда шина CAN окажется в состоянии ожидания (idle). Как только mailbox был успешно передан, он снова станет пустым (empty). Аппаратура покажет успешную передач установкой бит RQCP и TXOK в регистре CAN_TSR.

Если передача была неудачной, то это состояние будет показано битом ALST в регистре CAN_TSR, когда был проигрыш арбитража (Arbitration Lost), и/или битом TERR, когда была детектирована ошибка передачи.

Обрыв передачи. Запрос на передачу может быть оборван (abort) пользователем путем установки бита ABRQ в регистре CAN_TSR. Когда mailbox находится в состоянии pending или scheduled обрыв произойдет немедленно. Когда запрос на abort поступил в состоянии передачи mailbox, то состояние передачи может иметь одно из 2 результатов. Если была успешная передача, то mailbox станет пустым с установкой бита TXOK в регистре CAN_TSR. Если передача была неудачной, то mailbox получит состояние запланированности на передачу (scheduled), передача оборвется и ящик станет пустым с очищенным TXOK. Во всех случаях ящик становится пустым, как минимум в конце текущей передачи.

Режим не автоматической повторной передачи. Этот режим был реализован, чтобы удовлетворить требованиям опции Time Triggered Communication стандарта CAN. Чтобы сконфигурировать аппаратуру в этот режим, должен быть установлен бит NART в регистре CAN_MCR.

В этом режиме каждая передача начинается только однократно. Если первая попытка потерпела неудачу из-за потери арбитража или из-за ошибки, аппаратура не будет автоматически перезапускать передачу сообщения.

По окончании первой попытки передачи, аппаратура считает запрос завершенным, и установит бит RQCP в регистре CAN_TSR. Результат передачи показывается в регистре CAN_TSR битами TXOK, ALST и TERR.

Рис. 340. Состояния передающего mailbox.

Режим Time Triggered Communication. В этом режиме активируется внутренний счетчик аппаратуры CAN и используется для генерации значения метки времени (Time Stamp), сохраняемой в регистрах CAN_RDTxR/CAN_TDTxR (соответственно для Rx и Tx mailbox). Внутренний счетчик инкрементируется на каждом битовом интервале CAN, см. далее секцию «Интервалы бит (bit timing)». Внутренний счетчик захватывается в точке оцифровки (sample point) бита начала фрейма (Start Of Frame, SOF) и для приема, и для передачи.

[Обработка приема]

Для приема сообщений CAN предоставляются три mailbox, организованных как FIFO. Чтобы уменьшить нагрузку на CPU, упростить программу и гарантировать целостность данных, FIFO полностью обслуживается аппаратурой. Приложение обращается к сохраненным в FIFO сообщениям через выходной mailbox FIFO.

Корректно принятое сообщение. Принятое сообщение считается корректным (valid), когда оно было правильно принято в соответствии с протоколом CAN (не было ошибки до последнего бита, но с одним битом в поле EOF), и при этом успешно прошло фильтрацию по идентификатору (см. далее секцию «Фильтрация по идентификатору»).

Рис. 341. Состояния приемного FIFO.

Обслуживание FIFO. Начиная с состояния «пусто» (empty) FIFO, первое корректно принятое сообщение сохраняется в FIFO, который переходит в состояние pending_1 (ожидает обработки одно принятое сообщение). Аппаратура сигнализирует об этом событии установкой бит FMP[1:0] в регистре CAN_RFR в значение 01b. Сообщение становится доступным в выходном mailbox FIFO. Программа считывает текущий mailbox и освобождает его установкой бита RFOM в регистре CAN_RFR. После этого FIFO снова становится пустым. Если в этот момент было принято новое корректное сообщение, то FIFO остается в состоянии pending_1, и новое сообщение доступно в выходном mailbox FIFO.

Если программа не освободила mailbox, то следующее корректно принятое сообщение будет сохранено в FIFO, который перейдет в состояние pending_2 (FMP[1:0] = 10b). Процесс сохранения сообщений в FIFO продолжится вплоть до перехода FIFO в состояние pending_3 (FMP[1:0] = 11b). В этой точке программа должна освободить выходной mailbox FIFO установкой бита RFOM, чтобы можно было освободить mailbox для сохранения нового корректного сообщения. Иначе следующее корректное сообщение будет потеряно. См. также раздел «Хранилище сообщений».

Overrun. Как только FIFO перешел в состояние pending_3 (т. е. все mailbox заполнены), следующее поступившее сообщение приведет к переполнению приема (overrun), и сообщение будет потеряно. Аппаратура сигнализирует о состоянии overrun установкой бита FOVR в регистре CAN_RFR. Какое сообщение потеряно, зависит от конфигурации FIFO:

• Если функция блокировки FIFO (FIFO lock) запрещена (очищен бит RFLM в регистре CAN_MCR), то последнее сохраненное сообщение в FIFO будет перезаписано новым поступившим сообщением. В этом случае последние поступившие (самые свежие) сообщения будут всегда доступны для приложения.
• Если функция блокировки FIFO разрешена (установлен бит RFLM в регистре CAN_MCR), то самое свежее поступившее сообщение будет отброшено, и для программы будут всегда доступны 3 самые старые не обработанные сообщения FIFO.

Прерывания приема. Как только сообщение было сохранено в FIFO, обновятся биты FMP[1:0] и генерируется запрос прерывания, если установлен бит FMPIE в регистре разрешения прерываний CAN_IER.

Когда FIFO становится заполненным (т. е. сохранено третье сообщение), установится бит FULL в регистре CAN_RFR, и будет сгенерировано прерывание, если установлен бит FFIE в регистре разрешения прерываний CAN_IER.

При переполнении приема (overrun condition) установится бит FOVR, и будет сгенерировано прерывание, если установлен бит FOVIE в регистре разрешения прерываний CAN_IER.

[Фильтрация по идентификатору]

В протоколе CAN идентификатор сообщения не связан с адресом узла, но связан с содержимым сообщения. Следовательно, передатчик передает свое сообщение всем приемникам. Во время приема сообщения принимающий узел решает — в зависимости от значения идентификатора — нуждается программа в этом сообщении, или нет. Если сообщение нужное, то оно копируется в SRAM. Если нет, то сообщение будет отброшено без какого-либо вмешательства со стороны программы.

Чтобы удовлетворить этому требованию, контроллер bxCAN предоставляет для приложения 28 конфигурируемых и масштабируемых банков фильтра (27 .. 0). Эта аппаратная фильтрация сохраняет процессорное время CPU, которое иначе тратилось бы, если фильтрация была реализована программно. Каждый банк фильтра x состоит из двух 32-битных регистра CAN_FxR0 и CAN_FxR1.

Масштабируемая ширина (scale). Чтобы оптимизировать и адаптировать фильтрацию к требованиям приложения, каждый банк фильтра может масштабироваться независимо. В зависимости от масштаба фильтра банк фильтра предоставляет (см. рис. 342):

• Один 32-битный фильтр для бит STDID[10:0], EXTID[17:0], IDE и RTR.
• Два 16-битных фильтра для бит STDID[10:0], RTR, IDE и EXTID[17:15].

Кроме того, фильтры могут быть сконфигурированы в режиме маски (mask mode) или в режиме списка идентификаторов (identifier list mode).

Mask mode. В режиме маски регистры идентификатора связаны с регистрами маски, указывающими, какие биты в идентификаторе должны совпадать (must match), а какие могут быть любыми (don’t care).

Identifier list mode. В режиме списка идентификаторов регистры маски используются как регистры идентификатора. Таким образом, вместо определения идентификатора и маски, указываются 2 идентификатора, удваивая количество одиночных идентификаторов. Все биты приходящего идентификатора должны совпадать с битами, указанными в регистрах фильтра.

Конфигурация scale и mode банка фильтра. Банки фильтра конфигурируются соответствующим регистром CAN_FMR. Для конфигурирования банка фильтра он должен быть деактивирован очисткой бита FACT в регистре CAN_FAR. Параметр scale фильтра конфигурируется соответствующим битом FSCx регистра CAN_FS1R, см. рис. 342. Режим маски или режим списка идентификаторов для соответствующих регистров Mask/Identifier конфигурируется битами FBMx в регистре CAN_FMR.

Для фильтрации группы идентификаторов сконфигурируйте регистры Mask/Identifier в режиме маски.

Для выбора одиночных идентификаторов сконфигурируйте регистры Mask/Identifier в режиме списка идентификаторов.

Фильтры, не используемые приложением, должны быть оставлены деактивированными.

Каждый фильтр в банке фильтра пронумерован (номер называется Filter Number) от 0 до максимума, в зависимости от mode и scale каждого банка фильтра.

Конфигурация фильтра показана на рис. 342.

Рис. 342. Конфигурация масштабирования (scale) банков фильтра — организация регистров.

Примечания:

x = номеру банка фильтра.
ID = идентификатору.
(1) Эти биты находятся в регистре CAN_FS1R.
(2) Эти биты находятся в регистре CAN_FM1R.

Индекс совпадения фильтра. Как только сообщение было принято в FIFO, оно становится доступным для приложения. Обычно данные приложения копируются в ячейки SRAM. Чтобы копировать данные в правильное место, приложение должно идентифицировать данные по идентификатору. Чтобы упросить доступ к ячейкам SRAM принятых сообщений, контроллер CAN предоставляет индекс совпадения фильтра (Filter Match Index).

Этот индекс сохраняется в mailbox вместе с сообщением, в соответствии с правилами приоритета фильтра. Таким образом, каждое принятое сообщение связывает с индексом совпадения фильтра.

Индекс Filter Match может быть задействован двумя способами:

• Сравнение индекса Filter Match со списком ожидаемых значений.
• Использование индекса Filter Match как индекса в массиве для доступа к месту нахождения данных.

Для не маскируемых фильтров программа больше не должна сравнивать идентификатор.

Если фильтр маскирован, то программа ограничивает сравнение только маскированными битами.

Значение индекса номера фильтра не учитывает состояние активации банков фильтра. Дополнительно используются две независимые схемы нумерации, по одной для каждого FIFO. Пример см. на рис. 343.

Рис. 343. Пример нумерации фильтров. ID означает идентификатор.

Правила приоритезации фильтра. В зависимости от комбинации фильтров может произойти ситуация, когда идентификатор пройдет через несколько фильтров. В этом случае значение выбранного совпавшего фильтра сохраняется в mailbox приема по следующим правилам приоритета:

• 32-битный фильтр имеет приоритет над 16-битным фильтром.
• Для фильтров с одинаковым scale, приоритет предоставляется режиму списка идентификаторов (Identifier List mode) над режимом маски идентификаторов (Identifier Mask mode).
• Для фильтров с одинаковым scale и mode, приоритет дается по номеру фильтра (чем меньше номер, тем выше приоритет).

Рис. 344. Пример механизма фильтрации. Три банка фильтра сконфигурированы в 32-битном Unidentified List mode, остальные в 32-битном Identifier Mask mode.

На рис. 344 выше показан пример принципа фильтрации bxCAN. На приеме сообщения идентификатор сначала сравнивается с фильтрами, сконфигурированными в identifier list mode. Если было совпадение, то сообщение сохранятся в связанном FIFO и индекс совпавшего фильтра сохраняется в Filter Match Index (FMI). Как показано в примере, идентификатор совпал с Identifier #2, так что в FIFO будет сохранено содержимое сообщения и FMI 2.

Если не было совпадения, пришедший идентификатор сравнивается с фильтрами, сконфигурированными в mask mode.

Если идентификатор не совпал ни с одним из идентификаторов, сконфигурированным в фильтрах, то сообщение отбрасывается аппаратно, никак не влияя на программу.

[Хранилище сообщений]

Интерфейс между программой и аппаратурой для сообщений CAN реализован через ящики (mailboxes). Mailbox содержит всю информацию, относящуюся к сообщению: идентификатор, данные, управление, статус и метку времени.

Transmit mailbox. Программа настраивает сообщение для передачи в пустом передающем mailbox. Статус передачи показывается аппаратурой в регистре CAN_TSR.

Таблица 182. Отображение ящиков передачи (TX mailbox) передачи.

Receive mailbox. Когда было принято сообщение, оно становится доступным в выходном mailbox FIFO. Когда программа обработала сообщение (т. е. прочитала его), она должна освободить выходной mailbox FIFO с помощью бита RFOM в регистре CAN_RFR, чтобы стало доступным для чтения следующее приходящее сообщение. Индекс совпавшего фильтра сохраняется в поле MFMI регистра CAN_RDTxR. 16-битное значение метки времени (time stamp) сохраняется в поле TIME[15:0] регистра CAN_RDTxR.

Таблица 183. Отображение ящиков (RX mailbox) приема.

[Обработка ошибок]

Обработка ошибок (error management), как это описано в протоколе CAN, осуществляется полностью аппаратно, с использованием счетчика ошибок передачи Transmit Error Counter (значение TEC в регистре CAN_ESR) и счетчика ошибок приема Receive Error Counter (значение REC в регистре CAN_ESR), которые инкрементируются по мере появления событий ошибки. Более подробно обслуживание TEC и REC описано в стандарте CAN.

Оба счетчика TEC и REC могут быть прочитаны программой, чтобы определить стабильность сети CAN. Кроме того, аппаратура CAN предоставляет подробную информацию о текущем статусе ошибки в регистре CAN_ESR. Через регистр CAN_IER (бит ERRIE и т. п.), программа может очень гибко сконфигурировать прерывание при детектировании ошибки.

Рис. 345. Диаграмма состояний ошибки CAN.

Восстановление из Bus-Off. Состояние Bus-Off (отключение от шины) достигается, когда TEC становится больше 255, это состояние индицируется битом BOFF регистра CAN_ESR. В состоянии Bus-Off блок bxCAN больше не может передавать и принимать сообщения.

В зависимости от бита ABOM в регистре CAN_MCR, блок bxCAN будет восстанавливаться из Bus-Off (переходить в состояние error active) либо автоматически, либо по запросу программы. Однако в обоих случаях bxCAN будет ждать как минимум последовательности восстановления (recovery sequence), описанную в стандарте CAN (128 случаев появления 11 следующих друг за другом рецессивных бит, обнаруженных на CANRX).

Если установлен ABOM, то bxCAN автоматически начнет последовательность восстановления после того, как произошел вход в состояние Bus-Off. Если ABOM очищен, то программа должна инициировать последовательность восстановления путем запроса к bxCAN на вход в режим инициализации и на выход из него.

Примечание: в режиме инициализации bxCAN не мониторит сигнал CANRX, поэтому не может завершить последовательность восстановления. Для восстановления bxCAN должен быть в normal mode.

[Интервалы бит (bit timing)]

Логика тайминга бита мониторит последовательную линию шины и выполняет оцифровку сигнала с подстройкой точки выборки. Это делается синхронизацией по перепаду начального бита, и повторной синхронизацией на последующих перепадах.

Эта операция может быть объяснена простым разделением номинального времени бита на 3 сегмента следующим образом:

• Сегмент синхронизации (SYNC_SEG): во время этого интервала времени ожидается изменение бит. Величина этого сегмента фиксируется на одном кванте времени (time quantum): 1 x t_q.
• Сегмент бита 1 (Bit segment 1, BS1): определяет положение точки выборки уровня сигнала (sample point). Стандарт включает сюда интервалы PROP_SEG (сегмент распространения) и PHASE_SEG1 (сегмент фазы 1). Длительности этих интервалов программируются между 1 и 16 time quanta, однако они могут быть автоматически увеличены для компенсации положительного дрейфа фазы из-за разницы частот тактов различных узлов в сети.
• Сегмент бита 2 (Bit segment 2, BS2): определяет положение точки передачи (transmit point). Представлен в стандарте CAN интервалом PHASE_SEG2 (сегмент фазы 2). Его длительность программируется в диапазоне от 1 до 8 time quanta, однако этот интервал может быть автоматически сокращен для компенсации отрицательных смещений фазы.

Параметр ширины скачка ресинхронизации (resynchronization Jump Width, SJW) определяет верхнюю границу величины удлинения или укорочения сегментов бита. Программируется в диапазоне от 1 до 4 time quanta.

Достоверный перепад детектируется как первый переход в интервале бита от доминантного к рецессивному уровню шины при условии, что контролер сам не передает рецессивный бит.

Если достоверный перепад был детектирован в BS1 вместо SYNC_SEG, BS1 расширяется на интервал SJW, чтобы точка выборки была задержана. Соответственно, если достоверный перепад был определен в интервале BS2 вместо SYNC_SEG, интервал BS2 укорачивается на SJW, чтобы точка передачи оказалась раньше.

В качестве защиты от ошибок программирования конфигурация Bit Timing Register (CAN_BTR) возможна только когда устройство находится в режиме Standby.

Примечание: подробное описание тайминга бит CAN и механизма ресинхронизации см. в стандарте ISO 11898.

Рис. 346. Интервалы бит.

                  1
BaudRate = —————-
            NominalBitTime

NominalBitTime = 1 x t_q + t_BS1 + t_BS2

Здесь:

t_BS1 = t_q x (TS1[3:0] + 1),
t_BS2 = t_q x (TS2[2:0] + 1),
t_q = (BRP[9:0] + 1) x t_PCLK

t_q обозначает Time quantum.

t_PCLK = период тактов APB, BRP[9:0], TS1[3:0] и TS2[2:0] определены в регистре CAN_BTR.

Рис. 347. Фреймы CAN.

Примечания:

0 ≤ N ≤ 8
SOF = Start Of Frame (начало фрейма).
ID = Identifier (идентификатор).
RTR = Remote Transmission Request (запрос на передачу от удаленного сетевого узла).
IDE = Identifier Extension Bit (бит расширения идентификатора).
r0 = Reserved Bit (зарезервированный бит).
DLC = Data Length Code (код длины данных).
CRC = Cyclic Redundancy Code (контрольная сумма).
Error flag: флаг ошибки, 6 доминантных бит, если на узле активная ошибка, иначе 6 рецессивных бит.
Suspend transmission: приостановка передачи, применимо только к узлам с пассивной ошибкой.
EOF = End of Frame (конец фрейма).
ACK = Acknowledge bit (бит подтверждения).
Ctrl = Control (управление).

[Прерывания bxCAN]

Для bxCAN выделено 4 вектора прерывания. Каждый источник прерывания может быть независимо разрешен или запрещен программированием регистра разрешения прерываний CAN (CAN Interrupt Enable Register, CAN_IER).

Рис. 348. Флаги событий и генерация прерываний.

• Прерывание передачи (transmit interrupt) может генерироваться от следующих событий:
   – Transmit mailbox 0 стал пустым, установился бит RQCP0 в регистре CAN_TSR.
   – Transmit mailbox 1 стал пустым, установился бит RQCP1 в регистре CAN_TSR.
   – Transmit mailbox 2 стал пустым, установился бит RQCP2 в регистре CAN_TSR.
• Прерывание FIFO0 может генерироваться от следующих событий:
   – Прием нового сообщения, биты FMP0 в регистре CAN_RF0R не равны 00b.
   – Состояние заполненности FIFO0, установлен бит FULL0 в регистре CAN_RF0R.
   – Состояние переполнения FIFO0 (overrun), установлен бит FOVR0 в регистре CAN_RF0R.
• Прерывание FIFO 1 может генерироваться от следующих событий:
   – Прием нового сообщения, биты FMP1 в регистре CAN_RF1R не равны 00b.
   – Состояние заполненности FIFO1, установлен бит FULL1 в регистре CAN_RF1R.
   – Состояние переполнения FIFO1 (overrun), установлен бит FOVR1 в регистре CAN_RF1R.
• Прерывание ошибки и изменения статуса может быть сгенерировано следующими событиями:
   – Произошла ошибка (Error condition), подробную информацию о характере ошибки можно получить в регистре статуса ошибки (CAN Error Status register, CAN_ESR).
   – Пробуждение (Wakeup condition), на сигнале приема CAN Rx обнаружено начало фрейма (SOF).
   – Вход в режим сна (Sleep mode).

[Регистры CAN]

К регистрам периферийного устройства CAN нужно обращаться как к словам (32-битный доступ). Смещение адреса указано относительно базового адреса CAN1_BASE или CAN2_BASE (можно узнать в файле stm32f407xx.h). Для адресного пространства CAN1 зарезервированы адреса 0x40006400 .. 0x400067FF (базовый адрес 0x40006400). Для адресного пространства CAN2 зарезервированы адреса 0x40006800 .. 0x40006BFF (базовый адрес 0x40006800). Регистры со смещениями от 0x200 до 0x31C имеются только у CAN1.

Защита доступа к регистрам. Ошибочный доступ к определенным конфигурационным регистрам может привести к тому, что аппаратура временно нарушит работу всей сети CAN. Таким образом, регистр CAN_BTR может быть модифицирован программой только когда аппаратура CAN находится в режиме инициализации (initialization mode).

Хотя передача некорректных данных не приведет к проблемам на сетевом уровне CAN, это может сильно помешать работе приложения. Передающий mailbox может быть изменен программой только когда mailbox в состоянии empty, см. рис. 340.

Значения фильтра могут быть изменены либо деактивацией банков фильтра, либо установкой бита FINIT. Кроме того, модификация конфигурации фильтра (scale, mode и назначение FIFO) в регистрах CAN_FMxR, CAN_FSxR и CAN_FFAR может быть только когда установлен режим инициализации фильтра (filter initialization mode, FINIT=1) в регистре CAN_FMR.

[Регистры управления и состояния]

[Регистры CAN mailbox]

В этом разделе описываются регистры ящиков сообщений передачи и приема (mailbox, подробнее см. раздел «Хранилище сообщений»).

У ящиков передачи и приема одни и те же регистры, кроме:

• Поля FMI в регистре CAN_RDTxR.
• Приемный mailbox всегда защищен от записи.
• Передающий mailbox можно записывать только когда он пуст, т. е. когда установлен соответствующий бит TME в регистре CAN_TSR.

Есть 3 передающих ящика (TX Mailbox) и 2 приемных ящика (RX Mailbox), как показано на рис. 349. Каждый RX Mailbox позволяет получить доступ к FIFO глубиной в 3 уровня (стек глубиной в 3 сохраненных сообщения), причем доступ в FIFO предоставляется к самому старому принятому сообщению. Каждый mailbox состоит из 4 регистров.

Рис. 349. Ящики приема и передачи.

[Регистры фильтра CAN]

Для отображения / адресов регистров банков фильтра см. таблицу 184.

[Ссылки]

1. RM0090 Reference manual STM32F405/415, STM32F407/417, STM32F427/437 and STM32F429/439 advanced Arm®-based 32-bit MCUs site:st.com.

Вот и настало время, когда обсохло молоко на губах и перестали течь сопли из носа, накопил немного опыта, которым могу теперь поделиться с другими подготовленными начинающими .

Т.к. урок(и) будут рассчитан для начинающих, то и вестись они будут на связке CubeMX + Keil с использованием «могучей» библиотеки HAL (знающие поймут почему в кавычках), в связи с чем очень прошу не разводить полемику по поводу пристрастий к отдельным CMSIS, HAL, SPL, ни под каким соусом.
В качестве подопытного я решил использовать STM32F042K6T6

в семи известном и любимом корпусе ATMEGA8 (LQFP32), периферию можно посмотреть в кубе. Почему именно он? Во первых он у меня есть, во вторых Keil для него абсолютно бесплатный без каких либо ограничений, в третьих HAL дает возможность перенести код на другой камень без особых проблем (и мозги заодно потренировать в процессе, в виде закрепления материала)
Собственно приступим к самому уроку.
Запускаем куб, выбираем новый проект и камень. Включаем RCC(тактирование от внешнего кварца), SYS (активируем ноги для программирования ST-Link V2), CAN и две ножки на выход что б можно было поморгать диодиками и самое главное потом ногу PB8 посадить на землю иначе МК будет в режиме bootloader HAL про эту ногу позабыл))).

Настраиваем тактирование:

Следующая вкладка Configuration
Проверяем режим GPIO для диодиков, все по Default:

и ползем в настройка CAN:

Строчка Time for one bit имеет прямое отношение к скорости передачи CAN Kbit/s, стандартные скорости:
1000, 500, 250, 125, 100, 83.3, 50, 20, 10 Kbit/s
Моя формула для расчета скорости Time for one bit(ns)=1000000/X
где X скорость в Kbit/s, вот под расчетную скорость и начинаем просчитывать Prescaler, Time Quanta in Bit Segment 1 и Time Quanta in Bit Segment 2
А теперь самое интересное, как все это дело правильно посчитать, все дело в квантах)))
P.S. сам я не особо во все это въехал, но все же расскажу со своей колокольни.
Строчка Time Quantum показывает длину одного кванта она зависит только от делителя.
Вот нашел картинку про кванты:

по картинке мы имеем:
Sync_Seg содержит только 1tq
Prop_Seg + Phase_Seg1 может содержать 1-16tq, строчка в коде hcan.Init.BS1 = CAN_BS1_5TQ;
Phase_Seg2 может содержать 1-8tq, строчка в коде hcan.Init.BS2 = CAN_BS2_2TQ;

По картинке имеем 8 квантов, 1 квант на синхронизацию, 5 на первую фазу и 2 на вторую, для скорости 500Kbit/s (2000ns) Time Quantum=2000/8=250ns, т.е. Prescaler нужно подобрать такой, что бы Time Quantum был равен 250ns.
На что влияет соотношение BS1 к BS2 я так и не смог осознать или понять))), в разных источниках по разному, но по факту выходит, что BS1 должен быть больше BS2 или
как в другом источнике BS1=~(87,5%(BS1+BS2)), мне встречалось следующее BS1/BS2
4/3, 13/2, 6/5, и даже 6/8, 5/6 что как мне показалось не есть правильно, но хз…
P.S. в процессе написания пришлось немного разобраться в этих квантах)))
Если кто то знает больше, пишите, добавлю в статью)))
Продолжим, в самой нижней строчке режим работы
Normal — и прием и передача
LoopBack — передача и слушает сам себя
Silent — только прием и слушает сам себя
Silent+ LoopBack — полностью отключен от внешнего мира)))
Мы выбираем режим Normal.
И чуть не забыл вкладка NVIC Settings поставить галку на против CAN:

Переходим в Project->Settings и придумываем название проекту, место для хранения и для какой IDE собрать проект (MDK-ARM V5) и последний шаг Project->Generate Code

Открываем проект в Keil и сразу жмакаем на собрать проект (кнопка F7) что бы появились все связи.

Пропишем структуры приема и передачи:
/* Private variables ———————————————————*/
static CanTxMsgTypeDef canTxMessage;
static CanRxMsgTypeDef canRxMessage;
определим нашу рукописную функцию передачи
и несколько переменных для приема:
/* Private function prototypes ————————————————*/
void CAN_Transmit(void);

/* USER CODE END PFP */

/* USER CODE BEGIN 0 */
uint16_t CAN_ID;
uint8_t CAN_DLC;
uint8_t DATA[8];
сама функция передачи:
void CAN_Transmit(void)
{
hcan.pTxMsg->StdId = 0x222;
hcan.pTxMsg->DLC = 8;
hcan.pTxMsg->Data[0] = 1;
hcan.pTxMsg->Data[1] = 2;
hcan.pTxMsg->Data[2] = 3;
hcan.pTxMsg->Data[3] = 4;
hcan.pTxMsg->Data[4] = 5;
hcan.pTxMsg->Data[5] = 6;
hcan.pTxMsg->Data[6] = 7;
hcan.pTxMsg->Data[7] = 8;
HAL_CAN_Transmit(&hcan, 10);
}

и функцию обработчика прерывания по приему с моргающим диодом на ноге PB3 сигнализирующем о удачном принятии посылки:
void HAL_CAN_RxCpltCallback(CAN_HandleTypeDef* CanHandle)
{
HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_3);
CAN_ID = CanHandle->pRxMsg->StdId;
CAN_DLC = CanHandle->pRxMsg->DLC;
DATA[0] = CanHandle->pRxMsg->Data[0];
DATA[1] = CanHandle->pRxMsg->Data[1];
DATA[2] = CanHandle->pRxMsg->Data[2];
DATA[3] = CanHandle->pRxMsg->Data[3];
DATA[4] = CanHandle->pRxMsg->Data[4];
DATA[5] = CanHandle->pRxMsg->Data[5];
DATA[6] = CanHandle->pRxMsg->Data[6];
DATA[7] = CanHandle->pRxMsg->Data[7];
HAL_CAN_Receive_IT(&hcan, CAN_FIFO0);
}

Не забываем про структуры и настраиваем CAN фильтры в режиме IDLIST(перечисляем нужные нам ID), т.к. регистры 16 бит а ID посылки 11 бит и передача организована со старшего бита, то приходится ID двигать влево на 5 бит, не я так придумал)))
Через наш фильтр проскочат только:
0x53A, 0x53D, 0x54D, 0x54F, 0xA, 0x33, 0x44, 0x55, на остальные ID МК ни как не среагирует.
/* USER CODE BEGIN 2 */
hcan.pTxMsg = &canTxMessage;
hcan.pRxMsg = &canRxMessage;

CAN_FilterConfTypeDef canFilterConfig;
canFilterConfig.FilterNumber = 0;
canFilterConfig.FilterMode = CAN_FILTERMODE_IDLIST;
canFilterConfig.FilterScale = CAN_FILTERSCALE_16BIT;
canFilterConfig.FilterIdHigh = 0x53A<<5;
canFilterConfig.FilterIdLow = 0x53D<<5;
canFilterConfig.FilterMaskIdHigh = 0x54D<<5;
canFilterConfig.FilterMaskIdLow = 0x54F<<5;
canFilterConfig.FilterFIFOAssignment = 0;
canFilterConfig.FilterActivation = ENABLE;
canFilterConfig.BankNumber = 1;
HAL_CAN_ConfigFilter(&hcan, &canFilterConfig);

canFilterConfig.FilterNumber = 1;
canFilterConfig.FilterIdHigh = 0xA<<5;
canFilterConfig.FilterIdLow = 0x33<<5;
canFilterConfig.FilterMaskIdHigh = 0x44<<5;
canFilterConfig.FilterMaskIdLow = 0x55<<5;
HAL_CAN_ConfigFilter(&hcan, &canFilterConfig);

HAL_CAN_Receive_IT(&hcan, CAN_FIFO0) ;

/* USER CODE END 2 */

Ну и в главном цикле моргаем диодом на ноге PA15 и шлем сообщение в CAN каждые 200мсек
CAN_Transmit();
HAL_Delay(200);
HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_15);

Финальная проверка на CAN Hacker, при отправке ID прописанными в фильтре, диодик весело моргает.

готовый проект googl диск
про отладочную плату
Продолжение