Имеем: LPC2148 + IAR + Wigller. Девайс непрерывно обменивается данными с РС через UART. Останавливаем программу кнопкой [Break] или по брекпоинту – без разницы. После остановки данные еще какое-то время продолжают поступать в UART. В регистре UOIIR видно, что имеется отложенное CTI-прерывание, что вполне логично. Если затем продолжить выполнение программы, дав тем самым процу возможность обработать прерывание – все нормально. А во если ее сбросить, то прерывание UART «залипает». После этого идентификатор в UOIIR уже не сбрасывается ни при инициализации UART, ни при обработке прерывания (считывания U0RBR), в результате чего программа постоянно входит в обработчик. Помогает только аппаратный сброс с последующим перезапуском отладчика. Так должно быть или это результат кривого программирования? (во всем остальном UART работает нормально) Почему команда сброса ФИФО во время инициализации не сбрасывает прерывание?

Перезапустить программу в отладчике? Такого нет. Сбрасывайте все регистры UART и VIC при инициализации.

Как нет? А кнопка "Reset"? В смысле, кнопка не на плате, а на панели инструментов отладчика.
А что значит "сбрасывать"? Записывать в них нули? К сожалению, флаг прерывания так не сбрасывается. В VIC, на сколько я понял, предусмотрена очистка только софтовых прерываний и сброс регистра разрешения прерываний. В UART есть только команда сброса ФИФО, я ее даю - не помогает. Если я не прав - просветите.

В том смысле, что у меня все нормально.



Для LPC2132 (вроде, одинаково с 2148).

Здравствуйте.

Во-первых, при остановке по брейкпоинту или ещё как программисты любят наблюдать вкладки периферии и Watch. Я тоже. Не не забывайте, что содержимое этой вкладки, которую вам показывает дебаггер после бряка, он (дебаггер) достаёт через JTAG. Это значит, что он заставляет ядро процессора лезть и перечитывать всю периферию, которая отображается в отладчике, включая панель Watch. Как вы думаете, что будет, если процессор покажет вам состояние, скажем, регистра чтения FIFO, или VICVectAddr? В первом случае ваша программа после продолжения выполнения может эти данные уже не прочитать. Во втором случае ситуация может оказаться ещё интереснее: внутренняя логика VIC управляется чтением и записью будет переключена чтением этого регистра, что должно быть сделано в прерывании, и чтобы сбросить логику, нужно опять же выполнить запись в этот регистр, что должно быть сделано в последних инструкциях обработчика.

Отсюда вывод: при остановке в прерывании у вас НЕ ДОЛЖНЫ ОТОБРАЖАТЬСЯ в отладчике как либо любые регистры, чтение которых меняет логику работы периферии.

Сообщение отредактировал IgorMarx - Apr 17 2009, 09:05

Это не верно, по крайней мере в общем случае. Если это так для ЛПЦ, то это очень странно. Механизм JTAG не использует никакие функции ядра. Это соверщенно независимая система. О том что какой-то регистр бы прочитан через JTAG, ядро узнать никак не может.

Другое дело что если вы пишете в регистр который управляется записью или чтением, то опять таки это не тоже самое, как если бы ядро его записало. В этом случае возможны как раз серьезные глюки, в зависимости от того, как устроен процессор. Что вы и наблюдаете. Кстати, а зачем было подвергать прогрмамму такому издевательству -- сбрасывать прерывание?

В данном случае вы не правы. В правоте IgorMarx легко убедиться, запустив отладчик.

Поддерживаю. Проблема была обратная, смотришь периферию SPI отладчиком - байт уходит. Запускаешь прогу без отладки - не пашет. Отсель мораль, надо очищать регистр SPI состояния чтением перед каждой передачей.

Что имеется ввиду? JTAG заточен под ядро, работает только с ядром и не имеет никакого понятия о периферии. Или Вы думаете, что при проектировании каждого нового чипа с новой периферией весь механизм JTAG переделывают под конкретный чип?

Микроконтроллеры - это макросборки из кубиков, один из которых - ядро ARM - отдельное устройство, другое (это отдельная разработка, на которую есть отдельная документация) - VIC, могу как пример указать конкретный datasheet, и так далее. Кстати, это одна из причин, почему возникают spurious interrupts, от которых никак нельзя избавиться в микроконтроллерах LPC2000