Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: прерывания таймера. прошу помощи
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > MSP430
kavimanus
Помогите разобраться новичку. Пытался самостоятельно - не вышло. Ниже кусок когда (максимально упрощенный). Суть в банальном прерывании от таймера, которое срабатывает по достижении определённого значения, но вот срабатывает оно (прерывание) очень странно. Точнее имеются странные показания регистров при делителе частоты = 1 (значения приведены ниже).

Код
    .org    0xf800                    ;код с этого адреса        

init:
    mov.w #WDTPW+WDTHOLD, &WDTCTL;остановить WD

    mov.b &0x10FC, &DCOCTL            ;установка DCO
    mov.b &0x10FD, &BCSCTL1        ;на частоту 8МГц
    mov.b #0x06, BCSCTL2            ;Источник сигнала для MCLK и SMCLK - DCOCLK. делитель MCLK-1. делитель SMCLK-8. резистор внутр.

    mov.w #0280h, SP                ;стек с адреса #0x0280
    
    eint                            ;общее разрешение прерываний

loop:    
    mov.w #TASSEL_2+ID_0+MC_1+TACLR, TACTL;источник сигнала - SMCLK/делитель частоты - 1/прямой счет/сброс таймера
    mov.w #CM_0+CCIE, TACCTL0        ;нет захвата+разрешить прерывание (по переполнению)
    mov.w #10000, TACCR0            ;предел счета
    call #delay_proc        
    jmp loop            

delay_proc:
    mov.w #GIE+CPUOFF,SR            ;LPM0
    ret

TimerA_int:                        ;обработчик прерывания Timer_A
    nop                            ;для отладки
    clr.w TACTL                    ;остановить таймер
    reti                            ;вернуться из прерывания    


    .org 0xfffe                        ;адрес вектора прерывания проц-ры сброса
    dw init                        ;обработчик прерывания

    .org 0xfff2                        ;адрес вектора прерывания Таймера_А, по переполнению
    dw TimerA_int                    ;обработчик прерывания


В таком виде прерывание от таймера срабатывает, но попав обработчик регистры имеют непонятные значения:

До входа в обработчик

TACTL=0x210
TA0CCTL0=0x10
TA0CCTL1=0x00
TA0CCTL2=0x00
TAR=0x00
TA0CCR0=0x2710
TA0CCR1=0x00
TA0CCR2=0x00

При входе в обработчик

TACTL=0x211
TA0CCTL0=0x10
TA0CCTL1=0x01
TA0CCTL2=0x01
TAR=0x00
TA0CCR0=0x2710
TA0CCR1=0x00
TA0CCR2=0x00

Т.е. в регистре TAR значение 0x00 вместо 0x2710. И устанавливаются флаги CCIFG в регистрах TA0CCTL1 и TA0CCTL2

Стоит отметить, что при других значениях делителя частоты (ID_1, ID_2, ID_3. регистр TACLR) значения вполне адекватные.

Например при значении ID_1 состояния регистров следующие:

До входа в обработчик

TACTL=0x250
TA0CCTL0=0x10
TA0CCTL1=0x00
TA0CCTL2=0x00
TAR=0x00
TA0CCR0=0x2710
TA0CCR1=0x00
TA0CCR2=0x00

При входе в обработчик
TACTL=0x250
TA0CCTL0=0x10
TA0CCTL1=0x00
TA0CCTL2=0x00
TAR=0x2710
TA0CCR0=0x2710
TA0CCR1=0x00
TA0CCR2=0x00

Помогите пожалуйста разобраться в чём моя ошибка?

P.S.: Прошу прощения за форматирование текста
Baser
Цитата(kavimanus @ May 24 2018, 14:22) *
Помогите пожалуйста разобраться в чём моя ошибка?

Судя по всему при делителе на 1 у вас прерывание возникает еще до того, как вы настроите регистр TACCR0.
Попробуйте запускать таймер после настройки:

Код
    mov.w #MC_0, TACTL; Stop timer
    mov.w #CM_0+CCIE, TACCTL0
    mov.w #10000, TACCR0
    mov.w #TASSEL_2+ID_0+MC_0+TACLR, TACTL; Cfg. and Clear timer
    mov.w #TASSEL_2+ID_0+MC_1, TACTL; Start timer

Ну и флаги прерываний на других каналах тоже видите поэтому. Ибо 0=0
А в других случаях они успевают сброситься в прерывании-заглушке.
kavimanus
Цитата(Baser @ May 24 2018, 15:24) *
Судя по всему при делителе на 1 у вас прерывание возникает еще до того, как вы настроите регистр TACCR0.
Попробуйте запускать таймер после настройки:

Код
    mov.w #MC_0, TACTL; Stop timer
    mov.w #CM_0+CCIE, TACCTL0
    mov.w #10000, TACCR0
    mov.w #TASSEL_2+ID_0+MC_0+TACLR, TACTL; Cfg. and Clear timer
    mov.w #TASSEL_2+ID_0+MC_1, TACTL; Start timer

Ну и флаги прерываний на других каналах тоже видите поэтому. Ибо 0=0
А в других случаях они успевают сброситься в прерывании-заглушке.



Согласен с Вами. Ощущение такое, что прерывание генерируется неким иным источником, нежели задумано (что само по себе для меня странно по ряду причин). За идею Вам большое спасибо, попробовал, в разных вариациях, но увы, пока результат тот же.
k155la3
Не указали как (отладчиком или как) смотрите регистры.
Попробуйте зафиксировать значения регистров которые смотрите не отладчиком, а используя переменные.
Возможно при этом все будет работать как и ожидалось.
Снизьте тактовую частоту еще в 2 или 4 раза.
На время отладки не изменяйте режим LPM (только в активном режиме).
kavimanus
Цитата(k155la3 @ May 26 2018, 08:22) *
Не указали как (отладчиком или как) смотрите регистры.
Попробуйте зафиксировать значения регистров которые смотрите не отладчиком, а используя переменные.
Возможно при этом все будет работать как и ожидалось.
Снизьте тактовую частоту еще в 2 или 4 раза.
На время отладки не изменяйте режим LPM (только в активном режиме).


- Значения регистров смотрю в отладчике (IAR). Попытка анализа без отладчика, например включение светодиода по состоянию регистров (тому их состоянию, которое предполагается), так же положительных результатов не даёт.
- При использовании активного режима (без перехода в режимы энергосбережения) результат не меняется.
- Изменение значения делителя частоты (и соответственно частоты тактирующего сигнала) действительно дает ожидаемый положительный результат. Но, опять же, при различных частотах DCO появляются новые "спецэффекты"
- Мне не понятно то, что прерывание, судя по всему, генерируется регистрами TACCL1 и TACCL2 (флаги CCIFG этих регистров установлены при входе в обработчик прерывания) в то время, как флаги CCIE, этих регистров изначально сброшены (т.е. чисто теоретически и прерывания от них запрещены). В то же время прерывание от TACCL0 разрешено, но не срабатывает, хотя, насколько я понимаю, имеет более высокий приоритет.
- Есть подозрение, что я как-то неверно произвожу начальную инициализацию модуля синхронизации и таймера, но в чём моя ошибка, пока понять не могу.

Капаю дальше )
kavimanus
Хочу поблагодарить всех, кто оказывал помощь. Вопрос более не актуален. Всё работает.

Выводы следующие:

- действительно не стоит полностью полагаться на отладчик (что прискорбно);
- более вдумчиво нужно читать документацию.

Еще раз спасибо за посильную помощь. Все советы были полезны и способствовали решению моего вопроса.
k155la3
Цитата(kavimanus @ May 27 2018, 02:01) *
Хочу поблагодарить всех, кто оказывал помощь. Вопрос более не актуален. Всё работает.
. . .

sm.gif "Легко отделались" sm.gif Спасибо за отчет.
---
Еще одна причина, по которой может возникать такое непонятное поведение.
Неверное, по тем или иным причинам, "подключение" h-файлов и макроса переключения на конктретный тип процессора.
(при этом, ест-но, наблюдается "фонарная" установка адресов регистров и их битов).
В лучшем случае - не работает вообще. В худшем - проявляется в виде сбоев.

kavimanus
Цитата(k155la3 @ May 28 2018, 11:54) *
sm.gif "Легко отделались" sm.gif Спасибо за отчет.
---
Еще одна причина, по которой может возникать такое непонятное поведение.
Неверное, по тем или иным причинам, "подключение" h-файлов и макроса переключения на конктретный тип процессора.
(при этом, ест-но, наблюдается "фонарная" установка адресов регистров и их битов).
В лучшем случае - не работает вообще. В худшем - проявляется в виде сбоев.


Интересное замечание. Возьму на заметку, спасибо. Хотя, конечно, совсем отказываться от уже прописанных константных значений, и производить побитовую инициализацию, не очень бы хотелось )
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2024 Invision Power Services, Inc.