Добрый день.
Делаю сниффер SPI-шины на STM32F427. Частота процессора 168 МГц, частота исследуемого SPI - 4 МГц.
Использую внешнее прерывание по фронту SCK. Для тестирования посылаю известную посылку из 4-х байт (1 запрос и 3 ответ).
Вариант 1.
Сначала сделал полностью на HAL, как в примерах - в обработчике прерывания вызывается HAL_GPIO_EXTI_IRQHandler(SPI_SCK_PIN), который сбрасывает бит в регистре PR и вызывает пользовательскую функцию HAL_GPIO_EXTI_Callback(). В функции сохраняю состояние порта в буфер и считаю количество прерываний.
В этом случае "ловится" только 24 прерывания вместо 32-х.

Вариант 2.
Перенес операции сброса бита и чтения порта непосредственно в обработчик прерывания. В этом случае "ловится" 32 прерывания, однако значения в буфере не соответствуют реальным: передается байт x7 x6 x5 x4 x3 x2 x1 x0, а в буфере оказывается x6 x5 x4 x3 x2 x1 x0 ?? (как будто сдвинуто на 1 бит)

Без внешних прерываний (в бесконечном цикле ловлю фронт и читаю порт в буфер) все работает как надо.

Почему такое может происходить?

А чем аппаратный SPI-slave не угодил?
Может, у вас по фронту данные SPI защелкивает и тут же выставляет на MOSI новый бит.
MOSI нужно считывать именно в момент перехода SCK из 0 в 1 (хотя есть разные варианты).
Конечно же считывание MOSI в прерывании будет гораздо позже.
Может, стоит воспользоваться копеечным логическим анализатором, а не разрабатывать свой сниффер?

Мне нужен именно сниффер - просмотреть обе линии MISO и MOSI. Хотя, можно взять два слейва... - попробую.

Обмен идет корректно, на время отладки с одной стороны аппаратный SPI, с другой - NOR-Flash.

Насколько "гораздо"? Пусть даже 30 тактов - при частоте процессора 168 МГц эта задержка должна быть незаметна для частоты прерываний 4 МГц.

В данный конкретный момент у меня его нет, а задача неожиданно возникла.

Да и вообще, уже хочется просто понять, что происходит и чего я не понимаю.

Раз сниффер, значит смотреть будет человек.
Может, проще с частотой 8 МГц по таймеру через DMA складывать значения CS + MOSI + MISO + SCK в память,
а затем неспешно анализировать?


Да, хоть один такт. Представьте себе цепочку из D-триггеров.
По фронту на выход они записывают, что было на входе, но вход через t меняется,
где t - время распространения сигнала от входа к выходу (т.к. скорость работы логики конечна).


Логический анализатор - это инструмент для решения подобных задач.
Он у вас должен был быть задолго до того, как вы взялись за эту задачу))
Типа такого.

По возможности лучше использовать аппаратные ресурсы МК.
Соотношение 168:4 дает всего лишь 42 такта на отсчет. Не понятно, что вы хотите успеть сделать полезного.
12 тактов на вход, 12 на выход, несколько на сброс флага прерывания - остается ничего. При этом других прерываний возникать не должно.

Самый главный вопрос - ЗАЧЕМ?
Есть же совсем дешёвые готовые на CY7C68013 и с гораздо лучшими характеристиками.
И непонятно, что за исследуемый SPI? Сколько бит: single? dual? quad? Сколько рабочих перепадов SCLK: обычный? DDR?
А если уж так хочется слепить свой лисапед, то стоит хотя бы выбирать подходящий МК. Взять хотя-бы любой МК с quad-SPI и FIFO, тогда, если нужно захватить single-SPI, то все его сигналы завести на линии D0-D3 этого quad-SPI и при помощи DMA вытянуть их. Даже и с большей частотой.
А ещё лучше - взять LPC43xx - на его SGPIO не проблема захватить даже очень много параллельных битовых потоков без потерь и с большой частотой.
Ну или даже взять тот же CY7C68013 если нужно просто захватить сигнал в комп.

Делать что-то с захватом ногодрыгом по прерыванию - пустая затея. SPI с SCLK=4МГц невозможно программно захватить на МК частотой 168МГц. Нужен МК с частотой в несколько раз выше.


Чтобы более-менее посмотреть сигнал с частотой 4МГц, нужно сэмплирование в разы больше. Хотя-бы в 4 раза.
Проц 168МГц на прерывании 4МГц уже захлебнётся - слишком много.

Меньше 42 тактов. Через 21 такт выход начнёт устанавливать новое состояние. Итого 21 такт + некоторое время пока фронт ползёт.
Можно попробовать либо прерывание настроить не по фронту защёлкивания а по фронту установки бита. Либо как автор писал выше, что заработало в цикле.

Всем спасибо, свои заблуждения по поводу внешнего прерывания понял и осознал.

Отдельное спасибо jcxz за идеи и информацию о SGPIO.