Программная задержка перед стартом ОС Опции

[Pavel V.]

Портирую одно устройство на scmRTOS и все шло хорошо, пока не начал заниматься датчиками, висящими на шине 1-Wire.

После долгих разборок удалось локализовать проблему, и вот что получилось:

Код

void main() {
    WDTCTL = WDTPW + WDTHOLD;
    TimerB_Init();

    __enable_interrupt();
        OS::Run();
}

Этот код работает, ОС запускается, задачи переключаются.

А вот этот:

Код

void main() {
    WDTCTL = WDTPW + WDTHOLD;
    TimerB_Init();

        for(volatile uint16_t i = 0; i < 5000; i++);

    __enable_interrupt();
        OS::Run();
}

Приводит к бесконечным рестартам устройства. Причем, поведение зависит от величины задержки. Если написать:

Код

for(volatile uint16_t i = 0; i < 1000; i++);

ОС запускается..

Компилятор - IAR.

Видимо, я не понимаю какие-то фундаментальные вещи, но своим умом понять не могу

К сообщению прикладываю тестовый проект.

Прикрепленные файлы

 scmrtos.zip ( 172.07 килобайт ) Кол-во скачиваний: 16

 

[Demeny]

Приводит к бесконечным рестартам устройства. Причем, поведение зависит от величины задержки.

Видимо, срабатывает watchdog.

[MrYuran]

А смысл этой задержки?

Скорее всего, дело в TimerB_Init();
Наверно, какой-то таймаут срабатывает.
Может, его перед стартом ОС повторить?

[jorikdima]

Не успевает ли срабоатть обработчик тикового прерывания ОС. А еще не запущена ОС, следовательно обработчик может там дел натворить. От чего работает тиковый таймер?

[Pavel V.]

Инициализация таймера:

Код

/*
* Init Timer B
*/
void TimerB_Init() {
    TBCTL = TBSSEL_2 + ID_3 + MC_1;    // SMCLK, /8, Up Mode, Interrupt Enable
    TBCCR0 = 1382 - 1;
    TBCCTL0 = CCIE;
}

А смысл этой задержки?

В данном тестовом примере смысла нет, в боевом же софте в этот момент производится сканирование шины 1-wire, при этом сумма задержек приводит к таким же последствиям.

Видимо, срабатывает watchdog

В первой строчке сторожевой таймер отключается.

Не успевает ли срабоатть обработчик тикового прерывания ОС. А еще не запущена ОС, следовательно обработчик может там дел натворить. От чего работает тиковый таймер?

По идее не должен, т.к. прерывания разрешаются непосредственно перед стартом ОС. До этого они запрещены по умолчанию.

Системный таймер работает от Timer B.

[MrYuran]

По идее не должен, т.к. прерывания разрешаются непосредственно перед стартом ОС. До этого они запрещены по умолчанию.
Системный таймер работает от Timer B.

Ну так перезапустите его перед OS::Run()

[Pavel V.]

Ну так перезапустите его перед OS::Run()

Да, действительно

Видимо, прерывание возникало сразу же после разрешения прерываний и система уходила в астрал из-за того, что ядро еще не стартануло..

Вопрос можно считать закрытым. А я целый день мучился понять причины такого поведения.

Спасибо всем за помощь!

[ReAl]

Если я что-то в чём-то понимаю, то разрешать прерывания перед стартом ОС не нужно.
Конструктор процесса инициализирует образ регистра состояния на стеке процесса значением, разрешающим прерывания.
В конце «восстановления» контектса первого процесса на старте ОС прерывания автоматически будут разрешены.
Неужели для Вашего контроллера не так?

[jorikdima]

Видимо, прерывание возникало сразу же после разрешения прерываний и система уходила в астрал из-за того, что ядро еще не стартануло..

Ставиться флаг от таймера мог в любой момент и до разрешения прерывания, а само прерывание, действительно, возникало только после разрешения.