PIC12F629 & MPLAB на симуляторе работает, а при, прошивке не работает Опции

[skyled]

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

[xemul]

GP3/MCLR?

UPD: сразу не разлядел, что __CONFIG у Вас закомментирован. Снимите комментарий с первого, если на GP3 нет притяжки к Vcc, в __CONFIG добавьте & MCLRDIS.

[skyled]

GP3/MCLR?

UPD: сразу не разлядел, что __CONFIG у Вас закомментирован. Снимите комментарий с первого, если на GP3 нет притяжки к Vcc, в __CONFIG добавьте & MCLRDIS.

Потом перепрограммировать можно будет?

[xemul]

Потом перепрограммировать можно будет?

Вам с какой страницы даташит пересказывать?

[skyled]

Сделал, перепрошил. Ругнулось на некорректное конфигурационное слово. Оставил старое - не работает. Перезаписал слово не изменяя. По завершении сказало, что слово конфигурации после проверки осталось прежним. По прежнему и неработает.

Подтянул внешним в 1 ком. Не помогло. Явно что-то программное. Ну вобщемто по даташиту проверил что значит 0x31D4. Вродебы все нормально. Должно работать.

Сообщение отредактировал skyled - Jan 4 2011, 11:55

[xemul]

Сделал, перепрошил. Ругнулось на некорректное конфигурационное слово. Оставил старое - не работает. Перезаписал слово не изменяя. По завершении сказало, что слово конфигурации после проверки осталось прежним. По прежнему и неработает.

Подтянул внешним в 1 ком. Не помогло. Явно что-то программное. Ну вобщемто по даташиту проверил что значит 0x31D4. Вродебы все нормально. Должно работать.

0x31D4 соответствует __CONFIG(WDTDIS & UNPROTECT & INTIO & MCLRDIS);
Телепатировать, что означает "Ругнулось на некорректное конфигурационное слово ...", я не возьмусь. Можно помедитировать над сорцами с комментами (вряд ли кто-то кинется смотреть в ДШ, что означают 0b00001100 и 0b00100000), ^C^V руганью компилятора и хотя бы словесным описанием схемы (типа GP3/MCLR используется как ...), но не над неинформативным потоком сознания.

[skyled]

Компилятор не ругается. Ругается программатор. Даташит прочитал весь. На симуляторе работает как нужно. При прошивке не работает. Нужно понять в чем разница.

[skyled]

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

[xemul]

А мне думается это соответствует 0x3FD4. Программатор слово 0x3FD4 считает некорректным, на что и ругается. Предлагает исправить на 0x31D4. Соглашаясь или нет - ничего не меняется. При чтении имеем всегда 0x31D4.

Одноцветно. В ДШ чёрным по-английски "bit 11-9 Unimplemented: Read as ‘0’". Писать в них можно пытаться всё что угодно - не запишется.
Не знаю, каким программатором Вы пользуетесь, но те, которыми пользуюсь я (и оригинальные от Мелкочипа, и третьих фирм), на Unimplemented bits не возбуждаются.

В обоих случаях не работает программа (для МК).

Похоже, за счёт определения __delay_ms() компилятор Вам прощает пропущенную букву

Код

#define _XTAL_FREQ 4000000L

, но таки неаккуратненько.
В остальном чему-то не работать в Вашей программе сложно. Каждые 256 мкс будут приключаться T0IF, каждую 1.х3сколько мс - инвертироваться почти все GPIOx.
Я не знаю как Вы определяете, что "не работает программа". Может просто питание до контроллера не добегает?

[skyled]

Букву добавил. Перепрошил. Не помогло. На почти всех GPIO нули. Выв 4 подтянут к +5 В. Интервал 200 мС. Осциллограф бы заметил если что было бы. Питание добегает. Если залить hex, сгенерированый другой программой (не MPLAB vs HITECH), то светодиод загорается и гаснет как и положено. В случае, если залитиь мой hex, то ничего не происходит. Уже в тупике. Мой hex прилагается. Может есть возможность его залить в PIC12F629 и посмотреть, что будет? Спасибо.

P.S. Самое злое в этом, что симулируется все правильно.
 pic12_test.zip ( 370 байт ) Кол-во скачиваний: 90

[xemul]

Букву добавил. Перепрошил. Не помогло.

В данном случае и не должно было помочь. Я просто обратил Ваше внимание, что 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 контроллера) - съэкономите и своё, и чужое время, если кто-то будет разбираться с Вашими сорцами.

[skyled]

Попробовал. Результат тотже. Завтра попробую собрать другой программатор, хотя неплохобы всетаки знать причину. Чудес не бывает.

[xemul]

Попробовал. Результат тотже. Завтра попробую собрать другой программатор, хотя неплохобы всетаки знать причину. Чудес не бывает.

Проверьте, не затерся ли байт калибровки внутреннего генератора. Прочитайте память контроллера, по адресу 0x3fe должно быть 0x34xx.
Чтобы исключить проказы компилятора, которым Вы пользуетесь, в аттаче два хекса, собранных по последнему сорцу разными версиями.
Чтобы исключить предупреждения программатора, в конфиге замаскированы неиспользуемые биты.

Код

__CONFIG(WDTDIS & UNPROTECT & INTIO & MCLRDIS & 0x31ff);

[attachment=51778:test.zip]

[smk]

Байт калибровки точно затерт т.к. делался полный сброс контроллера и было предупреждение. о том. что этот байт будет тоже потерян. Это критично? Другая программа же работает.

[xemul]

Байт калибровки точно затерт т.к. делался полный сброс контроллера и было предупреждение. о том. что этот байт будет тоже потерян. Это критично? Другая программа же работает.

Это предположение или констатация факта?
"полный сброс контроллера" - имеется в виду 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;
- взять новый контроллер, а запиленный прибить гвоздём на видном месте.

[Дмитрий Ветра]

Проверьте, не затерся ли байт калибровки внутреннего генератора. Прочитайте память контроллера, по адресу 0x3fe должно быть 0x34xx.
Чтобы исключить проказы компилятора, которым Вы пользуетесь, в аттаче два хекса, собранных по последнему сорцу разными версиями.
Чтобы исключить предупреждения программатора, в конфиге замаскированы неиспользуемые биты.

Код

__CONFIG(WDTDIS & UNPROTECT & INTIO & MCLRDIS & 0x31ff);

[attachment=51778:test.zip]

Да, если не будет в конце памяти программ инструкции "retlw" с константой, а она в данном случае не причем, то код будет циклиться в начале стартапа. Обойти это - поможет не вызывать функцию 0x3ff. Я перекомпилил код выше без вызова функции. Естественно генератор будет уже некалиброванным, что на самом деле не страшно.

В догонку вот что получилось при компилировании:

Код

    list      p=12F629           ; list directive to define processor
    #include <p12F629.inc>       ; processor specific variable definitions

    errorlevel  -302             ; suppress message 302 from list file

    __CONFIG   _CP_OFF & _CPD_OFF & _BODEN_OFF & _MCLRE_OFF & _WDT_OFF & _PWRTE_ON & _INTRC_OSC_NOCLKOUT

       org    0
       GOTO   L00F


       org    4
       MOVWF  0x5e             ; save W
       MOVF   STATUS,W
       BCF    STATUS,RP0
       MOVWF  0x20             ; save STATUS
       MOVF   FSR,W
       MOVWF  0x21             ; save FSR
       MOVF   PCLATH,W
       MOVWF  0x22             ; save PCLATH
       MOVF   0x5f,W
       MOVWF  0x23
       GOTO   L034              ; jump to int overlay
L00F
       BSF    STATUS,RP0
;       CALL   0x3ff            ; get calibration value
;       MOVWF  OSCCAL           ; save
       CLRF   STATUS
       GOTO   L050
L014
       MOVLW  0xc              ; GPPU<<1|INTEDG<<1
       BSF    STATUS,RP0
       MOVWF  OPTION_REG
       MOVLW  0x20
       MOVWF  INTCON           ; T0IE<<1
       MOVLW  0x8
       MOVWF  TRISIO           ; xx00 1000
       MOVLW  0x7
       BCF    STATUS,RP0
       MOVWF  CMCON            ; set 0..2 pin as digio
       MOVLW  0xff
       MOVWF  GPIO             ; xx11 1111
       BSF    INTCON,GIE         ; sei
L021
       MOVLW  0x2
       BCF    STATUS,RP0
       MOVWF  0x26
       MOVLW  0x03
       MOVWF  0x25
       MOVLW  0xba
       MOVWF  0x24
L028                        ; delay overlay  init 0x0203ba
       DECFSZ 0x24,F
       GOTO   L028
       DECFSZ 0x25,F
       GOTO   L028
       DECFSZ 0x26,F
       GOTO   L028
       BCF    STATUS,RP0
       COMF   GPIO,F        ; toggle pins
       NOP
       GOTO   L021
       GOTO   L021
       GOTO   L00F
L034
       BTFSS  INTCON,T0IE   ; TMR0 enabled ?
       GOTO   L037          ;
       GOTO   L038          ; TMR0 Int enabled
L037
       GOTO   L045          ; no, resume int
L038
       BTFSS  INTCON,T0IF   ; int req from TMR0 overflow ?
       GOTO   L03B          ; no, resume int
       GOTO   L03C
L03B
       GOTO   L045          ; restore content
L03C
       BCF    INTCON,T0IF   ; clear flag
       MOVLW  0x1
       ADDWF  0x27,F        ; low tick_count
       BTFSC  STATUS,C
       INCF   0x28,F
       MOVLW  0
       ADDWF  0x28,F        ; high tick_count
       GOTO   L045
       GOTO   L045
L045
       MOVF   0x23,W
       MOVWF  0x5f
       MOVF   0x22,W        ; restore PCLATH
       MOVWF  PCLATH
       MOVF   0x21,W
       MOVWF  FSR           ; restore FSR
       MOVF   0x20,W
       MOVWF  STATUS        ; restore STATUS
       SWAPF  0x5e,F
       SWAPF  0x5e,W        ; restore W
       RETFIE
L050
       CLRF   0x29
       CLRF   0x27
       CLRF   0x28
       CLRF   STATUS
       GOTO   L014

       end

Сообщение отредактировал Дмитрий Ветра - Jan 7 2011, 17:21

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

 test12.zip ( 366 байт ) Кол-во скачиваний: 14

 

[DL36]

- взять новый контроллер, а запиленный прибить гвоздём на видном месте.

Неа проще взять PciKit2 и восстановить константу.

[skyled]

Вот такая вот ошибка в т.ч. и в случае с перекомпиленным. Что бы это значило?

[skyled]

Файлы, кстати, заливались в новый МК.

[xemul]

Вот такая вот ошибка в т.ч. и в случае с перекомпиленным. Что бы это значило?

Да что угодно - хардварные проблемы в программаторе (н-р, Vpp не держится), софтовые от и до. Если есть время и желание - разбирайтесь.
А лучше закажите PicKit2'образное (я и забыл про него, спасибо DL36).

[skyled]

http://www.qrz.ru/schemes/contribute/constr/extra-pic/ Вот этим пользуюсь. 12 В держится, но в процессе светодиод помигивает. Это должно так быть? Пробовал шить - проблемы с нулевым адресом на всех файлах и двух платах.

Код

А лучше закажите PicKit2'образное

Да вот хочу на PIC18F2550 PicKit2-образное собрать, но тотже PIC надо чем-то шить

[skyled]

хардварные проблемы в программаторе

Ну вобщем так и вышло. Только проблема не в программаторе была, а в целевом устройстве. К выв. 6 и 7 были подключены входы микросхемы ULN2003. Выпаял и все заработало как по маслу. Собственно в связи с этим вопрос. В даташите есть упоминание о резисторах между выводами программирования и остальной схемой, но нет упоминания про их номинал (или смотрел плохо). В ULN2003 стоит 2,7 кОм. Это мало?

[xemul]

Ну вобщем так и вышло. Только проблема не в программаторе была, а в целевом устройстве. К выв. 6 и 7 были подключены входы микросхемы ULN2003. Выпаял и все заработало как по маслу. Собственно в связи с этим вопрос. В даташите есть упоминание о резисторах между выводами программирования и остальной схемой, но нет упоминания про их номинал (или смотрел плохо). В ULN2003 стоит 2,7 кОм. Это мало?

Странно это. 2.7 кОм по PGD, PGC было достаточно любому программатору/отладчику, которыми мне доводилось пользоваться.
Могу предположить только, что 1533ЛА3 на 2.7 кОм не обеспечивает VIH1 (CLOCK, DATA) input high level >= 0.8 VDD (при программировании PGD, PGC на вход работают триггерами Шмитта с порогами 0.2 и 0.8 VDD).
Если есть возможность, попробуйте заменить её на КМОП аналог типа 74AC(T)00.

Кста, в списке поддерживаемых этим программатором PIC18F2550/4550 отсутствуют (это я про сборку пиккит2).
И не нравится мне неотключаемое Vcc, но, наверное, это фича всех подобных программаторов.

[skyled]

Импортный аналог там и стоит. Не разглядел, но похоже на то, что Вы пишите. Всеравно прийдется какой-то буфер делать. SN74HC14 есть под рукой. Если пользовать WinPic800, то PIC18F2550 поддерживается, уже залил. Спасибо за консультации. Посмотрим как заработает а-ля PicKit2. Может еще какие вопросы по ходу будут. Спасибо.

[smk]

Калибровочное слово я знаю уже. Дело действительно именно в нем. по совету сменить программатор собрал PicKit2 Если я записываю им hex из MPLAB, то калибровочное слово теряется и контроллер не работает (не тактируется? или с чем это связано?). Если я в программе PicKit2 v2.52 с помощью нового программатора сначала определяю это калибровочное слово, а потом прошиваю hex то все работает. При повторном программировании из MPLAB опять не работает. Кстати последний раз не удалось восстановить калибровочное слово программатором. Попыток было несколько. Хорошо, что записал на бумажке.Ввел вручную - заработало. Как сделать так чтобы MPLAB не сносила єто слово и можно было программировать из нее. Для чего нужна строка OSCCAL = _READ_OSCCAL_DATA(); и в каком месте программы она должна быть? Спасибо.

[Дмитрий Ветра]

Калибровочное слово я знаю уже. Дело действительно именно в нем. по совету сменить программатор собрал PicKit2 Если я записываю им hex из MPLAB, то калибровочное слово теряется и контроллер не работает (не тактируется? или с чем это связано?). Если я в программе PicKit2 v2.52 с помощью нового программатора сначала определяю это калибровочное слово, а потом прошиваю hex то все работает. При повторном программировании из MPLAB опять не работает. Кстати последний раз не удалось восстановить калибровочное слово программатором. Попыток было несколько. Хорошо, что записал на бумажке.Ввел вручную - заработало. Как сделать так чтобы MPLAB не сносила єто слово и можно было программировать из нее. Для чего нужна строка OSCCAL = _READ_OSCCAL_DATA(); и в каком месте программы она должна быть? Спасибо.

Эта строка (функция) как раз то и читает калибровочное слово из памяти PIC. Если по адресу нахожднения калибровочного слова не будет инструкции RETLW, то не будет возврата из функции _READ_OSCCAL_DATA(), а это означает, что программа будет крутитьтся в начале инициализации вечно. Когда MPLAB сносит (стирает) константу, вместо RETLW там будет пустая ячейка, что интерпретируется как инструкция ADDWF.

Код

   CALL   0x3ff                  ; get calibration value
             MOVWF  OSCCAL          ; save

[xemul]

Калибровочное слово я знаю уже. Дело действительно именно в нем. по совету сменить программатор собрал PicKit2 Если я записываю им hex из MPLAB, то калибровочное слово теряется и контроллер не работает (не тактируется? или с чем это связано?). Если я в программе PicKit2 v2.52 с помощью нового программатора сначала определяю это калибровочное слово, а потом прошиваю hex то все работает. При повторном программировании из MPLAB опять не работает. Кстати последний раз не удалось восстановить калибровочное слово программатором. Попыток было несколько. Хорошо, что записал на бумажке.Ввел вручную - заработало. Как сделать так чтобы MPLAB не сносила єто слово и можно было программировать из нее.

Programmer->Settings->Calibration memory
Чтобы использовалась заводская калибровка (или то, что уже записано), снимите галку "Allow to program Calibration memory"
Чтобы записать своё значение, поставьте галку и задайте "New Value". 0x80 соответствует середине калибровочного интервала.

Для чего нужна строка OSCCAL = _READ_OSCCAL_DATA(); и в каком месте программы она должна быть? Спасибо.

Project->Build Options->Project->Linker
Установленная галка "Calibrate oscillator" всё сделает за Вас (в прологе, до старта main(); см. startup.lst в папке проекта).
Можете задать своё значение в поле "Alternate oscillator calibration value".
Для использования заводской калибровки поле нужно очистить.
Если же хочется всё сделать самому, снимите галку и вставьте OSCCAL = _READ_OSCCAL_DATA(); в прогу там, где хочется.
Если такой галки нет, обновите UniversalToolSuite.

Можно ещё почитать .chm к MPLab'у и программатору, manual.pdf к компилятору и помедитировать в симуляторе.

[smk]

Programmer->Settings->Calibration memory

Вот такого у меня нет.

Project->Build Options->Project->Linker
Установленная галка "Calibrate oscillator" всё сделает за Вас

Такая галка есть, но она установлена и поле пустое. Почему ничего не происходит?

[smk]

Почемуто всякий раз после заливки из MPLAB последний байт оказывается нулевым (ну в смысле значение в последней ячейке 0000). Даже если вписать конкретное значение в ту ячейку. Даже если он там был. Почему так и что делать с этим?  pic2.rar ( 352 байт ) Кол-во скачиваний: 72
Файл сгенерированный MPLAB.

[xemul]

Вот такого у меня нет.

Версия MPLab какая?
UPD сейчас добавил поддержку PICKit2 (ну нет у меня его) - действительно в настройках программатора в MPLab никаких упоминаний об OSCCAL.
Посмотрите "\Program Files\Microchip\MPLAB IDE\PICkit 2\hlpPICkit2.chm" - там описывается какая-то оболочка для PICKit2, и в её опциях поминается OSCCAL.

Такая галка есть, но она установлена и поле пустое. Почему ничего не происходит?

Значит на компилятор можно не грешить. Проверьте на всякий случай:
- на закладке Linker поле Debugger установлено в Auto;
- при компиляции с включённым симулятором последнее слово в памяти программ должно получаться 0x3400, с выключенной отладкой - 0x3fff.

[smk]

- на закладке Linker поле Debugger установлено в Auto;

так и есть

Оба варианта и как я понимаю они одинаковые.

Код

:020000000F28C7
:10000800DE0003088312A0000408A1000A08A20069
:100018005F08A30041288316FF2390008301572817
:100028000C308316810020308B00083085000730A3
:1000380083129900FF3085008B172228261C25285B
:100048002628222826100130A4070318A50A003004
:10005800A50703302506031D33280D302406031D8C
:100068003628372822280030A4000030A50085094A
:1000780022282228222822280F288B1E4428452897
:100088004C280B1D482849284C280B1126144C28AD
:100098002308DF0022088A00210884002008830042
:1000A800DE0E5E0E0900A601A401A5018301142835
:0207FE0038348D
:02400E00D431AB
:00000001FF

:020000000F28C7
:10000800DE0003088312A0000408A1000A08A20069
:100018005F08A30041288316FF2390008301572817
:100028000C308316810020308B00083085000730A3
:1000380083129900FF3085008B172228261C25285B
:100048002628222826100130A4070318A50A003004
:10005800A50703302506031D33280D302406031D8C
:100068003628372822280030A4000030A50085094A
:1000780022282228222822280F288B1E4428452897
:100088004C280B1D482849284C280B1126144C28AD
:100098002308DF0022088A00210884002008830042
:1000A800DE0E5E0E0900A601A401A5018301142835
:0207FE0038348D
:02400E00D431AB
:00000001FF

MPLAB 8.60.00.00 Certified

Та програмка, на нелп кот орой Вы дали ссылку как раз прошивает как надо.

[xemul]

так и есть

Тогда при изменении Debugger->Select Tool->MPLab Sim/None это поле должно меняться соответственно.

Оба варианта и как я понимаю они одинаковые.

Угу, с 0x3400 в конце, что соответствует компиляции для симулятора.

Та програмка, на нелп кот орой Вы дали ссылку как раз прошивает как надо.

Два вопроса:
- она прошивает приведённый хекс?
- "как надо" - это с калибровкой из хекса или из пика?

Приаттачьте что ли .mcp, .mcw, .mcs и сорцы (всё в архиве, естесно), потому что иначе Вас, похоже, на чистую воду не вывести.

[xemul]

Почемуто всякий раз после заливки из MPLAB последний байт оказывается нулевым (ну в смысле значение в последней ячейке 0000).Даже если вписать конкретное значение в ту ячейку. Даже если он там был. Почему так и что делать с этим?

Попробуйте отделить бузину от дядьки и внятно описать свои действия, т.к. это описание явно адресовано телепатам.
По адресу 0x3ff живёт 0x3400? Тогда скорее всего в ходе экспериментов в байт калибровки действительно было вписано 0x00. Восстановите калибровку с помощью PICKit2.
Или там живёт 0x0000? Может приключиться при сбое при программировании (н-р, при кратковременном нарушении контакта по PGC). Восстановите калибровку с помощью PICKit2.
Даже если вписать где? В настройках линкера, н-р, или непосредственно в контроллер.
Даже если был где? В контроллере исходно было 0x34что-то, а после программирования стало 0x3400? Приаттаченный .hex такого сделать точно не сможет - там по адресу 0x3ff штатное 0x3fff.
Внятно:
- контроллер новый?
- слово по адресу 0x3fff в контроллере до и после программирования
- слово по адресу 0x3fff в .hex
- чем писалось

Файл сгенерированный MPLAB.

IDE (среда разработки) - MPLab, компилятор (который что-то генерирует) - picc.

[skyled]

Компилятор HI-TECH.

Мои действия такие (описываю с самого начала):
1) Создал проект в MPLAB, в качестве компилятора указал HI-TECH, контроллер PIC12F629;
2) Написал текст программы (тут уже приводил);
3) Нажал красную кнопочку для компиляции;
4) Подключил PicKit2, он системой опознался. Установил его в качестве программатора. В окошке увидел, что PicKit2 ready и контроллер found.
5) Скомандовал программатору записать программу. Программа успешно записалась.
6) Программа в контроллере не работает т.к. светодиод не моргает.
7) Устанавливаю в MPLAB программатор none, загружаю PicKit2 v2.52.
8) Читаю из контроллера прошивку. В последней ячейке 0х0000;
9) Вручную средствами PicKit2 v2.52 вписываю значение 3438 в последнюю ячейку. Программа начинает работать.
10) Читаю программатором прошивку заново. В последней ячейке 3438.

При этом дополню, что если изначально программировать средствами PicKit2 v2.52 (п.5), то программа успешно шьется и работает.

[smk]

С нетерпеним жду какой будет вердикт или совет? Да и хочется использовать режим отладки.