I2C Slave на STM32F103, нестабильная работа Опции

[Demeny]

Добрый день!
На контроллере STM32F103 реализовано I2C Slave устройство, которое принимает от "внешнего мира" команды, обрабатывает их, и по запросу чтения выдает ответ. Всё это работает на 90% выпущенных плат.
На 10% тех же плат (из той же произведенной серии) наблюдается следующая картина - I2C Slave аппаратно не подтверждает свой адрес, то есть не выдает ACK на первый (адресный) байт со стороны мастера. В качестве мастера для теста используется компьютер с простейшим адаптером на LPT порт, который имитирует программно работу мастера (выдает команды по I2C и получает ответ).
Картина, наблюдаемая логическим анализатором, доподлинно следующая - мастер правильно формирует старт-условие, адресный байт, не получает от I2C Slave ACK, снова формирует старт, адрес и т. д. много-много раз (несколько десятков раз), и вот в какой-то момент адрес подтверждается (ACK), контроллер получает команду, обрабатывает её и готов отдать ответ. Далее та же петрушка начинается с чтением - старт, адрес + бит чтения = NACK до посинения, потом, наконец, STM32 формирует ACK и выдает правильный ответ мастеру.
Примечательный момент - если встать на любую линию SCL или SDA щупом осциллографа, то работа слейва сразу стабилизируется, он начинает работать четко и формирует ACK сразу после первого же запроса.
Что это может быть? В чём ошибка? Почему 90% плат работают, а 10% ведут себя так?

[Demeny]

Вести с полей.
Не веря ни в какие "пички", решил поискать более материальную причину происходящего. Если контроллер не отвечает на свой адрес - возможно, он находит какую-то ошибку в происходящем на шине.
Сказано - сделано, подключил обработчик прерывания ошибок на шине I2C, разрешил прерывания ITERREN=1, и в обработчике прерывания дергаю внешним отладочным пином, чтобы видеть происходящие ошибки.
И сразу увидел, что в момент, когда при передаче адресного байта обе линии SCL и SDA одновременно падают в ноль (после переданного бита 1) - возникает ошибка Bus Error.
Согласно даташита, это как раз ситуация, когда посреди передачи байта возникает "старт" или "стоп" условие на шине.
Казалось бы, вот и ответ - программа бросает обе линии в ноль одновременно, но из-за различных емкостных характеристик линий SCL,SDA, неидеальности резисторов и ESD-диодов линия SDA с точки зрения контроллера падает в ноль первой, и возникает минимое "старт"-условие, которое и сбивает контроллер с толку.
Включив лог. анализатор на максимальную скорость 400 MS/s, вижу, что SCL 1=>0 всё же опережает SDA 1=>0 буквально на 7-8 нс, то есть "старт"-условия нету, а ошибка шины есть!
Замыкая проходные резисторы 100 Ом, могу подвигать фронтами, и вижу, что фронты двигаются друг относительно друга примерно на 10-15 нс, и ошибка пропадает при этом.
НО!
Я ещё понимаю, когда ошибка пропадает при отодвигании SDA 1=>0 позже по времени от SCL 1=>0.
Фантастика заключается в том, что ошибка пропадает и при отодвигании спада SCL в другую сторону, то есть фактически, когда "старт"-условие в реальности выполняется (SDA 1=>0 при SCL=1)!
Итого - ошибка шины возникает тогда и только тогда, когда разбежка между фронтами спада меньше 7-8 нс.
Если разбег фронтов (в любую сторону) больше - ошибки нет, что мы и видим при любом прикосновении к любой линии (пинцетом, щупом осциллографа и т. п.).
Что это - метастабильность триггера, защёлкивающего "старт" условие, из-за невыполнения setup-hold ??
Почему он его не защелкивает, когда "старт"-условие фактически выполняется (при подвижке спада на 10-15 нс в нужную сторону)??
И ещё. На такой же плате, у которой нет проблем с обменом (таких 90%) - также точно линии SCL и SDA падают в ноль с минимальным разбегом (<2.5 нс), но ошибки нет...

[scifi]

По спецификации I2C Fast Mode для Start Condition между фронтами SDA и SCL должно быть как минимум 600 нс. Вот не надо нарушать.