Полная версия этой страницы: Проблемы с UART под отладкой
Имеем: LPC2148 + IAR + Wigller. Девайс непрерывно обменивается данными с РС через UART. Останавливаем программу кнопкой [Break] или по брекпоинту – без разницы. После остановки данные еще какое-то время продолжают поступать в UART. В регистре UOIIR видно, что имеется отложенное CTI-прерывание, что вполне логично. Если затем продолжить выполнение программы, дав тем самым процу возможность обработать прерывание – все нормально. А во если ее сбросить, то прерывание UART «залипает». После этого идентификатор в UOIIR уже не сбрасывается ни при инициализации UART, ни при обработке прерывания (считывания U0RBR), в результате чего программа постоянно входит в обработчик. Помогает только аппаратный сброс с последующим перезапуском отладчика. Так должно быть или это результат кривого программирования? (во всем остальном UART работает нормально) Почему команда сброса ФИФО во время инициализации не сбрасывает прерывание?
Цитата(b-volkov @ Apr 9 2009, 09:40) 
А во если ее сбросить, то прерывание UART «залипает».
Перезапустить программу в отладчике? Такого нет. Сбрасывайте все регистры UART и VIC при инициализации.
Как нет? А кнопка "Reset"? В смысле, кнопка не на плате, а на панели инструментов отладчика.
А что значит "сбрасывать"? Записывать в них нули? К сожалению, флаг прерывания так не сбрасывается. В VIC, на сколько я понял, предусмотрена очистка только софтовых прерываний и сброс регистра разрешения прерываний. В UART есть только команда сброса ФИФО, я ее даю - не помогает. Если я не прав - просветите.
А что значит "сбрасывать"? Записывать в них нули? К сожалению, флаг прерывания так не сбрасывается. В VIC, на сколько я понял, предусмотрена очистка только софтовых прерываний и сброс регистра разрешения прерываний. В UART есть только команда сброса ФИФО, я ее даю - не помогает. Если я не прав - просветите.
Цитата(b-volkov @ Apr 10 2009, 13:44)
В смысле, кнопка не на плате, а на панели инструментов отладчика.
В том смысле, что у меня все нормально.
Цитата(b-volkov @ Apr 10 2009, 13:44)
А что значит "сбрасывать"
Для LPC2132 (вроде, одинаково с 2148).
Код
VICSoftIntClear = ~0u;
VICIntEnClear = ~0u;
VICIntEnable = 0u;
VICIntSelect = 0u;
VICVectAddr = 0u;
VICIntEnClear = ~0u;
VICIntEnable = 0u;
VICIntSelect = 0u;
VICVectAddr = 0u;
Здравствуйте.
Во-первых, при остановке по брейкпоинту или ещё как программисты любят наблюдать вкладки периферии и Watch. Я тоже. Не не забывайте, что содержимое этой вкладки, которую вам показывает дебаггер после бряка, он (дебаггер) достаёт через JTAG. Это значит, что он заставляет ядро процессора лезть и перечитывать всю периферию, которая отображается в отладчике, включая панель Watch. Как вы думаете, что будет, если процессор покажет вам состояние, скажем, регистра чтения FIFO, или VICVectAddr? В первом случае ваша программа после продолжения выполнения может эти данные уже не прочитать. Во втором случае ситуация может оказаться ещё интереснее: внутренняя логика VIC управляется чтением и записью будет переключена чтением этого регистра, что должно быть сделано в прерывании, и чтобы сбросить логику, нужно опять же выполнить запись в этот регистр, что должно быть сделано в последних инструкциях обработчика.
Отсюда вывод: при остановке в прерывании у вас НЕ ДОЛЖНЫ ОТОБРАЖАТЬСЯ в отладчике как либо любые регистры, чтение которых меняет логику работы периферии.
Во-первых, при остановке по брейкпоинту или ещё как программисты любят наблюдать вкладки периферии и Watch. Я тоже. Не не забывайте, что содержимое этой вкладки, которую вам показывает дебаггер после бряка, он (дебаггер) достаёт через JTAG. Это значит, что он заставляет ядро процессора лезть и перечитывать всю периферию, которая отображается в отладчике, включая панель Watch. Как вы думаете, что будет, если процессор покажет вам состояние, скажем, регистра чтения FIFO, или VICVectAddr? В первом случае ваша программа после продолжения выполнения может эти данные уже не прочитать. Во втором случае ситуация может оказаться ещё интереснее: внутренняя логика VIC управляется чтением и записью будет переключена чтением этого регистра, что должно быть сделано в прерывании, и чтобы сбросить логику, нужно опять же выполнить запись в этот регистр, что должно быть сделано в последних инструкциях обработчика.
Отсюда вывод: при остановке в прерывании у вас НЕ ДОЛЖНЫ ОТОБРАЖАТЬСЯ в отладчике как либо любые регистры, чтение которых меняет логику работы периферии.
Цитата(IgorMarx @ Apr 17 2009, 04:05)
Здравствуйте.
Во-первых, при остановке по брейкпоинту или ещё как программисты любят наблюдать вкладки периферии и Watch. Я тоже. Не не забывайте, что содержимое этой вкладки, которую вам показывает дебаггер после бряка, он (дебаггер) достаёт через JTAG. Это значит, что он заставляет ядро процессора лезть и перечитывать всю периферию, которая отображается в отладчике, включая панель Watch. Как вы думаете, что будет, если процессор покажет вам состояние, скажем, регистра чтения FIFO, или VICVectAddr? В первом случае ваша программа после продолжения выполнения может эти данные уже не прочитать. Во втором случае ситуация может оказаться ещё интереснее: внутренняя логика VIC управляется чтением и записью будет переключена чтением этого регистра, что должно быть сделано в прерывании, и чтобы сбросить логику, нужно опять же выполнить запись в этот регистр, что должно быть сделано в последних инструкциях обработчика.
Отсюда вывод: при остановке в прерывании у вас НЕ ДОЛЖНЫ ОТОБРАЖАТЬСЯ в отладчике как либо любые регистры, чтение которых меняет логику работы периферии.
Это не верно, по крайней мере в общем случае. Если это так для ЛПЦ, то это очень странно. Механизм JTAG не использует никакие функции ядра. Это соверщенно независимая система. О том что какой-то регистр бы прочитан через JTAG, ядро узнать никак не может. Во-первых, при остановке по брейкпоинту или ещё как программисты любят наблюдать вкладки периферии и Watch. Я тоже. Не не забывайте, что содержимое этой вкладки, которую вам показывает дебаггер после бряка, он (дебаггер) достаёт через JTAG. Это значит, что он заставляет ядро процессора лезть и перечитывать всю периферию, которая отображается в отладчике, включая панель Watch. Как вы думаете, что будет, если процессор покажет вам состояние, скажем, регистра чтения FIFO, или VICVectAddr? В первом случае ваша программа после продолжения выполнения может эти данные уже не прочитать. Во втором случае ситуация может оказаться ещё интереснее: внутренняя логика VIC управляется чтением и записью будет переключена чтением этого регистра, что должно быть сделано в прерывании, и чтобы сбросить логику, нужно опять же выполнить запись в этот регистр, что должно быть сделано в последних инструкциях обработчика.
Отсюда вывод: при остановке в прерывании у вас НЕ ДОЛЖНЫ ОТОБРАЖАТЬСЯ в отладчике как либо любые регистры, чтение которых меняет логику работы периферии.
Другое дело что если вы пишете в регистр который управляется записью или чтением, то опять таки это не тоже самое, как если бы ядро его записало. В этом случае возможны как раз серьезные глюки, в зависимости от того, как устроен процессор. Что вы и наблюдаете. Кстати, а зачем было подвергать прогрмамму такому издевательству -- сбрасывать прерывание?
Цитата(ar__systems @ Apr 17 2009, 13:54)
Механизм JTAG не использует никакие функции ядра. Это соверщенно независимая система. О том что какой-то регистр бы прочитан через JTAG, ядро узнать никак не может.
В данном случае вы не правы. В правоте IgorMarx легко убедиться, запустив отладчик.
Цитата(Сергей Борщ @ Apr 17 2009, 14:07)
В данном случае вы не правы. В правоте IgorMarx легко убедиться, запустив отладчик.
Поддерживаю. Проблема была обратная, смотришь периферию SPI отладчиком - байт уходит. Запускаешь прогу без отладки - не пашет. Отсель мораль, надо очищать регистр SPI состояния чтением перед каждой передачей.
Цитата(ar__systems @ Apr 17 2009, 14:54)
Это совершенно независимая система.
Что имеется ввиду? JTAG заточен под ядро, работает только с ядром и не имеет никакого понятия о периферии. Или Вы думаете, что при проектировании каждого нового чипа с новой периферией весь механизм JTAG переделывают под конкретный чип?
Микроконтроллеры - это макросборки из кубиков, один из которых - ядро ARM - отдельное устройство, другое (это отдельная разработка, на которую есть отдельная документация) - VIC, могу как пример указать конкретный datasheet, и так далее. Кстати, это одна из причин, почему возникают spurious interrupts, от которых никак нельзя избавиться в микроконтроллерах LPC2000
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.