Месяц ждать? А на месте купить? Запрос "saleae logic петербург купить" выдает цену ~700 рублей.

сегодня куплю вечером его.
Утром будет у меня уже.

пока давайте еще в осцилл посмотрим.
http://prntscr.com/cs3vat

При нормальной работе идет пачка из 5 пакетов. Адрес моего слейва 0х01

Почему NAK приходит первым пакетом?

Вроде же, ACK там на осциллограмме. 9-й бит защёлкивается ноль, это ACK.

да, правильно. на 9-м бите в нуле зеленый луч. Это АСК.
Вторая пачка всегда в нуле. Тоже нормально?

Тут уж Вам виднее. Судя по биту направления, идёт чтение, читается нулевой байт, а правильно это или нет, определяется логикой обмена.

Кстати, не наблюдаете проблем с мастером? Т.е. между фронтами не мало времени? Должен по опыту аппаратный I2C работать?

Ну, фронты не только мастер определяет, в случае бита ACK/NACK его установка зависит от расторопности слейва, и у вас она на пределе, я бы сказал. Также видно, что мастер меняет SDA практически одновременно с падением вниз SCL, что как раз и может способствовать появлению ложных START/STOP условий, особенно на длинных проводах.
Это как раз то, с чем я боролся, и после чего остановился на софтовом I2C. Неприятная особенность аппаратного I2C в STM32 как раз в этом и заключается, что он очень чувствителен к таким ситуациям, выбрасывает при этом флаг BERR и начинает с начала.

зеленый луч- зачастую слейв отвечает. После SCL слейв дает ответ через микросекунду ровно. Может мастеру быстро?

Разобрал по битам пачку от мастера:
дает адрес 1, далее на чтение.
слейв отвечает 0,7,8,90

а вот мой код:
outgoing[0] = 0x00;
outgoing[1] = 0x07;
outgoing[2] = 8;
outgoing[3] = calcCRC(outgoing, 4);

Все сходится. Вопрос глюков.

Мастер растягивать SCL умеет? STM по-умолчанию делает это, возможно мастеру это не подходит.

мастер может и умеет, но я туда не лезу.
Может где в STM указать, чтобы растянул слегка?
Я купил анализатор за 700=, будем завтра изучать вопрос углубленно ))

Теперь Вы и сами, думаю, разберетесь. А если покурите UM10204.pdf Philips - такужточно

Я для такой разработки, конечно, вместо черного ящика с линуксом сделал бы его эмуляцию для "нагрузочного" тестирования.
(если в процессоре есть 2 канала I2C - то можно эмулятор мастера сделать и в основном проекте, а соединение с линуксом временно разорвать).

Обратите внимание на содержимое вектора обработки прерываний.
Он должен быть полнофункциональный по обработке ситуаций и минимальный по объему кода.
Только работа с периферийным узлом I2C - команды и состояния обмена.

http://prntscr.com/cseh7b

вот кусок с анализатора. Не понятно- почему 3 в расшифровке? Адрес 7 бит, 0-й бит =1. Еще младше, это 1- на чтение слейва команда.

Содержимое ветки обработчика может и наполнено лишним. Но надо разобраться сначала тут.

Анализатор пишет адрес с учетом сдвига. Там еще на боковой панели вам текстовый лог протокола идет.

По поводу SCL STRETCH - по-умолчанию он включен в STM32. Не каждый мастер поддерживает такую возможность (практически все примеры soft-i2c такого не умеют). Выключите этот режим. NOSTRETCH = 1 в CR1 кажется. Но имейте в виду - в таком случае ваши прерывания по I2C в ведомом не должны иметь длительной обработки.
Хотя если судить по биту ACK кажется ваш мастер такое умеет.

может быть, что зависания происходят из-за того, что в закрытом корпусе? Рядом горячий проц на Линуксе (85 градусов). Корпус изделия на ощупь горячий.
Уже все варианты смотрю.

Только что-то не найти в даташите рабочей температуры МК

как минимум, смените адрес слейва на допустимый.. i2cdetect вам в помощь..