| |
 PIC12F629 & MPLAB на симуляторе работает, а при, прошивке не работает |
|
|
|
|
 Jan 4 2011, 11:11
|
Местный
Группа: Участник
Сообщений: 217
Регистрация: 11-06-10
Пользователь №: 57 868
|
MPLAB vs HI-TECH C компилятор делают файл hex. После прошивки его в PIC12F629 работы контроллера не наблюдается, хотя другая программа работает, т.е. аппаратно все исправно. Прошиваю PIC программатор v4.10a. Все красиво. Биты конфигурации 0x31D4. В симуляторе все красиво работает, а реально на выходе контроллера все нули. Код #include <htc.h>
#include <stdio.h>
#include <stdlib.h>
//__CONFIG(WDTDIS & UNPROTECT & INTIO); // Program config. word 1
//__CONFIG(INTIO); // Program config. word 2
#define _XTAL_FREQ 4000000
#define bitset(var, bitno) ((var) |= 1UL << (bitno))
#define bitclr(var, bitno) ((var) &= ~(1UL << (bitno)))
bit flag;
unsigned int tick_count;
void eetest(void) {
unsigned char value = 255;
unsigned char address = 0;
// write value to EEPROM address
eeprom_write(address, value);
// read from EEPROM at address
value = eeprom_read(address);
}
//FLASH_WRITE(address,value);
//variable=FLASH_READ(address);
//ei(); // enable all interrupts
//di(); // disable all interrupts
//CLRWDT();
void interrupt tc_int(void)
{
if (T0IE && T0IF) {
T0IF=0;
++tick_count;
//GPIO=~GPIO;
return;
}
}
void main(void)
{
OPTION=0b00001100;
INTCON=0b00100000;
TRISIO=0b00001000;
CMCON=0b00000111;
GPIO=0xFF;
//eetest();
ei(); // enable all interrupts
while(1)
{
__delay_ms(1);//а было и 100 и 500
GPIO=~GPIO;
NOP();
}
} Кто подскажет где искать причину? В pic-ах новичок. Спасибо.
Сообщение отредактировал skyled - Jan 4 2011, 11:12
|
|
|
|
|
|
|
|
Jan 4 2011, 11:21
|
Местный
Группа: Участник
Сообщений: 217
Регистрация: 11-06-10
Пользователь №: 57 868
|
Цитата(xemul @ Jan 4 2011, 18:15)  GP3/MCLR?
UPD: сразу не разлядел, что __CONFIG у Вас закомментирован. Снимите комментарий с первого, если на GP3 нет притяжки к Vcc, в __CONFIG добавьте & MCLRDIS. Потом перепрограммировать можно будет?
|
|
|
|
|
|
|
|
Jan 5 2011, 08:05
|
Местный
Группа: Участник
Сообщений: 217
Регистрация: 11-06-10
Пользователь №: 57 868
|
Цитата 0x31D4 соответствует __CONFIG(WDTDIS & UNPROTECT & INTIO & MCLRDIS); А мне думается это соответствует 0x3FD4. Программатор слово 0x3FD4 считает некорректным, на что и ругается. Предлагает исправить на 0x31D4. Соглашаясь или нет - ничего не меняется. При чтении имеем всегда 0x31D4. В обоих случаях не работает программа (для МК). Вот такой код сейчас: Код #include <htc.h>
#include <stdio.h>
#include <stdlib.h>
__CONFIG(WDTDIS & UNPROTECT & INTIO & MCLRDIS); // Program config. word 1
#define _XTAL_FREQ 4000000
bit flag;
unsigned int tick_count;
void interrupt tc_int(void)
{
if (T0IE && T0IF) {
T0IF=0;
++tick_count;
return;
}
}
void main(void)
{
OPTION=0b00001100;
INTCON=0b00100000;
TRISIO=0b00001000;
CMCON=0b00000111;
GPIO=0xFF;
ei(); // enable all interrupts
while(1)
{
__delay_ms(1);
GPIO=~GPIO;
NOP();
}
}
Сообщение отредактировал skyled - Jan 5 2011, 08:33
|
|
|
|
|
|
|
|
Jan 5 2011, 10:47
|
Группа: Свой
Сообщений: 1 928
Регистрация: 11-07-06
Пользователь №: 18 731
|
Цитата(skyled @ Jan 5 2011, 14:05) А мне думается это соответствует 0x3FD4. Программатор слово 0x3FD4 считает некорректным, на что и ругается. Предлагает исправить на 0x31D4. Соглашаясь или нет - ничего не меняется. При чтении имеем всегда 0x31D4. Одноцветно. В ДШ чёрным по-английски "bit 11-9 Unimplemented: Read as ‘0’". Писать в них можно пытаться всё что угодно - не запишется. Не знаю, каким программатором Вы пользуетесь, но те, которыми пользуюсь я (и оригинальные от Мелкочипа, и третьих фирм), на Unimplemented bits не возбуждаются. Цитата В обоих случаях не работает программа (для МК). Похоже, за счёт определения __delay_ms() компилятор Вам прощает пропущенную букву Код #define _XTAL_FREQ 4000000L , но таки неаккуратненько. В остальном чему-то не работать в Вашей программе сложно. Каждые 256 мкс будут приключаться T0IF, каждую 1.х3сколько мс - инвертироваться почти все GPIOx. Я не знаю как Вы определяете, что "не работает программа". Может просто питание до контроллера не добегает?
|
|
|
|
|
|
|
|
Jan 5 2011, 11:26
|
Местный
Группа: Участник
Сообщений: 217
Регистрация: 11-06-10
Пользователь №: 57 868
|
Букву добавил. Перепрошил. Не помогло. На почти всех GPIO нули. Выв 4 подтянут к +5 В. Интервал 200 мС. Осциллограф бы заметил если что было бы. Питание добегает. Если залить hex, сгенерированый другой программой (не MPLAB vs HITECH), то светодиод загорается и гаснет как и положено. В случае, если залитиь мой hex, то ничего не происходит. Уже в тупике. Мой hex прилагается. Может есть возможность его залить в PIC12F629 и посмотреть, что будет? Спасибо. P.S. Самое злое в этом, что симулируется все правильно. 
pic12_test.zip ( 370 байт )
Кол-во скачиваний: 90
|
|
|
|
|
|
|
|
Jan 5 2011, 12:07
|
Группа: Свой
Сообщений: 1 928
Регистрация: 11-07-06
Пользователь №: 18 731
|
Цитата(skyled @ Jan 5 2011, 17:26) Букву добавил. Перепрошил. Не помогло. В данном случае и не должно было помочь. Я просто обратил Ваше внимание, что 4000000 > 32767, и поэтому нужно явно указать тип константы. Цитата На почти всех GPIO нули. Выв 4 подтянут к +5 В. Интервал 200 мС. Осциллограф бы заметил если что было бы. Питание добегает. Если залить hex, сгенерированый другой программой (не MPLAB vs HITECH), то светодиод загорается и гаснет как и положено. В случае, если залитиь мой hex, то ничего не происходит. Уже в тупике. Мой hex прилагается. Может есть возможность его залить в PIC12F629 и посмотреть, что будет? Спасибо.
P.S. Самое злое в этом, что симулируется все правильно. Заливать Ваш хекс мне некуда. Попробуйте это: Код #include <htc.h>
__CONFIG(WDTDIS & UNPROTECT & INTIO & MCLRDIS);
#define _XTAL_FREQ 4000000UL
#define TICK 256 // TMR0 interrupt rate in us
#define LED_BLINK_RATE 200000UL // 200 ms
volatile bit flag;
unsigned int tick_count;
void interrupt tc_int(void)
{
if (T0IE && T0IF)
{
T0IF = 0;
flag = 1;
}
}
void main(void)
{
OPTION = 0b00001100;
INTCON = 0b00100000;
TRISIO = 0b00001000;
CMCON = 0b00000111;
GPIO = 0xFF;
ei(); // enable all interrupts
while(1)
{
if(flag)
{
flag = 0;
if(++tick_count == (LED_BLINK_RATE / TICK))
{
tick_count = 0;
GPIO = ~GPIO;
}
}
}
} Из "сэрца горэстний замэт" (С) неизвестный грузынский поэт начала 19 века: - ПРО причудлив, пользуйтесь ЛАЙТ/СТД; - если предполагается что-то сложнее мырганья лампочкой, не пользуйтесь _delay() и её производными; - коктейль из _delay() с прерываниями даст дивное послевкусье и сильную головную боль; - пишите комментарии (особенно для инициализации SFR контроллера) - съэкономите и своё, и чужое время, если кто-то будет разбираться с Вашими сорцами.
|
|
|
|
|
|
|
|
Jan 5 2011, 15:44
|
Группа: Свой
Сообщений: 1 928
Регистрация: 11-07-06
Пользователь №: 18 731
|
Цитата(skyled @ Jan 5 2011, 18:30) Попробовал. Результат тотже. Завтра попробую собрать другой программатор, хотя неплохобы всетаки знать причину. Чудес не бывает. Проверьте, не затерся ли байт калибровки внутреннего генератора. Прочитайте память контроллера, по адресу 0x3fe должно быть 0x34xx. Чтобы исключить проказы компилятора, которым Вы пользуетесь, в аттаче два хекса, собранных по последнему сорцу разными версиями. Чтобы исключить предупреждения программатора, в конфиге замаскированы неиспользуемые биты. Код __CONFIG(WDTDIS & UNPROTECT & INTIO & MCLRDIS & 0x31ff); [attachment=51778:test.zip]
|
|
|
|
|
|
|
|
Jan 6 2011, 09:28
|
Группа: Свой
Сообщений: 1 928
Регистрация: 11-07-06
Пользователь №: 18 731
|
Цитата(smk @ Jan 6 2011, 00:04) Байт калибровки точно затерт т.к. делался полный сброс контроллера и было предупреждение. о том. что этот байт будет тоже потерян. Это критично? Другая программа же работает. Это предположение или констатация факта? "полный сброс контроллера" - имеется в виду Bulk Erase? Дык любой разумный программатор в соответствии со спецификацией программирования должен прочитать байт калибровки и биты BGx перед Bulk Erase и восстановить их после. Если софт программатора этого не делает, то я бы поискал что-нить более пристойное. Если по адресу байта калибровки не будет восстановлен хотя бы код инструкции (0x34XX == retlw 0xXX), а останется 0x3fff (после стирания; == addlw 0xff), то после addlw будет выполнена инструкция по адресу 0x0000. Другая программа может работать, если в ней не используется call 0x3fe .. retlw 0xXX Варианты лечения: - в опциях компилятора снять галку "Use OSCCAL" (в проге в качестве костыля можно добавить что-нить вроде OSCCAL = 0x80; // установит OSCCAL на середину диапазона); - оставить галку, в проге добавить что-нить вроде 0x3480 @ 0x3fe (тоже самое, только в профиль); - каким-либо образом откалибровать по-новой внутренний генератор и вписать полученное значение вместо XX в 0x34XX @ 0x3fe; - взять новый контроллер, а запиленный прибить гвоздём на видном месте.
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
