MicroCHIP.RU
Главная Документация Отладочные средства Справочник Поиск Ссылки
 Новости   Конференция   Контакты 
 

баги ШИМа или компилятора?

 Нoвaя темa  |  Наверх  |  Перейти к теме  |  Поиск  |  Правила  |  Вход 

ВНИМАНИЕ!
Вы просматриваете архив форума.

Этот форум работает только в режиме просмотра и поиска.

Действующий форум переведен на новый движок и
находится по адресу www.microchip.su

 баги ШИМа или компилятора?
Автор: gen ()
Дата:   13/07/2006 15:19

PIC18F4420 компилятор mcc18. При работе ШИМа он сначала работает нормально, а затем
через некоторое время сигнал на выходе инвертируется. При этом изменяются биты в
регистре CCP1CON <1:0>. Для настройки ШИМ использую встроенные подпрограммы
компилятора. ШИМ настраивается только один раз при включении. Что это может быть?


 
 А Вы можете отключить
Автор: mborman ()
Дата:   13/07/2006 15:22

все в коде, кроме настройки шима, загнать программу в мертвый цикл и посмотреть, чем кончится?
Если все будет ок - значит баг в программе.


 
 Re: А Вы можете отключить
Автор: gen ()
Дата:   13/07/2006 15:43

отключил, пока работает. Может прерывания как-нибудь влияют?


 
 сами по себе они вряд-ли влияют,
Автор: mborman ()
Дата:   13/07/2006 15:46

а вот в их коде вероятно кроется западло - скажем, вполне реально сделать что-то вроде
  movlw xxx
  lfsr FSR0,CCP1CON
  movwf INDF0


т.е. проверьте, вдруг где-то непрямая адресация адресует регистры управления шимом.


 
 Re: сами по себе они вряд-ли влияют,
Автор: gen ()
Дата:   13/07/2006 15:54

Попробую, но в ассемблерном коде все в адресах , ни одного названия нет. Может
контекст неправильно сохраняется? Как его правильно сохранять? У меня в программе
прописано сохранение только PRODL и PRODH.


 
 это уже в доку к компилятору
Автор: mborman ()
Дата:   13/07/2006 15:59

смотрите + в листинг.


 
 Re: это уже в доку к компилятору
Автор: gen ()
Дата:   13/07/2006 16:04

В ассемблере напрямую адрес CCP1CON указывается только там, где у меня прописано.
Но вот насчет косвенного обращения к нему...???


 
 но я же Ваш листинг не вижу,
Автор: mborman ()
Дата:   13/07/2006 16:13

и, кроме того, я только высказал один из возможных вариантов причины сбоя шима.


 
 Re: баги ШИМа или компилятора?
Автор: 335 ()
Дата:   13/07/2006 16:48

Если есть ICD-2, поставте специальный брэйкпоинт на запись в ячейку CCP1CON и
когда остановится, по дизасму уже разбирайтесь, .


 
 Re: но я же Ваш листинг не вижу,
Автор: gen ()
Дата:   13/07/2006 17:34

вытащил кусок кода из ассемблера

вот так начинается прерывание
MOVFF 0xfd8, 0xfe4
NOP
MOVFF 0xfe0, 0xfe4
NOP
MOVWF 0xfe4, ACCESS
CALL 0x19ac, 0
NOP


0X19ac:
MOVFF 0xfda, 0xfe4
NOP
MOVFF 0xfe2, 0xfda
NOP
MOVFF 0xfe9, 0xfe4
NOP
MOVFF 0xfea, 0xfe4
NOP
MOVFF 0xfd9, 0xfe4
NOP
MOVFF 0xfda, 0xfe4
NOP
MOVFF 0xff3, 0xfe4
NOP
MOVFF 0xff4, 0xfe4
NOP
MOVF 0xfe6, F, ACCESS
RETURN 0


в переводе на нормальный русский язык это

MOVFF STATUS,PREINC1; сохранение регистра статус в рег-ре, адрес которого в FSR1
NOP ;??? кто записывает в FSR адрес памяти
MOVFF BSR,PREINC1 ;сохранение BSR
NOP
MOVWF PREINC1,ACCESS ;
CALL 0x19ac, 0 ;вызов подпрограммы 0x19ac
NOP


0X19ac:
MOVFF FSR2H,PREINC1 ;подпрограмма 0x19ac
NOP
MOVFF FSR1H,FSR2H
NOP
MOVFF FSR0L,PREINC1
NOP
MOVFF FSR0H,PREINC1
NOP
MOVFF FSR2L,PREINC1
NOP
MOVFF FSR2H,PREINC1
NOP
MOVFF PRODL,PREINC1
NOP
MOVFF PRODH,PREINC1
NOP
MOVFF POSTINC1,F,ACCESS


но при этом нигде не прописывается адрес в FSR1
или я что-то не понимаю? Да и само сохранение я бы лично сделал по другому


 
 пилите, Шура, пилите... (С)
Автор: mborman ()
Дата:   13/07/2006 18:00

gen писал(а):

> но при этом нигде не прописывается адрес в FSR1

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


Эмулятором не гоняли? Поставьте брейкпойнты на изменения CCPх, и ждите когда сработает (естественно,
в том варианте, который глючит).

> Да и само сохранение я бы лично сделал
> по другому

А кто Вам мешает сделать это по-другому? Пишите на асме вставочку - и вуаля.


 
 Re: баги ШИМа или компилятора?
Автор: Borschtsch ()
Дата:   13/07/2006 19:48

Сколько работаю с mcc18, пока тараканов только у себя в голове находил :) Вероятнее всего ошибка
где-то в программе.
Что-то подобное у меня обычно возникает, когда выхожу за пределы стека задачи. Компилятору абсолютно
ровно, что компилировать, а вот линкер слинкует так, как ему укажут. Так что может стоит обратить
внимание на файл скрипта. А в таком случае возможно, что влиянию подвержен не только регистр ШИМ.


 
 Re: баги ШИМа или компилятора?
Автор: gen ()
Дата:   14/07/2006 13:52

немного разобрался. Глюк исчезает, если отключать прерывания перед модификацией
данных в CCP1CON. Похоже, что он наступает при возникновении прерывания с высоким
приоритетом, при обработке прерывания с низким. Как можно правильно указать
компилятору чтобы он не использовал быстрые регистры при переходе на прерывания?
Или вообще, где можно найти инфу об этом?


 
 Re: баги ШИМа или компилятора?
Автор: dialex ()
Дата:   14/07/2006 14:58

http://ww1.microchip.com/downloads/en/DeviceDoc/80209e.pdf


23. Module: Interrupts
If an interrupt occurs during a two-cycle instruction
that modifies the STATUS, BSR or WREG register,
the unmodified value of the register will be saved
to the corresponding Fast Return (Shadow)
register and upon a fast return from the interrupt,
the unmodified value will be restored to the
STATUS, BSR or WREG register.
For example, if a high priority interrupt occurs
during the instruction, MOVFF TEMP, WREG, the
MOVFF instruction will be completed and WREG
will be loaded with the value of TEMP before
branching to ISR. However, the previous value of
WREG will be saved to the Fast Return register
during ISR branching. Upon return from the
interrupt with a fast return, the previous value of
WREG in the Fast Return register will be written to
WREG. This results in WREG containing the value
it had before execution of MOVFF TEMP, WREG.
Affected instructions are:
MOVFF Fs, Fd
where Fd is WREG, BSR or STATUS;
MOVSF Zs, Fd
where Fd is WREG, BSR or STATUS; and
MOVSS [Zs], [Zd]
where the destination is WREG, BSR or STATUS.


 
 Re: баги ШИМа или компилятора?
Автор: buka_2004 ()
Дата:   14/07/2006 16:04

Да они всегда используются. Поэтому при приоритетной системе
прерываний необходимо в низком приоритете програмносохранять
регистры Wreg, Status и т.д.




 
 Re: баги ШИМа или компилятора?
Автор: gen ()
Дата:   14/07/2006 17:47

В общем, вопрос решился. Надо при объявлении прерываний сохранять некоторые секции,
которые компилятор сам не сохраняет. Например:

#pragma interruptlow int_isr save=PRODL,PRODH, section (".tmpdata")

соответственно для высокоприоритетных прерываний будет

#pragma interrupt int_high_isr save=PRODL, PRODH, section (".tmpdata"), section
("int_isr_tmp")

т.е. дополнительно сохраняем еще переменные низкоприоритетного прерывания на случай
возникновения высокоприоритетного во время обработки низкоприоритетного.

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


 
 Re: баги ШИМа или компилятора?
Автор: Borschtsch ()
Дата:   15/07/2006 11:41

ясно.
Но на всякий случай почитай - есть ли у твоего камня проблемы с восстановлением wreg, bsr и status
из shadow регистров через retfie 1. На 18F2580 была такая.
Если есть, тогда поставь у высокоприоритетного прерывания #pragma interruptlow int_high_isr
save=PRODL, PRODH, section (".tmpdata"), section
("int_isr_tmp")
Компилятор будет использовать возврат retfie 0 при выходе из прерывания.