PIC12F6xx trouble

Loading thread data ...

VR> INTCON = 0x00; // No ints

А не пробовал на всякий случай ставить здесь цикл ожидания подтверждения запрета прерывания - выполнения INTCON.7 = 0?

VR> WriteEE();

VR> while(1) CLRWDT();

Reply to
Rifkat Abdulin
Reply to
Vitaliy Romaschenko
Reply to
Vitaliy Romaschenko
Reply to
Maxim Polyanskiy

VR>>> INTCON = 0x00; // No ints RA>>

RA>> А не пробовал на всякий случай ставить здесь цикл ожидания RA>> подтверждения запрета прерывания - выполнения INTCON.7 = 0?

VR> Пpо паузу я писал еще в пpошлый pаз. Я вставил циклик и увеличивал веpхний VR> пpедел однобайтового счетчика. Запись становилась коppектной начиная со VR> значений VR> поpядка 100, т.е. получается более 100 мкс. Только паузу я ставил (убpал из

А просто что-то типа while (GIE == 0x00); поставить?

Reply to
Rifkat Abdulin

RA>> А просто что-то типа while (GIE == 0x00); RA>> поставить?

VR> Извини, я не совсем понимаю почему и сколько надо ожидать "подтвеpждения VR> запpета пpеpывания". Где можно пpочитать о такой необходимости? Мне некогда

На 12е, как и на 16е (IMHO)- рекомендуется после отключки прерываний (GIE = 0)операцией проверки бита GIE дожидаться установления этого режима. Объяснялось это в апнотах возможной неоднозначностью ветвления в ситуации, если само прерывание упадет в момент попытки его отключки - насколько я помню

VR> смотpеть весть даташит на PIC12. Hо поскольку у меня под pукой есть все VR> необходимое я тут же пpовеpил:

VR> ...

VR> INTCON = 0x00;

VR> while(GIE !=0) CLRWDT(); // ждем пока GIE станет нулем (так ты хотел?)

Вернее, наверное, так - while (GIE); //пока GIE = 1 - крутим

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

Думаю - причина все-таки в чем-то другом. Ты пришли скомпилленый кусок асма в этой части проги - проще будет понять

Reply to
Rifkat Abdulin
Reply to
Alexey V Bugrov

Thu Jan 20 2005 10:00, Alexey V Bugrov wrote to Rifkat Abdulin:

RA>> Hа 12е, как и на 16е (IMHO)- рекомендуется после отключки прерываний RA>> (GIE = 0)операцией проверки бита GIE дожидаться установления этого RA>> режима. Объяснялось это в апнотах возможной неоднозначностью ветвления RA>> в ситуации, если само прерывание упадет в момент попытки его отключки RA>> - насколько я помню

AVB> Hет такой проблемы. Эта апнота чей-то бред, который ни микрочип, не AVB> сторонние разработчики не смогли повторить. Команда в пиках неразрывна и AVB> бит будет сброшен независимо от того, возникло прерывание или нет.

_Сейчас_ такой проблемы может и нет, а в старых PIC16 она точно была (и наблюдалась воочию на PIC16C71), как была и аппликуха на сей счет. Кремниевый баг, имхо, который мелкочипы пофиксили где-то в середине 90-х.

С прерываниями мелкочипы долго ходили по разным граблям. Как показатель, в фичах 16С54 (даташит) явственно стояло наличие прерывания, хотя реально его там вообще не было. Имхо, хотели сделать, да не получилось, в последний момент изничтожили, но из даташита забыли убрать.

Пока, Алексей

Reply to
Alex Kouznetsov
Reply to
Alexey V Bugrov
Reply to
Vitaliy Romaschenko

Thu Jan 20 2005 13:13, Alexey V Bugrov wrote to Alex Kouznetsov:

AVB> Возможно. Только аппликуха вроде как 97 года издания, но вокруг нее уже AVB> немало плясок с бубном было. И здесь это обсуждалось в том числе. Как AVB> факт никому указанный в апликухе эффект повторить не удалось. От AVB> микрочипа вроде бы была информация, что ошибка была в инженерных AVB> версиях камней и в серии не встречается.

Я с этой проблемой имел дело примерно в 95 или 96 году, на серийных камнях. У меня это проявлялось как случайный повторный вход в прерывание (уже обработанное). Аппликуха, помнится, уже существовала.

С тех пор много лет я всегда ставил для нее фикс во все свои проги для PIC16, так что затрудняюсь точно сказать, начиная с какого времени не стало чипов с этой багой.

Пока, Алексей

Reply to
Alex Kouznetsov
Reply to
Maxim Polyanskiy
Reply to
Vitaliy Romaschenko
Reply to
Maxim Polyanskiy
Reply to
Vitaliy Romaschenko

VR> org 0

Можно вставить banksel GPIO

VR> goto Main

VR> org 0x50

VR> Pause VR> clrwdt VR> movlw dead_t VR> movwf j ; VR> jploop VR> decfsz j,F VR> goto jploop VR> return

VR> EEByteW VR> call Pause

Pause можно выкинуть.

VR> EEW0

banksel EECON1

btfsc EECON1, WR goto $-1

VR> banksel EEADR

VR> movlw 0x00 VR> movwf EEADR

VR> movlw 0x33 VR> movwf EEDATA

banksel EECON1

bcf EECON1, EEPGD ;насчет этого не знаю - это для 876го

VR> bsf EECON1, WREN ; Enable write VR> bcf INTCON, GIE ; Disable INTs.

btfsc INTCON, GIE goto $-1

banksel EECON2

VR> movlw 0x55 ; VR> movwf EECON2 ; Write 55h VR> movlw 0xAA ; VR> movwf EECON2 ; Write AAh

banksel EECON1

VR> bsf EECON1,WR ; Set WR bit VR> ; begin write VR> WaitEEOk VR> btfsc EECON1,WR VR> goto WaitEEOk VR> bcf PIR1,EEIF VR> bcf EECON1, WREN ; Disable write EEPROM VR> ; test written byte

banksel EEDATA

VR> movf EEDATA,W

banksel EECON1

VR> bsf EECON1,RD ; Start reading VR> nop

banksel EEDATA

VR> subwf EEDATA,W VR> BNZ EEW0 ; bad EEPROM - unlimited cycle (WDT reset) VR> ; written byte Ok VR> return

В-общем - могу попутать банкселы - с 12ми не работал ;-) Посмотри DS30292C - страница 43 - работа с EEPROM для 876го. Это точно работает :-)

Reply to
Rifkat Abdulin

Вспомнил - я еще анализировал при записи в EEPROM флаг досрочного прерывания цикла записи. МОжет - стоит его "подсмотреть"?

Reply to
Rifkat Abdulin

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.