Доброго времени суток! Столкнулся со следующей проблемой: при инициализации модуля SPI1 в режим SPI slave Framed slave контроллер не входит в прерывание по импульсам на ноге SS1. В других режимах работы модуля прерывание отрабатывает. Обмен происходит с АЦП, которая и генерирует клоки и импульсы кадровой синхронизации. Возможно в этом режиме прерывание и не должно срабатывать, но в дата- и эррата-шитах этого не нашел. Разработка ведется в среде MikroC for dsPIC/PIC24 ver.6.0. АЦП ADS1601, тактируется от LTC6903.
Привожу кусок кода программы:


Ниже приведены осциллограммы на SS1, SCLK1 и SDI1 соответственно (все ноги сконфигурированы на вход)

Проверьте есть ли питание на плате! Некоторые устройства (не все!) работают лучше, если их запитать электричеством.
Следующим шагом должна быть уже проверка напряжения - оно тоже должно быть, хотя бы приблизительно, близко к значению, которое указано в даташите!
Проверьте, случайно, программатор не находится ли в режиме "Hold in reset"!
Проверьте вообще имеется ли контроллер на испытываемой плате! Если забыли впаять, обязательно сделайте это!
Проверьте запрограммирован ли вообще контроллер! Запрограммируйте еще раз, на всякий случай! (программатором!)
Проверьте совпадает ли язык программирования с языком компилятора! Это важно!
Проверьте, наконец, правильно ли у вас подключены выводы SPI. "Правильно" означает что бы совпадали номера выводов в даташите и на вашей схеме.
Некоторые контроллеры не умеют догадываться к какому именно выводу вы хотите подключить периферию, к которой хотите обратится по указанному интерфейсу.
Проверьте все!
Удачи!

ПП Перечитайте все последние темы в данном разделе! Начинается все с "Не работает высшая математика на моем контроллере, не извлекается квадратный корень из сферического коня в вакууме!".
А заканчивается на "Ой! Я забыл нажать кнопку "Release from Reset"."

Не понял смысл и цель вашего сообщения. Если Вам по делу нечего сказать - проходите мимо. На форум люди приходят для обмена опытом, и если Ваш опыт заканчивается на том, что вы написали - я вам сочувствую.

Сообщение отредактировал MasterM12 - Aug 6 2013, 07:45

Сударь! Нет здесь никакого дела! Каков вопрос - таков и ответ.
Вы утверждаете:

Не удосужитесь ли вы растолковать, как установили сей факт (что контроллер не входит в прерывание)?
Чудес, знаете, не бывает ...
Я бы вам порекомендовал проверить SPIROV. Если он выставлен, никакого приема данных не будет...
А потом можете прочитать документ 70206D, пункт 18.3.5. ...

В вашем куске кода не заметно что бы вы упразднили буфер SPI (прочитав его) до начала приема.

Проверяю вход в прерывание выводом символа '*' по UART2
Вот обработчик прерывания. В первом посте вывод не описан, так как посчитал это лишней деталью, наверное зря, каюсь




А за совет спасибо, действительно в инициализации SPIROV не обнуляю, может в этом собака зарыта, сейчас проверю.
P.S. сильно не бейте, в пиках пока что новичок

Сообщение отредактировал MasterM12 - Aug 6 2013, 09:35

обнуление при инициализации SPIROV не помогло. Подскажите, кто-то использовал SPI в этом пике в таком режиме? Может он и не должен так работать?

Я вам не написал обнулять SPIROV, а прочитать буфер обмена SPI1BUF при инициализации.
Прерывание происходит когда заполняется этот буфер. Тогда выставляется флаг SPRBF.
Если при включении питания из-за инициализации системы (имею ввиду всякие переходные процессы или просто сдвиг порога логического уровня),
на вход SS и/или SCLK поступит импульс, это уже приведет к ошибке.
Я вам порекомендовал проверить SPIROV, а SPI1BUF прочитать, что бы НЕ выставился SPIROV.
С SPI все работают. И да, он должен работать именно так. Позволю себе перевести для вас кусок цитаты из моего предыдущего поста:

Это означает, что если вы сбросили флаг SPIROV, но не устранили вызывающие его выставление условия (не прочитали/упразднили SPI1BUF) он выставится заново
при следжуюущей же отправки данных.
Повторюсь, не знаю тот ли у вас случай, но это обязательно делать и с SPI и с USART и с ADC, когда у него не один, а стек буферов (напр. у PIC24, где 16 АЦП буферов).
Возможно вы просто не учли какую-то мелочь и сейчас просто смотрите не туда, именно как в случаях, о которых я вам писал в первом своем посте (утрировал, да!).

Неправильно выразился, в инициализации сначала делаю фиктивное чтение, а потом обнуляю SPIROV (для надежности ), а прерывание так и молчит. Сделал сейчас просто SPI Slave - все срабатывает, берутся семплы от АЦП, но пока не разобрался с фазой клоков, т.к. АЦП CS поднимает по 15 клоку, и 16-й клок проходит уже при поднятом CS. По идее старший бит должен теряться(в сдвиговый регистр вдвигается 15 бит вместо 16). Наверное вследствие этого в результатах проскакивает и старший и младший биты одновременно при КЗ входа АЦП, хотя по осциллограмме шумит 4 младших бита, остальные - в нулях.
Вобщем пошел разбираться с полярностью и фазой клоков, и в АЦП есть прямые и инверсные клоки, может что получится.
На рисунке осциллограмма данных с АЦП при подаче на вход 100 мВ.

P.S. Все же интересно, кто-то из форумчан заводил SPI в framed slave mode c прерываниями? У меня уже ощущение что это в принципе невозможно (баг камня).

Инициализация SPI теперь выглядит так:


Сообщение отредактировал MasterM12 - Aug 7 2013, 10:21

Очень даже может быть. Но в таком случае, (ЕМНИП) в регистре настроек SPI была возможность выбирать фронт сигнала (полярность, скорее всего) SS.



В 99.9% из случаев - баг задклавиатурного устройства.