Баг ядра LPC2368? Опции

[GetSmart]

Проц 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. Реальным пацанам

Сообщение отредактировал GetSmart - Nov 12 2009, 10:36

Эскизы прикрепленных изображений

 

[Rst7]

Либо прошу подсказать советом как мне найти почему этот баг происходит.

Ставлю литру на Ваш выбор, что в процессе выполнения команды mov r0,r0 происходит прерывание. В результате стек запарывается (видимо, сохранением LR в стек), ибо тут кодописатели - сами себе злобные буратины, код совершенно не предназначен для работы со вложенными прерываниями. Надо делать так:

Код

   stmfd sp!, {r0}
   sub sp,sp,#4
   stmia sp,{sp}^
   mov r0, r0
   ldr r0, [sp], #4

Короче, баг не в ядре, а в голове у кого-то.

[GetSmart]

Короче, баг не в ядре, а в голове у кого-то.

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

YES!!!!!! Теперь работает

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

Кто сообщит автору FreeRTOS, что у него косяк?

Сообщение отредактировал GetSmart - Nov 17 2009, 13:11

[Dima_G]

Внатуре
Эти кретины сохраняют регистр не в стеке, а в свободной его области. И я потом на ней работаю и ненароком затираю
Кто сообщит автору FreeRTOS, что у него косяк?

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

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