GetSmart 0 12 ноября, 2009 Опубликовано 12 ноября, 2009 (изменено) · Жалоба Проц LPC2368. Отладчик MT-Link v6.0. Прога под FreeRTOS. Компилятор CW 1.7 build 9 В майне всё как полагается - регистрируются треды и в конце вызывается vTaskStartScheduler(). Собственно во все треды управление залетает, до тех пор пока не встретится vTaskDelay(). Далее управление больше не возвращается. Баг возникает очень редко, но долговременно. Часто до выключения питания. Перепрограммирование проца баг не снимает. Во всех тредах IRQ и FIQ разрешены (CPSR = x000001f). Расследование показывает, что не вызываются IRQ вообще, хотя FIQи прекрасно работают. Настройки таймера FreeRTOS правильные. Все регистры в норме, таймер тикает до установленного MATCH, потом опять с нуля. В VIC корректный адрес обработчика TIMER0 и приоритет = 1 (проверено). Все остальные регистры VIC тоже в порядке, причём в VICIRQStatus и VICRawIntr установлен запрос на прерывание от TIMER0, но оно туда не идёт. Брейкпоинт на 0x18 и на первой команде прерывания (IRQ) TIMER0 не срабатывает. IRQ реально не вызывается. Не могу выяснить проблему. Кстати, в начале майна стоит запрет прерываний в CPSR и команда VICIntEnClr = ~0; ЗЫ. Одну странность заметил. В регистре VICRawIntr наблюдается включённый бит 3 (ARM Core Embedded ICE, DbgCommTX), причём этого же бита нет ни в VICIRQStatus ни в VICFIQStatus. Состояние первых 16-ти регистров VIC на картинке. Забыл указать - прога без конца крутится в цикле for (;;) из функции static portTASK_FUNCTION( prvIdleTask, pvParameters ) периодически залетая в FIQ. В ней аналогично CPSR = x000001f. В течении ближайшего часа могу продемонстрировать баг "вживую" на "телевизоре" TeamViewer. Реальным пацанам :) Изменено 12 ноября, 2009 пользователем GetSmart Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
KRS 1 12 ноября, 2009 Опубликовано 12 ноября, 2009 · Жалоба Ну то что прерывание по DCC TX разрешено - так может это отладчик его использует, для debug_printf или еще для чего. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
GetSmart 0 12 ноября, 2009 Опубликовано 12 ноября, 2009 (изменено) · Жалоба ----------------- Есть предположение, что это не баг, а фича под названием RealMonitor, прошитая в bootloader. Цитата из User Manual 23xx.pdf While user application is running, RMTarget typically uses IRQs generated by the DCC. This means that if user application also wants to use IRQs, it must pass any DCC-generated interrupts to RealMonitor. Кто-нибудь с этим сталкивался? Как это точно переводится? Когда пользовательская прога работает, RMTarget-у тоже требуются запросы IRQ. Это значит что если пользовательская прога юзает IRQ, то она же должна перенаправлять прерывания от DCC в RealMonitor ? Я правильно перевёл? Ну то что прерывание по DCC TX разрешено - так может это отладчик его использует, для debug_printf или еще для чего. Проверил. debug_printf не используется в моём проекте. Изменено 12 ноября, 2009 пользователем GetSmart Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
KRS 1 12 ноября, 2009 Опубликовано 12 ноября, 2009 · Жалоба ----------------- Есть предположение, что это не баг, а фича под названием RealMonitor, прошитая в bootloader. Так его надо включить вызовом соответствующим! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
GetSmart 0 12 ноября, 2009 Опубликовано 12 ноября, 2009 (изменено) · Жалоба Может кто-нибудь знает, как сбрасываются запросы от Embedded ICE, DbgCommRx и Embedded ICE, DbgCommTX или сиё тайна NXP? Поставил в начале main() вот это VICVectAddr = 0; VICVectAddr = 0; VICVectAddr = 0; VICVectAddr = 0; VICVectAddr = 0; VICVectAddr = 0; VICVectAddr = 0; И всё заработало :) Всвязи с этим возник вопрос - как при рестарте проги (программно или по JTAG) правильно сбрасывать VIC ? Чтобы ещё и счётчик приоритетов обнулялся. И для чего существует регистр VICSWPriorityMask, на который в мануале нет внятного объяснения? И что за регистр, находящийся по адресу 0xFFFFF028 ? В мануале его нет, но на моей картинке в первом посте он есть! Ещё прикол в том, что иногда подобный баг возникал прямо при первой отладке. Возможно когда отладчик прерывал работающую прогу прямо из прерывания FreeRTOS - Timer0 и все прерывания блокировались. Мля. Изменено 12 ноября, 2009 пользователем GetSmart Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
KRS 1 12 ноября, 2009 Опубликовано 12 ноября, 2009 · Жалоба Всвязи с этим возник вопрос - как при рестарте проги (программно или по JTAG) правильно сбрасывать VIC ? Чтобы ещё и счётчик приоритетов обнулялся. Хороший вопрос!!! Вообще надо что бы отладчик делал ресет контроллеру, но я тоже заметил что не всегда происходит сброс всей переферии. Похоже делается ресет, а потом проц останавливаетя, но уже успевает выполнить часть программы. Можно в начале задержку поставить. И для чего существует регистр VICSWPriorityMask, на который в мануале нет внятного объяснения? Вам нужен datasheet от ARM ARM DDI 0273A ARM PrimeCell ™ Vectored Interrupt Controller (PL192) Technical Reference Manual Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VslavX 0 12 ноября, 2009 Опубликовано 12 ноября, 2009 · Жалоба Поставил в начале main() вот это VICVectAddr = 0; VICVectAddr = 0; VICVectAddr = 0; VICVectAddr = 0; VICVectAddr = 0; VICVectAddr = 0; VICVectAddr = 0; И всё заработало :) Посмотрел в свои исходники - у меня есть такая строчки for (i=0; i<16; i++) pVic->sVIC_VECTOR = 0; // очищаем аппаратный стек вложений Начал вспоминать и вспомнил - VIC в LPC поддерживает схему приоритетов прерываний - когда происходит прерывание, VIC запоминает в свое внутреннем аппаратном стеке текущий уровень приоритета и все прерывания с более низким приоритетом - блокируются, с более высоким - разрешаются и "нестяться". Вот этот внутренний стек и чистится многократной записью VIC_VECTOR. 16 - глубина стека, равная числу уровней приоритета. Может кто-нибудь знает, как сбрасываются запросы от Embedded ICE, DbgCommRx и Embedded ICE, DbgCommTX или сиё тайна NXP? Да нет, в LPC23 все стандартно, задокументировано в документации ARM на ядро ARM7TDMI. Доступ к регистрам DCC, например, такой: #define hal_status_dcc() __MRC(14, 0, 0, 0, 0) #define hal_write_dcc(a) __MCR(14, 0, a, 1, 0, 0) #define hal_read_dcc() __MRC(14, 0, 1, 0, 0) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
GetSmart 0 17 ноября, 2009 Опубликовано 17 ноября, 2009 (изменено) · Жалоба Зачем создавать новую тему, если можно здесь продолжить. Тем более, что название темы аналогичное. Столкнулся с непонятным мне поведением LPC2368. Прога (та же), работает под FreeRTOS. Используются вложенные FIQ, работающие в Undef режиме и вложенные IRQ, работающие тоже на Undef режиме. Всё прекрасно работает под осью и без неё. Далее, меняю режим работы вложенных FIQ на IRQ и под FreeRTOS падаю в Data Abort. То же самое запускаю без FreeRTOS (вместо треда пустой цикл, хотя прога на уровне прерываний проигрывает музыку) и всё прекрасно работает. Обёртку вложенных прерываний FIQ выкладывал в соседней теме. здесь: http://electronix.ru/forum/index.php?showt...st&p=678194 Там нужно только при загрузке режима в CPSR поменять режим с 0x9b на 0x92 (или 0xd2 - без разницы). Под FreeRTOS падает в месте, помеченном стрелкой: void vPreemptiveTick( void ) { /* Save the context of the interrupted task. */ portSAVE_CONTEXT(); <<------- /* Increment the RTOS tick count, then look for the highest priority task that is ready to run. */ vTaskIncrementTick(); vTaskSwitchContext(); /* Ready for the next interrupt. */ T0IR = 2; VICVectAddr = portCLEAR_VIC_INTERRUPT; /* Restore the context of the new task. */ portRESTORE_CONTEXT(); } vPreemptiveTick portSAVE_CONTEXT(); E92D0001 stmfd sp!, {r0} E94D2000 stmfd sp, {sp}^ E1110001 mov r0,r0 (менял на tst r1, r1 - не помогло) E24DD004 sub sp, sp, #0x00000004 E8BD0001 ldmfd sp!, {r0} E9204000 stmdb r0!, {lr} <<<----- Data Abort (R0 = 0x0006be80, CPSR = 0x0006be80) Причём именно после "хаковой" инструкции stm xx, {xx}^. По логике, эта инструкция должна загрузить регистр SP треда сначала в стек, а потом он загружается в текущий R0, но там просто чудеса творятся. Вообще, этот обработчик прерывания переключения тредов от таймера (vPreemptiveTick) какое-то время нормально работает. В каких-то особых случаях в регистре R0 оказывается значение в районе внутреннего флэш, конкретно из моей проги. Прикол ещё в том, что в регистре SPSR (текущего режима IRQ) оказывается то же самое значение (чего не может быть в принципе, т.к. в SPSR задействованы только первые 8 бит и последние 4). Проверил, что указатели стеков всех режимов в норме. И в режиме System/User стек = 40003360, хотя в R0 загрузилось другое число. Проверял, точно выяснил, что управление залетает в vPreemptiveTick когда все мои вложенные прерывания уже закончились, то есть нет перекрёстных входов, собсно как и должно быть. Если есть настоящие спецы, которым интересен этот баг - могу сильно кастрировать прогу и выложить для тестирования. Либо прошу подсказать советом как мне найти почему этот баг происходит. Только прошу не оффтопить. --------------------- Уже когда написал пост понял!!!!!! После команды stmfd sp, {sp}^ стоит NOP (mov r0, r0), который и затирает R0 чёрт знает каким значением, но видимо из PC. Вообще-то изменив команду на TST R1,R1 это не помогло. Зато выяснил, что значение загруженное в R0 равняется текущему LR, то есть R0, LR и SPSR совпадают. Изменено 17 ноября, 2009 пользователем GetSmart Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 17 ноября, 2009 Опубликовано 17 ноября, 2009 · Жалоба Либо прошу подсказать советом как мне найти почему этот баг происходит. Ставлю литру на Ваш выбор, что в процессе выполнения команды mov r0,r0 происходит прерывание. В результате стек запарывается (видимо, сохранением LR в стек), ибо тут кодописатели - сами себе злобные буратины, код совершенно не предназначен для работы со вложенными прерываниями. Надо делать так: stmfd sp!, {r0} sub sp,sp,#4 stmia sp,{sp}^ mov r0, r0 ldr r0, [sp], #4 Короче, баг не в ядре, а в голове у кого-то. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
GetSmart 0 17 ноября, 2009 Опубликовано 17 ноября, 2009 (изменено) · Жалоба Короче, баг не в ядре, а в голове у кого-то. Внатуре :) Эти кретины сохраняют регистр не в стеке, а в свободной его области. И я потом на ней работаю и ненароком затираю YES!!!!!! Теперь работает :):):) Rst7, респект и уважуха Кто сообщит автору FreeRTOS, что у него косяк? :) Изменено 17 ноября, 2009 пользователем GetSmart Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 17 ноября, 2009 Опубликовано 17 ноября, 2009 · Жалоба Rst7, респект и уважуха Да ладно. Я вот настоящий баг знаю. Правда, в ядрах 926EJ-S, которые в чипсетах мобильников от Siemens (Infineon) и SE (там не знаю кто). Там MOV PC,Rx не меняет режим ядра ARM->Thumb, хотя по даташиту - должен. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
GetSmart 0 17 ноября, 2009 Опубликовано 17 ноября, 2009 (изменено) · Жалоба Вот исправленный макрос #define portSAVE_CONTEXT() \ { \ extern volatile void * volatile pxCurrentTCB; \ extern volatile unsigned portLONG ulCriticalNesting; \ \ /* Push R0 as we are going to use the register. */ \ asm volatile ( \ "STMDB SP!, {R0} \n\t" \ \ /* Set R0 to point to the task stack pointer. */ \ "SUB SP,SP,#4 \n\t" \ "STMIA SP,{SP}^ \n\t" \ "NOP \n\t" \ "LDMIA SP!,{R0} \n\t" \ \ /* Push the return address onto the stack. */ \ "STMDB R0!, {LR} \n\t" \ \ /* Now we have saved LR we can use it instead of R0. */ \ "MOV LR, R0 \n\t" \ \ /* Pop R0 so we can save it onto the system mode stack. */ \ "LDMIA SP!, {R0} \n\t" \ \ /* Push all the system mode registers onto the task stack. */ \ "STMDB LR,{R0-LR}^ \n\t" \ "NOP \n\t" \ "SUB LR, LR, #60 \n\t" \ \ /* Push the SPSR onto the task stack. */ \ "MRS R0, SPSR \n\t" \ "STMDB LR!, {R0} \n\t" \ \ "LDR R0, =ulCriticalNesting \n\t" \ "LDR R0, [R0] \n\t" \ "STMDB LR!, {R0} \n\t" \ \ /* Store the new top of stack for the task. */ \ "LDR R0, =pxCurrentTCB \n\t" \ "LDR R0, [R0] \n\t" \ "STR LR, [R0] \n\t" \ ); \ ( void ) ulCriticalNesting; \ ( void ) pxCurrentTCB; \ } #endif :):):) Теперь и на Supervisor-е работает вложенный FIQ! А раньше так же "падал" как и на IRQ. Изменено 17 ноября, 2009 пользователем GetSmart Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 17 ноября, 2009 Опубликовано 17 ноября, 2009 · Жалоба Теперь и на Supervisor-е работает вложенный FIQ! А раньше так же "падал" как и на IRQ. Вот поэтому я резко отрицательно отношусь к чужому коду, ибо времени на вычитывание надо затратить часто больше, чем на собственную имплементацию. Особенно, если необходимо сделать какой-то нестандарт, ну вот типа как у Вас. Да и повторное использование своего тоже требует осторожности, по крайней мере обязательна вычитка узких мест. PS Если охота пофлудить, можем развить тему унылогуаности всех методов, крутящихся возле идеи time-to-market, как то - повторное использование кода (да здравствуют апноты, либы производителей и исходники, скачанные где-то в интернете), ООП (как метод затруднения поиска потенциально бажных мест в коде ;) ), и т.д. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
GetSmart 0 17 ноября, 2009 Опубликовано 17 ноября, 2009 · Жалоба PS Если охота пофлудить, можем развить тему унылогуаности всех методов, крутящихся возле идеи time-to-market, как то - повторное использование кода (да здравствуют апноты, либы производителей и исходники, скачанные где-то в интернете), ООП (как метод затруднения поиска потенциально бажных мест в коде ;) ), и т.д. Мне было бы интересно узнать что-то новое. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 17 ноября, 2009 Опубликовано 17 ноября, 2009 · Жалоба Мне было бы интересно узнать что-то новое. Тактичное приглашение к флуду? ;) Завтра, я щас убегаю из-за компа, а с мобильника - нет того размаха :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
