Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Баг ядра LPC2368?
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
GetSmart
Nov 12 2009, 10:43
Проц 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. Реальным пацанам smile.gif
KRS
Nov 12 2009, 11:36
Ну то что прерывание по DCC TX разрешено - так может это отладчик его использует, для debug_printf или еще для чего.
GetSmart
Nov 12 2009, 11:40
-----------------
Есть предположение, что это не баг, а фича под названием 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 ?
Я правильно перевёл?

Цитата(KRS @ Nov 12 2009, 17:36) *
Ну то что прерывание по DCC TX разрешено - так может это отладчик его использует, для debug_printf или еще для чего.

Проверил. debug_printf не используется в моём проекте.
KRS
Nov 12 2009, 11:40
Цитата(GetSmart @ Nov 12 2009, 14:37) *
-----------------
Есть предположение, что это не баг, а фича под названием RealMonitor, прошитая в bootloader.

Так его надо включить вызовом соответствующим!
GetSmart
Nov 12 2009, 12:13
Может кто-нибудь знает, как сбрасываются запросы от Embedded ICE, DbgCommRx и Embedded ICE, DbgCommTX или сиё тайна NXP?

Поставил в начале main() вот это
Код
        VICVectAddr = 0;
        VICVectAddr = 0;
        VICVectAddr = 0;
        VICVectAddr = 0;
        VICVectAddr = 0;
        VICVectAddr = 0;
        VICVectAddr = 0;

И всё заработало smile.gif

Всвязи с этим возник вопрос - как при рестарте проги (программно или по JTAG) правильно сбрасывать VIC ? Чтобы ещё и счётчик приоритетов обнулялся. И для чего существует регистр VICSWPriorityMask, на который в мануале нет внятного объяснения?

И что за регистр, находящийся по адресу 0xFFFFF028 ? В мануале его нет, но на моей картинке в первом посте он есть!

Ещё прикол в том, что иногда подобный баг возникал прямо при первой отладке. Возможно когда отладчик прерывал работающую прогу прямо из прерывания FreeRTOS - Timer0 и все прерывания блокировались. Мля.
KRS
Nov 12 2009, 12:38
Цитата(GetSmart @ Nov 12 2009, 15:13) *
Всвязи с этим возник вопрос - как при рестарте проги (программно или по JTAG) правильно сбрасывать VIC ? Чтобы ещё и счётчик приоритетов обнулялся.

Хороший вопрос!!!
Вообще надо что бы отладчик делал ресет контроллеру, но я тоже заметил что не всегда происходит сброс всей переферии. Похоже делается ресет, а потом проц останавливаетя, но уже успевает выполнить часть программы.
Можно в начале задержку поставить.

Цитата(GetSmart @ Nov 12 2009, 15:13) *
И для чего существует регистр VICSWPriorityMask, на который в мануале нет внятного объяснения?

Вам нужен datasheet от ARM
ARM DDI 0273A
ARM PrimeCell ™ Vectored Interrupt Controller (PL192)
Technical Reference Manual
VslavX
Nov 12 2009, 13:40
Цитата(GetSmart @ Nov 12 2009, 14:13) *
Поставил в начале main() вот это
Код
        VICVectAddr = 0;
        VICVectAddr = 0;
        VICVectAddr = 0;
        VICVectAddr = 0;
        VICVectAddr = 0;
        VICVectAddr = 0;
        VICVectAddr = 0;

И всё заработало smile.gif

Посмотрел в свои исходники - у меня есть такая строчки
Код
for (i=0; i<16; i++) pVic->sVIC_VECTOR = 0;     // очищаем аппаратный стек вложений

Начал вспоминать и вспомнил - VIC в LPC поддерживает схему приоритетов прерываний - когда происходит прерывание, VIC запоминает в свое внутреннем аппаратном стеке текущий уровень приоритета и все прерывания с более низким приоритетом - блокируются, с более высоким - разрешаются и "нестяться". Вот этот внутренний стек и чистится многократной записью VIC_VECTOR. 16 - глубина стека, равная числу уровней приоритета.

Цитата(GetSmart @ Nov 12 2009, 14:13) *
Может кто-нибудь знает, как сбрасываются запросы от 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
Nov 17 2009, 12:59
Зачем создавать новую тему, если можно здесь продолжить. Тем более, что название темы аналогичное.

Столкнулся с непонятным мне поведением 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 совпадают.
Rst7
Nov 17 2009, 13:04
Цитата
Либо прошу подсказать советом как мне найти почему этот баг происходит.


Ставлю литру на Ваш выбор, что в процессе выполнения команды mov r0,r0 происходит прерывание. В результате стек запарывается (видимо, сохранением LR в стек), ибо тут кодописатели - сами себе злобные буратины, код совершенно не предназначен для работы со вложенными прерываниями. Надо делать так:
Код
   stmfd sp!, {r0}
   sub sp,sp,#4
   stmia sp,{sp}^
   mov r0, r0
   ldr r0, [sp], #4


Короче, баг не в ядре, а в голове у кого-то.
GetSmart
Nov 17 2009, 13:19
Цитата(Rst7 @ Nov 17 2009, 19:04) *
Короче, баг не в ядре, а в голове у кого-то.

Внатуре smile.gif
Эти кретины сохраняют регистр не в стеке, а в свободной его области. И я потом на ней работаю и ненароком затираю biggrin.gif

YES!!!!!! Теперь работает smile.gifsmile.gifsmile.gif

Rst7, респект и уважуха biggrin.gif

Кто сообщит автору FreeRTOS, что у него косяк? smile.gif
Rst7
Nov 17 2009, 13:20
Цитата
Rst7, респект и уважуха


Да ладно. Я вот настоящий баг знаю. Правда, в ядрах 926EJ-S, которые в чипсетах мобильников от Siemens (Infineon) и SE (там не знаю кто). Там MOV PC,Rx не меняет режим ядра ARM->Thumb, хотя по даташиту - должен.
GetSmart
Nov 17 2009, 13:41
Вот исправленный макрос
CODE
#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


smile.gifsmile.gifsmile.gif

Теперь и на Supervisor-е работает вложенный FIQ! А раньше так же "падал" как и на IRQ.
Rst7
Nov 17 2009, 13:51
Цитата
Теперь и на Supervisor-е работает вложенный FIQ! А раньше так же "падал" как и на IRQ.


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

PS Если охота пофлудить, можем развить тему унылогуаности всех методов, крутящихся возле идеи time-to-market, как то - повторное использование кода (да здравствуют апноты, либы производителей и исходники, скачанные где-то в интернете), ООП (как метод затруднения поиска потенциально бажных мест в коде wink.gif ), и т.д.
GetSmart
Nov 17 2009, 14:10
Цитата(Rst7 @ Nov 17 2009, 19:51) *
PS Если охота пофлудить, можем развить тему унылогуаности всех методов, крутящихся возле идеи time-to-market, как то - повторное использование кода (да здравствуют апноты, либы производителей и исходники, скачанные где-то в интернете), ООП (как метод затруднения поиска потенциально бажных мест в коде wink.gif ), и т.д.

Мне было бы интересно узнать что-то новое.
Rst7
Nov 17 2009, 14:17
Цитата
Мне было бы интересно узнать что-то новое.


Тактичное приглашение к флуду? wink.gif Завтра, я щас убегаю из-за компа, а с мобильника - нет того размаха smile.gif
GetSmart
Nov 17 2009, 14:51
Цитата(Rst7 @ Nov 17 2009, 20:17) *
Тактичное приглашение к флуду? wink.gif

Для кого флуд, а для кого ценная информация smile.gif

Заметил ещё одну "странность" в коде прологов/эпилогов обычных функций, генеримом CW 1.7.9 с нулевой оптимизацией.
Код
       E1A0C00D   mov r12, sp
       E92DD800   stmfd sp!, {r11-r12, lr-pc}
       E24CB004   sub r11, r12, #0x00000004
...
       E24BD00C   sub sp, r11, #0x0000000C
       E89D6800   ldmfd sp, {r11, sp-lr}
       E12FFF1E   bx lr

Всё вроде нормально, но зачем в стеке сохраняется PC, кто-нибудь знает?
Dima_G
Nov 17 2009, 16:24
Цитата(GetSmart @ Nov 17 2009, 16:19) *
Внатуре smile.gif
Эти кретины сохраняют регистр не в стеке, а в свободной его области. И я потом на ней работаю и ненароком затираю biggrin.gif
Кто сообщит автору FreeRTOS, что у него косяк? smile.gif


Вообще то, эти кретины про это в ФАКе написали.
Ну дак ктож его читает

Цитата
See the description of the configKERNEL_INTERRUPT_PRIORITY and configMAX_SYSCALL_INTERRUPT_PRIORITY configuration parameters for additional information.

As downloaded most ports do not implement interrupt nesting - the exceptions being the Cortex M3 and PIC32 ports. In most cases the use of a fast real timer kernel removes the need for interrupts to nest.

Nesting interrupts introduces uncertainty into the stack usage requirements and complicates system behaviour analysis. Instead it is preferred that interrupt handlers do nothing but collect event data, post the data to a task, and clear the interrupt source. This permits the interrupt to exit very promptly by deferring any necessary computational processing of the event data to the task level - inside 'interrupt tasks'. The task level processing can be performed with interrupts enabled, negating the requirement for nesting.

This scheme has the added advantage of flexible event processing prioritisation. Task priorities are used instead of the prioritisation being dependent on the priority assigned to each interrupt source by the target processor. The prioritisation of interrupt handler tasks would normally be chosen to be higher than ordinary tasks within the same application - thereby allowing the interrupt handler to return directly into the peripheral handler task. The interrupt can interrupt a normal task, grab the data, then return to the interrupt handling task. When the interrupt handling task completes, the interrupted task (or whichever task is now the highest priority ready task) will automatically continue from the point at which it was interrupted. Processing of the interrupt routine itself and the interrupt handler task will be contiguous in time just as if all the processing had been performed in the interrupt itself, but using a much simpler mechanism.

In the case that a very fast interrupt response is required for a certain peripheral then the peripheral priority can normally be set to above that of the kernel itself. This means the processing of the peripheral will never be delayed by the action of the kernel.


http://www.freertos.org/index.html?http://...org/FAQISR.html
GetSmart
Nov 17 2009, 16:31
Ну я вообще не очень дружу с аглицким, но выделенным шрифтом не совсем тот баг обозначен (кажется). Там скорее всего про то, что таймер переключения тредов должен быть самым низкоприоритетным прерыванием (у меня 15). Что я сразу сделал и даже в какой-то ветке отписАлся.
Dima_G
Nov 17 2009, 16:38
Цитата(GetSmart @ Nov 17 2009, 19:31) *
Ну я вообще не очень дружу с аглицким, но выделенным шрифтом не совсем тот баг обозначен (кажется). Там скорее всего про то, что таймер переключения тредов должен быть самым низкоприоритетным прерыванием (у меня 15). Что я сразу сделал и даже в какой-то ветке отписАлся.


Выделил я не баг, а их мнение:
"В большинстве случаев, использование быстрого реал-таймового ядра избавляет от необходимости использовать вложенные прерывания"

Примечание переводчика: оборот "в большинстве случаев", ИМХО, по аналогии с тестом ДНК - максимальная вероятность 99.99%. 0.01% оставляется на вероятность того, что ДНК двух человек - идентична biggrin.gif

А до выделенного написано: Исходный вариант FreeRTOS не реализует (читай - не работает) вложенные прерывания. Исключение - кортекс М3 и ПИК32
GetSmart
Nov 17 2009, 16:54
Цитата(Dima_G @ Nov 17 2009, 22:38) *
А до выделенного написано: Исходный вариант FreeRTOS не реализует (читай - не работает) вложенные прерывания. Исключение - кортекс М3 и ПИК32

А всего-то надо было пару инструкций в порте исправить. Причём по тактам - равноценно.
Rst7
Nov 17 2009, 17:16
Цитата
А всего-то надо было пару инструкций в порте исправить.


Я эту конструкцию довольно во многих местах наблюдал (в серьезных коммерческих осях, изучение которых мною происходило при помощи дизассемблера). С некоторыми вариациями имеется принципиальная зопа со вложенными прерываниями. Когда то давно один идиот написал, сотня повторила. Вот оно, повторное использование кода (а иначе как соблюсти принцип "продать побыстрее") и бездумное передирание (даже авторы осей не владеют темой, а ведь это - основа, на которой держится все здание).
GetSmart
Nov 17 2009, 18:09
А вот из-за этой конструкции внутри portSAVE_CONTEXT() нельзя работать во вложенных прерываниях на стеке System/User. Хотя это и не резонно.
Код
    /* 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"    \

Если нельзя будет работать на стеке SVC, то будет обидно. Но пока стабильно моя прога работает. Работая на SVC есть один минус - нельзя вызывать portYIELD(), то бишь влетать снова в SVC, но из прерывания это делать как-то нелогично даже. А работая в Undef-е или в Abort-е - можно.
GetSmart
Nov 22 2009, 08:54
Вобщем, теперь вложенные прерывания прекрасно работают на стеках IRQ и SVC и уж тем более на Undef и Abort. Единственное ограничение - из вложенных прерываний (как и из прерываний вообще) нельзя вызывать некоторые функции FreeRTOS, типа delay, yield (и возможно ещё других).
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.