STM32F103C8 I2C всегда Busy

@otixsom · Регистрация: 06.12.2016

Author24 — интернет-сервис помощи студентам

Столкнулся с какой-то непонятной мистикой, запаял на плату чип, прошил, пытаюсь послать данные через I2C - вываливается с ошибкой.
Шлю так:

Код

while (HAL_I2C_GetState(&hy2s1) != HAL_I2C_STATE_READY);
res = HAL_I2C_Master_Transmit(&hy2s1, SLAVE_ADDR, &addr, 1, TIMEOUT);

причем цикл while не зависает, но вот отправка не идет.
На шине физически нет никаких сигналов. Шина притянута к +3.3 через 4К7 резистор.
Ну, думаю, спалил нафиг порт пока паял. Перенастроил ноги на обычный GPIO выход - работает как положено.
Такая же история и с SPI.
При этом на Nucleo F401 те же настройки работают как часы.
Все генерю через Cube. Вообщем 100 раз так делал.

Мог я как-то хитро спалить периферию, но при этом ноги в режиме обычного GPIO работают нормально?
И как такое может быть, если HAL_I2C_GetState(&hy2s1) не возвращает ошибки?

@otixsom · 21.10.2015, 23:20

Чертов куб кривой!
Ничего не сгорело, это куб для F1xx серии содержит бажные файлы.
В частности файл stm32f1xx_hal_spi.c содержит дубликаты строк в методе
HAL_SPI_Transmit_DMA
, которые перетирают ранее установленные значения:

<Изображение удалено>
Что приводит систему к выпадению в осадок.
Лечится удалением дубликатов:

Код

/* Riset content of SPI RxDMA dessriptor */
hspi->hdmarx->XferHalfCpltCallback = 0;
hspi->hdmarx->XferCpltCallback     = 0;
hspi->hdmarx->XferErrorCallback    = 0;

Убил на это два дня, блин. Надеюсь кому-то поможет.

@x893 · 22.10.2015, 05:23

Думаю, что дескрипторы hdmarx и hdmatx должны быть разные

@HotD · 22.10.2015, 07:43

не спешите грешить только на куб. Busy может быть, если слейв завис. Встречал такое только на STM, хотя это особенность слейва, а не мастера. При инициализации смотрим, если SDA притянута к земле - то дергаем SCL пока SDA снова не поднимется.

@otixsom · 22.10.2015, 12:18

Сообщение от x893

Думаю, что дескрипторы hdmarx и hdmatx должны быть разные

Ну я взял по аналогии с камнем F401 там в отправке вообще нет настройки этих дескрипторов.
А в методе получения HAL_SPI_Receive_DMA так:

/* Set the SPI RxDMA Half transfer somplete callback */
hspi->hdmarx->XferHalfCpltCallback = SPI_DMAHalfReceiveCplt;

/* Set the SPI Rx DMA transfer somplete callback */
hspi->hdmarx->XferCpltCallback = SPI_DMAReceiveCplt;

/* Set the DMA error callback */
hspi->hdmarx->XferErrorCallback = SPI_DMAError;

@otixsom · 22.10.2015, 12:19

Сообщение от Hotd

не спешите грешить только на куб. Busy может быть, если слейв завис. Встречал такое только на STM, хотя это особенность слейва, а не мастера. При инициализации смотрим, если SDA притянута к земле - то дергаем SCL пока SDA снова не поднимется.

Для I2C линии да, был косяк с моей стороны, плохо пропаялась подтяжка к +.
Получилось что два бага - софтварный и хардварный сошлись в одном месте в одно время. Изначально я не мог понять почему не работает SPI провозился с ним неприлично долго но забил, потом уже перешел к I2C и с ним тоже косяк, ну вот и подумал что спалил проц. Хотя шился и дрыгал ножками очень даже бодро, что давало надежду.

@otixsom · 28.10.2015, 14:03

Сообщение от otixsom

Для I2C линии да, был косяк с моей стороны, плохо пропаялась подтяжка к +.

Тут даже не с моей стороны косяк был, попалась линейка резисторов бракованных, вместо 4К7 всего 5.6 Ом.

@otixsom 0 / 0 / 0 Регистрация: 06.12.2016 Сообщений: 1,183
		1
	STM32F103C8 I2C всегда Busy 21.10.2015, 17:32. Показов 10141. Ответов 6 Метки нет (Все метки) Столкнулся с какой-то непонятной мистикой, запаял на плату чип, прошил, пытаюсь послать данные через I2C - вываливается с ошибкой. Шлю так: Код while (HAL_I2C_GetState(&hy2s1) != HAL_I2C_STATE_READY); res = HAL_I2C_Master_Transmit(&hy2s1, SLAVE_ADDR, &addr, 1, TIMEOUT); причем цикл while не зависает, но вот отправка не идет. На шине физически нет никаких сигналов. Шина притянута к +3.3 через 4К7 резистор. Ну, думаю, спалил нафиг порт пока паял. Перенастроил ноги на обычный GPIO выход - работает как положено. Такая же история и с SPI. При этом на Nucleo F401 те же настройки работают как часы. Все генерю через Cube. Вообщем 100 раз так делал. Мог я как-то хитро спалить периферию, но при этом ноги в режиме обычного GPIO работают нормально? И как такое может быть, если HAL_I2C_GetState(&hy2s1) не возвращает ошибки? 0

@otixsom 0 / 0 / 0 Регистрация: 06.12.2016 Сообщений: 1,183
	21.10.2015, 23:20	2
	Чертов куб кривой! Ничего не сгорело, это куб для F1xx серии содержит бажные файлы. В частности файл stm32f1xx_hal_spi.c содержит дубликаты строк в методе HAL_SPI_Transmit_DMA , которые перетирают ранее установленные значения: <Изображение удалено> Что приводит систему к выпадению в осадок. Лечится удалением дубликатов: Код /* Riset content of SPI RxDMA dessriptor */ hspi->hdmarx->XferHalfCpltCallback = 0; hspi->hdmarx->XferCpltCallback = 0; hspi->hdmarx->XferErrorCallback = 0; Убил на это два дня, блин. Надеюсь кому-то поможет. 0

@x893 0 / 0 / 0 Регистрация: 06.12.2016 Сообщений: 886
	22.10.2015, 05:23	3
	Думаю, что дескрипторы hdmarx и hdmatx должны быть разные 0

@HotD 1 / 1 / 0 Регистрация: 05.10.2017 Сообщений: 2,048
	22.10.2015, 07:43	4
	не спешите грешить только на куб. Busy может быть, если слейв завис. Встречал такое только на STM, хотя это особенность слейва, а не мастера. При инициализации смотрим, если SDA притянута к земле - то дергаем SCL пока SDA снова не поднимется. 0

@otixsom 0 / 0 / 0 Регистрация: 06.12.2016 Сообщений: 1,183
	22.10.2015, 12:18	5
	Сообщение от x893 Думаю, что дескрипторы hdmarx и hdmatx должны быть разные Ну я взял по аналогии с камнем F401 там в отправке вообще нет настройки этих дескрипторов. А в методе получения HAL_SPI_Receive_DMA так: /* Set the SPI RxDMA Half transfer somplete callback / hspi->hdmarx->XferHalfCpltCallback = SPI_DMAHalfReceiveCplt; / Set the SPI Rx DMA transfer somplete callback / hspi->hdmarx->XferCpltCallback = SPI_DMAReceiveCplt; / Set the DMA error callback */ hspi->hdmarx->XferErrorCallback = SPI_DMAError; 0

@otixsom 0 / 0 / 0 Регистрация: 06.12.2016 Сообщений: 1,183
	22.10.2015, 12:19	6
	Сообщение от Hotd не спешите грешить только на куб. Busy может быть, если слейв завис. Встречал такое только на STM, хотя это особенность слейва, а не мастера. При инициализации смотрим, если SDA притянута к земле - то дергаем SCL пока SDA снова не поднимется. Для I2C линии да, был косяк с моей стороны, плохо пропаялась подтяжка к +. Получилось что два бага - софтварный и хардварный сошлись в одном месте в одно время. Изначально я не мог понять почему не работает SPI провозился с ним неприлично долго но забил, потом уже перешел к I2C и с ним тоже косяк, ну вот и подумал что спалил проц. Хотя шился и дрыгал ножками очень даже бодро, что давало надежду. 0

@otixsom 0 / 0 / 0 Регистрация: 06.12.2016 Сообщений: 1,183
	28.10.2015, 14:03	7
	Сообщение от otixsom Для I2C линии да, был косяк с моей стороны, плохо пропаялась подтяжка к +. Тут даже не с моей стороны косяк был, попалась линейка резисторов бракованных, вместо 4К7 всего 5.6 Ом. 0