Процессор LPC2148
J-TAG : Виглер и J-link
При переходе с CrossWoks 1.5 -> 1.6 перестали работать прерывания или работают неправильно.
Задача проекта : отловить, где у меня ошибка.
Проект в 1.5 http://sevsin.ru/data/MyArm_CW_1-5.rar
Проект в 1.6 http://sevsin.ru/data/MyArm_CW_1-6.rar
При прошивке проекта в 1.5 - все работает как ожидается(моргают светодиоды). При прошивке 1.6 прерывания перестают работать вообще.
Подскажите, в чем проблема?
Полная версия этой страницы: Не работают прерывания LPC2148 после перехода CW1.5 -> CW1.6
Цитата(Arischenko Ivan @ Oct 30 2006, 03:55) 
Процессор LPC2148
J-TAG : Виглер и J-link
При переходе с CrossWoks 1.5 -> 1.6 перестали работать прерывания или работают неправильно.
Подскажите, в чем проблема?
J-TAG : Виглер и J-link
При переходе с CrossWoks 1.5 -> 1.6 перестали работать прерывания или работают неправильно.
Подскажите, в чем проблема?
А в debug работает?
Исходники не глядел, но возможно решение проблемы тут:
http://electronix.ru/forum/index.php?showtopic=21799
http://electronix.ru/forum/index.php?showtopic=21799 - Я внимательно читал эту ветке. Пробовал писать на асемблере свою функцию обработки прерываний, включал функцию которая есть в кросворксе(написанная на асме обработчик прерываний) , качал патченный GCC, не помогло.
После прошивки (если сделать - build and run или build and debug) проц заводится, прерывания происходят(моргают светодиоды). Но стоит процессор сбросить, дернуть питание или сделать ресет с помощью JTAG - прерывания перестают происходить(светодиоды гаснут). При том что те же исходники в 1.5 версии работают нормально.
После прошивки (если сделать - build and run или build and debug) проц заводится, прерывания происходят(моргают светодиоды). Но стоит процессор сбросить, дернуть питание или сделать ресет с помощью JTAG - прерывания перестают происходить(светодиоды гаснут). При том что те же исходники в 1.5 версии работают нормально.
Цитата(Arischenko Ivan @ Oct 30 2006, 10:25)
После прошивки (если сделать - build and run или build and debug) проц заводится, прерывания происходят(моргают светодиоды). Но стоит процессор сбросить, дернуть питание или сделать ресет с помощью JTAG - прерывания перестают происходить(светодиоды гаснут). При том что те же исходники в 1.5 версии работают нормально.
Покажите листинг ассемблерного кода обработчика IRQ/FIQ?, посмотрим и подумаесм что у вас за беда. А лучше пришлите "возможность" запустить CW 1.6 build 3, а то с 1.6 build 2 у меня все и так работает. Хочу build 3 - там отладчик поправлен на предмет корявости и гнекоторых глюков
Цитата(Arischenko Ivan @ Oct 30 2006, 12:25)
После прошивки (если сделать - build and run или build and debug) проц заводится, прерывания происходят(моргают светодиоды). Но стоит процессор сбросить, дернуть питание или сделать ресет с помощью JTAG - прерывания перестают происходить(светодиоды гаснут). При том что те же исходники в 1.5 версии работают нормально.
А точно прерываний только нет, или вообще ничего не пашел? Как ведёт себя "Reset and debug"?
startup от 1.6? Тогда может Вы на грабельки связанные с STARTUP_FROM_RESET наступили?
PS Кстати, немного не в тему но, в 1.5 и 1.6 reset script очень разные.
klen:
В осле пока нет build 3, есть пока только 2. Будем ждать.
Alex03
"Тогда может Вы на грабельки связанные с STARTUP_FROM_RESET наступили?" Пожалуста поподробней где про это написано? Я прописал в опциях препроцессора "STARTUP_FROM_RESET" , и проект заработал!
В осле пока нет build 3, есть пока только 2. Будем ждать.
Alex03
"Тогда может Вы на грабельки связанные с STARTUP_FROM_RESET наступили?" Пожалуста поподробней где про это написано? Я прописал в опциях препроцессора "STARTUP_FROM_RESET" , и проект заработал!
Нашел: (лежит в startup коде)
* STARTUP_FROM_RESET
*
* If defined, the program will startup from power-on/reset. If not defined
* the program will just loop endlessly from power-on/reset.
*
* This definition is not defined by default on this target because the
* debugger is unable to reset this target and maintain control of it over the
* JTAG interface. The advantage of doing this is that it allows the debugger
* to reset the CPU and run programs from a known reset CPU state on each run.
* It also acts as a safety net if you accidently download a program in FLASH
* that crashes and prevents the debugger from taking control over JTAG
* rendering the target unusable over JTAG. The obvious disadvantage of doing
* this is that your application will not startup without the debugger.
*
* We advise that on this target you keep STARTUP_FROM_RESET undefined whilst
* you are developing and only define STARTUP_FROM_RESET when development is
* complete.
* STARTUP_FROM_RESET
*
* If defined, the program will startup from power-on/reset. If not defined
* the program will just loop endlessly from power-on/reset.
*
* This definition is not defined by default on this target because the
* debugger is unable to reset this target and maintain control of it over the
* JTAG interface. The advantage of doing this is that it allows the debugger
* to reset the CPU and run programs from a known reset CPU state on each run.
* It also acts as a safety net if you accidently download a program in FLASH
* that crashes and prevents the debugger from taking control over JTAG
* rendering the target unusable over JTAG. The obvious disadvantage of doing
* this is that your application will not startup without the debugger.
*
* We advise that on this target you keep STARTUP_FROM_RESET undefined whilst
* you are developing and only define STARTUP_FROM_RESET when development is
* complete.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.