Здравствуйте, у меня тут ребус

У мастера stm32f407 на i2c шине висят slave устройства.
У мастера есть пин, которым он может сделать аппаратный сброс этих устройств (всех сразу).

При зависании одного из slave устройств, мастер должен прекратить работу на шине, дернуть за сброс, возобновить работу по шине.

А непонятка в следующем: какого-то хрена сброс slave устройств и дальнейшая работа по шине возможна только во время старта мастера, но до инициализации шины i2c.
А когда мастер уже инициализировал свою шину, тогда после сброса slave устройств дальнейшая работа по шине невозможна (вызов HAL_I2C_Master_Receive возвращается с ошибкой HAL_BUSY)

===============================================================
Такая последовательность запуска мастера работает:
HAL_Init();
SystemClock_Config();
MX_GPIO_Init();
MX_DMA_Init();
MX_UART4_Init();
MX_USART1_UART_Init();

reset_i2c3m_subsystems();
MX_I2C3_Init();

MX_RTC_Init();
MX_I2C2_Init();
MX_I2C1_Init();

далее работа по шине идет нормально
.......................................................

===============================================================
Такая последовательность запуска мастера НЕ работает:
HAL_Init();
SystemClock_Config();
MX_GPIO_Init();
MX_DMA_Init();
MX_UART4_Init();
MX_USART1_UART_Init();

MX_I2C3_Init();
reset_i2c3m_subsystems();

MX_RTC_Init();
MX_I2C2_Init();
MX_I2C1_Init();

HAL_I2C_Master_Receive возвращает HAL_BUSY
....................................................................

================================================================
Содержимое функции сброса простое.
void reset_i2c3m_subsystems(){
//HAL_I2C_MspDeInit(&hi2c3); // Не помогает
HAL_GPIO_WritePin(RST_DEV_GPIO_Port, RST_DEV_Pin, GPIO_PIN_RESET);
HAL_Delay(10);
HAL_GPIO_WritePin(RST_DEV_GPIO_Port, RST_DEV_Pin, GPIO_PIN_SET);
HAL_Delay(100);
//HAL_I2C_MspInit(&hi2c3); //не помогает
}

=================================================================
=================================================================
Обнаружил, что работе шины мешает сброс устройств именно после инициализации SCL. Функция ниже вызывается из MX_I2C3_Init():

void HAL_I2C_MspInit(I2C_HandleTypeDef* i2cHandle){
.............................................................................
.............................................................................
/**I2C3 GPIO Configuration
PC9 ------> I2C3_SDA
PA8 ------> I2C3_SCL
*/
.............................................................................
.............................................................................
>>> Если сброс slave устройств сделать здесь, шина будет работать

GPIO_InitStruct.Pin = GPIO_PIN_8;
GPIO_InitStruct.Mode = GPIO_MODE_AF_OD;
GPIO_InitStruct.Pull = GPIO_PULLUP;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
GPIO_InitStruct.Alternate = GPIO_AF4_I2C3;
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

>>> Если сброс slave устройств сделать здесь, шина работать НЕ будет
.............................................................................
.............................................................................
}


На осциллографе до и после инициализации шины изменений не видно, линии к земле не прижаты
Уже башку сломал



Сообщение отредактировал simark1979 - Feb 5 2018, 15:34

так вы залезьте внутрь HAL_I2C_Master_Receive и посмотрите причину HAL_BUSY. Там не так много вариантов

Видимо религия запрещает использовать Step Into кнопку.

Спасибо за пинок в нужном направлении, сейчас выяснил, что все-таки во время сброса slave устройств кто-то из них кратковременно дважды притягивает обе линии к земле, в следствие чего у регистра I2C_SR2 выставляется бит 1 в единицу. А в DM00031020.pdf на стр 872 написано.
1 BUSY: Bus busy
0: No communication on the bus
1: Communication ongoing on the bus
– Set by hardware on detection of SDA or SCL low
– cleared by hardware on detection of a Stop condition.
It indicates a communication in progress on the bus. This information is still updated when
the interface is disabled (PE=0).

Теперь вопрос, как это дело похерить....

Сообщение отредактировал simark1979 - Feb 5 2018, 18:46

Попробовать если 3.1.16 Bus clear

А нельзя ли действовать в такой последовательности: i2C Disable ->Devices Reset ->i2C Enable?
Когда Вы сбрасываете устройство, оно может свести с ума Ваш процессор непредсказуемым сочетанием сигналов на шине.

Тема тоже актуальная, но там речь идет от том когда slave прижимает SDA и в этот момент происходит перезапуск мастера и мастер клокать перестает. А slave то ждет клок и до потери пульса будет держать SDA в прижатом состоянии. Для того чтобы вернуть себе шину, мастер должен проклокать, пока SDA не отпустят. А далее начинать работу с шиной заново.
Я с этой фигней столкнулся, но решил экспериментальным путем.

Но спасибо, это была интересная информация для меня







Вообще для меня это очень неприятная новость, что так ведут себя слэйвы при старте (их программировал мой бывший сотрудник).
Ведь любая перезагрузка одного из слэйвов, может подвесить всю шину.
Как Вы предлагаете я пробовал, но в этом случае сначала по шине приходит TIMEOUT, а далее опять BUSY......и обе линии кто-то прижимает.
пока не понял в чем дело

Очевидный вывод из этой истории: если пишем slave i2c устройство, нужно его правильно инициализировать.
Чтобы при своем запуске они не дергали SDA/SCL дабы не подвесить всю шину.

Сообщение отредактировал simark1979 - Feb 5 2018, 20:20

Два варианта. HAL писали или немцы или индусы. Первые живут в идеальном мире, вторые к нему стремятся.
Совет - выбросьте это Кхалл. Чтение документации по периферии + написание даже на CMSIS (лучше STDLIB) + отладка = займет в 100 раз меньше времени, чем написание костылей и сложного обхода граблей Кхалла. Извините за скромность - не выдержал.
Из-за массовой рекламы и политики STM, этот кхалл разбросан по всему интернету, очень сложно не вступить.

Сообщение отредактировал картошка - Feb 20 2018, 13:54