Перейти к содержанию
    

Costa

Участник
  • Постов

    19
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о Costa

  • Звание
    Участник
    Участник
  • День рождения 05.12.1970

Контакты

  • Сайт
    Array
  • ICQ
    Array
  1. Что ж, каждый выбирает себе решение исходя из своих приоритетов. И Вам удачи!
  2. Хм, это интересный поворот. Надо будет на досуге сымитировать подобное. Но полагаю, что вероятность порчи основной прошивки в этом случае исчезающе мала, т.к. нужно точно "попасть" в код записи/стирания, иначе весь ущерб - нештатный переход в бутлоадер и как следствие - перезагрузка в рабочую прошивку или штатно, или по WDT. Внешний чип не обеспечит защиты от копирования.
  3. Ну можно же и проверку адреса в бутлоадере вставить, чтобы запретить самоперезапись. Да, бутлоадер на своем месте, проверено считыванием из МК всей памяти. В моем случае - F000. У меня все нормально работает на мегах 16/32/64, и только на 640 затык :(
  4. Так этот код же находится в пространстве бутлоадера, стереть/записать самого себя он не может, а если по ошибке программиста/мантейнера прошивки зальется "левая" прошивка, которая не позволит штатным образом переходить в бутлоадер, то это проблема программиста/мантейнера. Если же произойдет сбой и запишется "мусор", то не сойдется CRC прошивки, и бутлоадер просто не передаст на нее управление, ожидая загрузки по новой. По моей проблеме - ни у кого не возникло идей? Куда рыть?
  5. Вот исходник с разрешением RWW else if (type == TYPE_PROGRAM) { // Program page buffer into flash page unsigned int *q = (unsigned int *) pageBuffer; unsigned char APPFLASH *r = address; spmErasePage(address); spmEnableRWW(address); do { spmWriteWord(r, *q++); r += 2; } while (--size); spmProgramPage(address); spmEnableRWW(address); } Вот исходник spm640.asm NAME spm(16) PUBLIC spmWriteWord PUBLIC spmErasePage PUBLIC spmEnableRWW PUBLIC spmProgramPage PUBLIC spmEEWriteByte #define __ENABLE_BIT_DEFINITIONS__ #include INCLUDE_FILE #if !defined( EEMWE ) #define EEMWE EEMPE #endif #if !defined( EEWE ) #define EEWE EEPE #endif //============================================================================= // I/O registers used RSEG CODE //============================================================================= // Writes one word to a temporary page buffer spmWriteWord: movw r1:r0, r19:r18 ldi r22, (1 << SPMEN) rjmp spmSPM //============================================================================= // Erases one flash page spmErasePage: ldi r22, (1 << PGERS) | (1 << SPMEN) rjmp spmSPM //============================================================================= // Re-enables RWW section spmEnableRWW: ldi r22, (1 << RWWSRE) | (1 << SPMEN) rjmp spmSPM //============================================================================= // Programs the temporary buffer to flash memory spmProgramPage: ldi r22, (1 << PGWRT) | (1 << SPMEN) //============================================================================= // Executes self-programming command spmSPM: ; movw r31:r30, r17:r16 ldi r31, 0 ldi r30, 0 ldi r19, 0x13 ldi r18, 0x57 movw r1:r0, r19:r18 rcall spmWait in r20, SREG cli sts SPMCSR, r22 spm dw 0xFFFF nop out SREG, r20 ret spmWait: wdr __spmWait: lds r23, SPMCSR andi r23, (1 << SPMEN) brne __spmWait ret //============================================================================= // Writes one byte to EEPROM memory spmEEWriteByte: rcall spmWait rcall spmEEWriteByteComplete out EEARL, r16 out EEARH, r17 out EEDR, r18 sbi EECR, EEMWE sbi EECR, EEWE spmEEWriteByteComplete: sbic EECR, EEWE rjmp spmEEWriteByteComplete ret END Увы, результат печальный - FLASH не пишется :(
  6. Вообще нет, и до этого случая все прекрасно работало. Не хочется думать, что мне просто несказанно везло, но за несколько лет сбоев не наблюдалось. Возможно используется какой-то хитрый трюк, давно это было. По теме - я об этом думал и даже делал тест, в котором реализовывал такой алгоритм - стирание страницы, разрешение RWW, запись в буфер, запись страницы, разрешение RWW. Результат был тем же - не работало. Но если Вы считаете, что это критически важно, я повторю тест и выложу результат с исходником. Смотря что Вы имеете в виду под "слетом" прошивки. Если несанкционированный вылет рабочей прошивки в код загрузчика - то да, такое теоретически возможно, и да, теоретически возможно, что МК попадет в такое место загрузчика, в котором зациклится. Но на этот случай есть WDT, который сбросит МК и все восстановится, если конечно а) в этом "цикле" не встретится команда wdr б) сам WDT не окажется временно отключенным. Повторюсь из предыдущего поста - я с таким не сталкивался. А если Вы боитесь, что во время обновления произойдет сбой, прошивка "недообновится" и привет - то нет. Принцип такой - сначала ВСЕГДА стартует бутлоадер, смотрится некий признак, переходить ли в режим обновления. Если признака нет (тут каждый на что горазд придумывает по каким критериям переходить, смотря какой интерфейс используется, таймауты и пр.), считается CRC всей памяти МК (application, т.е. от 0 до бутлоадера), если CRC сошлась, управление передается на 0-ой адрес рабочей прошивке. Рабочая прошивка тоже должна уметь "ловить" какие-то признаки, по которым она передает управление бутлоадеру в целях обновления. Как она это делает? Тупо и цинично :) - встает колом и по WDT ресетится, попадая в бутлоадер. Ну а если бутлоадер "понял", что кто-то извне хочет обновлять - он и обновляет, ну там целый набор команд в аппноте, опять же Вы можете оставить себе только необходимые. Например я оставил только запись FLASH/EEPROM, старт/стоп, все чтения удалил, и все остальное. А фузы блокировки выставил таким образом, что из рабочей прошивки нельзя ни читать ни писать область бутлоадера, и нельзя ни читать ни писать application область, и поскольку прошивки формирую только я, и прошивки эти шифрованные (ключ внутри бутлоадера, на каждый тип устройства свой), получилось очень удобно - вероятность взлома прошивки или ее воровства практически нулевая. Да, забыл добавить, если происходит сбой при обновлении, надо просто запустить процесс повторно - в 99.99% случаев помогает.
  7. Доброго времени суток, коллеги! Столкнулся с подобной проблемой, не пишется FLASH из бутлоадера. Бутлоадер немного переделанный под себя из AES-аппнота, подобных бутлоадеров понаделано прилично под меги 16/32/64, все работают. А вот под 640 - не шьет :( Исходные данные: камень Atmega640-16AU, питание схемы 5В, кварц 14.7456МГц. Фузы: E:0xF4 H:0xDA L:0xD7 L:0x3F (вообще последний должен быть 0x0C, но ставлю 0x3F для тестов, чтобы уж точно была разрешена запись spm и чтобы потом FLASH можно было прочитать для сравнения) Вот кусочки исходников, откуда пишется во FLASH else if (type == TYPE_PROGRAM) { // Program page buffer into flash page unsigned int *q = (unsigned int *) pageBuffer; unsigned char APPFLASH *r = address; do { spmWriteWord(r, *q++); r += 2; } while (--size); spmErasePage(address); spmProgramPage(address); } Вот исходник spm640.asm (сделал специальный под 640, обрезав "лишнее") NAME spm(16) PUBLIC spmWriteWord PUBLIC spmErasePage PUBLIC spmProgramPage PUBLIC spmEEWriteByte #define __ENABLE_BIT_DEFINITIONS__ #include INCLUDE_FILE #if !defined( EEMWE ) #define EEMWE EEMPE #endif #if !defined( EEWE ) #define EEWE EEPE #endif //============================================================================= // I/O registers used RSEG CODE //============================================================================= // Writes one word to a temporary page buffer spmWriteWord: movw r1:r0, r19:r18 ldi r22, (1 << SPMEN) rjmp spmSPM //============================================================================= // Erases one flash page spmErasePage: ldi r22, (1 << PGERS) | (1 << SPMEN) rjmp spmSPM //============================================================================= // Programs the temporary buffer to flash memory spmProgramPage: ldi r22, (1 << PGWRT) | (1 << SPMEN) //============================================================================= // Executes self-programming command spmSPM: ; movw r31:r30, r17:r16 ; в целях тестирования по адресу 0 всегда пишем константу 0x1357 ldi r31, 0 ldi r30, 0 ldi r19, 0x13 ldi r18, 0x57 movw r1:r0, r19:r18 rcall spmWait in r20, SREG cli sts SPMCSR, r22 spm dw 0xFFFF nop out SREG, r20 ret spmWait: wdr __spmWait: lds r23, SPMCSR andi r23, (1 << SPMEN) brne __spmWait ret //============================================================================= // Writes one byte to EEPROM memory spmEEWriteByte: rcall spmWait rcall spmEEWriteByteComplete out EEARL, r16 out EEARH, r17 out EEDR, r18 sbi EECR, EEMWE sbi EECR, EEWE spmEEWriteByteComplete: sbic EECR, EEWE rjmp spmEEWriteByteComplete ret END Вот настройки линкера -ca90 -w29 //============================================================================= // Interrupt vectors -Z(CODE)INTVEC=(FLASH_SIZE-BOOT_SIZE)-(FLASH_SIZE-BOOT_SIZE+IVT_SIZE-1) -H1895 -h(CODE)(FLASH_SIZE-BOOT_SIZE)-(FLASH_SIZE-BOOT_SIZE+IVT_SIZE-1) //============================================================================= // Code memory -Z(CODE)NEAR_F,HUGE_F,SWITCH,INITTAB,DIFUNCT,CODE=(FLASH_SIZE-BOOT_SIZE)-(FLASH_SIZE-1) -Z(FARCODE)FAR_F,FARCODE=(FLASH_SIZE-BOOT_SIZE)-(FLASH_SIZE-1) //============================================================================= // RAM -Z(DATA)NEAR_I,NEAR_Z=RAM_BASE-(RAM_BASE+RAM_SIZE-1) -Z(DATA)RSTACK+100=RAM_BASE-(RAM_BASE+RAM_SIZE-1) -Z(DATA)CSTACK+(RAM_SIZE-300-APP_SRAM_USAGE)=RAM_BASE-(RAM_BASE+RAM_SIZE-1) Вот вывод map-а **************************************** * * * MODULE MAP * * * **************************************** DEFINED ABSOLUTE ENTRIES PROGRAM MODULE, NAME : ?ABS_ENTRY_MOD Absolute parts ENTRY ADDRESS REF BY ===== ======= ====== APP_SRAM_USAGE 0000042E RAM_BASE 00000200 RAM_SIZE 00002000 IVT_SIZE 000000E4 FLASH_SIZE 00010000 BOOT_SIZE 00001000 ************************************************************************* .............. SEGMENTS IN THE MODULE ====================== INTVEC Common segment, address: CODE 0000F000 - 0000F063 (0x64 bytes), align: 0 Segment part 0. **************************************** * * * SEGMENTS IN ADDRESS ORDER * * * **************************************** SEGMENT SPACE START ADDRESS END ADDRESS SIZE TYPE ALIGN ======= ===== ============= =========== ==== ==== ===== INTVEC CODE 0000F000 - 0000F063 64 com 1 NEAR_F CODE 0000F064 - 0000F097 34 rel 0 SWITCH CODE 0000F098 dse 0 HUGE_F CODE 0000F098 dse 0 INITTAB CODE 0000F098 - 0000F09D 6 rel 0 DIFUNCT CODE 0000F09E dse 0 CODE CODE 0000F09E - 0000F9C9 92C rel 1 ABSOLUTE DATA 0000001F rel 0 DATA 00000020 DATA 00000021 DATA 00000027 - 00000028 2 DATA 0000002A - 0000002B 2 DATA 0000002D - 0000002E 2 DATA 00000030 - 00000031 2 DATA 00000033 - 00000034 2 DATA 00000036 - 00000036 1 DATA 0000004C - 0000004E 3 DATA 00000055 - 00000055 1 DATA 00000060 - 00000060 1 DATA 0000006F - 0000006F 1 DATA 0000007C - 0000007C 1 DATA 00000080 - 00000082 3 DATA 00000084 - 00000085 2 DATA 000000C0 - 000000C1 2 DATA 000000C4 - 000000C6 3 DATA 00000101 - 00000102 2 DATA 00000104 - 00000105 2 DATA 00000107 - 00000108 2 DATA 0000010A - 0000010B 2 NEAR_I DATA 00000200 dse 0 NEAR_Z DATA 00000200 - 0000061F 420 rel 0 RSTACK DATA 00000620 - 0000071F 100 dse 0 CSTACK DATA 00000720 - 00001FF1 18D2 dse 0 **************************************** * * * END OF CROSS REFERENCE * * * **************************************** 2 506 bytes of CODE memory 7 666 bytes of DATA memory (+ 41 absolute ) Errors: none Warnings: none Пишу бутлоадер, обновляю через него прошивку, читаю FLASH - чистая с 0-го адреса (0xFFFF), с 0xF000 - бутлоадер. Пишу бутлоадер и рабочую прошивку, обновляю через бутлоадер прошивку, читаю FLASH - прошивка по адресу 0 на константу 0x1357 не затирается, с 0xF000 - бутлоадер. Прошу помощи, уже весь мозг сломал, в чем может быть причина, куда копать.
  8. ucGoZilla

    Мой ответ на этот вопрос прост. Я всегда считал извращением только лишь для прошивки ставить или держать на винте огромные монстроузные пакеты типа MAX+PLUS II или Quartus, даже в их урезанной версии. Посему идея реализовать JAM-плеер в консольной утилите, отправляя команды записи-чтения блока через эмуляцию COM-порта, мне представляется весьма рациональной. К тому же такой подход легко прокатит на Линуксе. О! Это тоже круто и очень нужно. Остается только надеяться, что свободного времени на эти проекты удастся выделить побольше :)
  9. ucGoZilla

    prottoss, как с планами реализовать какой-нибудь "бластер" для прошивки Altera? Мне тут понадобится в одно устройство поставить Altera, паять LPT шнурок никакого смысла нет, а покупать USB-бластер не хочется, ведь у нас же есть ucGoZilla B) У Altera есть код JAM-плеера, который можно встраивать в свой процессор, там только один файлик нужно подправить. Ту часть, которая отвечает за стык этого плеера с USB и с Quartus, в расчет не беру, т.к. не могу адекватно оценить сложности ее реализации. А вот сам JAM-плеер вроде не сложен для портирования.
  10. ucGoZilla

    А хотите еще прикол? Ведь я программировал только BODLEVEL, но включение самого BOD - нет, поэтому и не предполагал, что с этим BOD-ом могут быть проблемы. Читаем Errata: 10. BOD will be enabled after any reset If any reset source goes active, the BOD will be enabled and keep the device in reset if the VCC voltage is below the programmed BOD level. During Power-On Reset, reset will not be released until VCC is above the programmed BOD level even if the BOD is disabled. Problem fix/Workaround Do not set the BOD level higher than VCC even if the BOD is not used.
  11. ucGoZilla

    prottoss, дело не в программаторе. Вспомнил я, что когда-то давно покупал по акции Atmel-а программатор AVR Dragon, да валялся он без дела, т.к. имел совершенно идиотское ограничение на чипы с объемом flash более 32 Кб. Сейчас уже это ограничение снято, дай думаю попробую восстановить чип с помощью этого Dragon. Для этого поставил AVR Studio 4.18 SP3 (build 716), обновил прошивку в Dragon-e. Взял плату с xmega32A4, которую еще не прошивал - через Dragon все нормально и шьется и читается, в т.ч. и fuse5 - правда здесь обнаружена одна особенность, о ней ниже расскажу. А тот чип, который был испорчен, даже через Dragon недоступен - на любую попытку выдает "Failed to set emulatore mode. Unable to continue." Теперь про особенность. Открываем даташит XMEGA-A Manual (8077H–AVR–12/09) стр. 33 - fuse5 [2:0] BODLEVEL отсылает нас к таблице 9-2 на стр. 106, где для всех 8-и кодов перечислены значения: 1.6(111) 1.8(110) 2.0(101) 2.2(100) 2.4(011) 2.7(010) 2.9(001) 3.2(000). Более того, в даташите на сам кристалл (8069Q–AVR–12/10) на стр. 67 в табл. 34-10 также перечислены все 8 уровней BOD - правда с другими значениями, именно на них мне и стоило опираться: BOD level 0 falling Vcc 1.7 BOD level 1 falling Vcc 1.9 BOD level 2 falling Vcc 2.17 BOD level 3 falling Vcc 2.43 BOD level 4 falling Vcc 2.68 BOD level 5 falling Vcc 2.96 BOD level 6 falling Vcc 3.22 BOD level 7 falling Vcc 3.49 Я запрограммировал fuse5=0xF0, что соответствует 3.2В по мануалу, но 3.49В по даташиту. Видимо в этом месте я и прокололся, т.к. питание у меня 3.3В (реально 3.39В). Что интересней всего, AVR Studio предлагает всего 7 уровней (т.к. измеренное им питание target 3.4В, то возможность запрограммировать BODLEVEL до 3.49В он благоразумно не предлагает). Повысив питание платы до 3.58В, удалось перепрограммировать fuse5 и вернуть чип к жизни. Но что самое интересное! - код BODLEVEL 000 AVR Studio интерпретирует как Undefined, вот так вот. В итоге, плата восстановлена, программатор не виноват. Не знаю, имеет ли смысл внести в прошивку программатора ограничение - если кто-то попытается прошить fuse5 BODLEVEL 000, возвращать ошибку. Хотя ведь кому-нибудь может понадобиться BODLEVEL 3.49В, уж и не знаю, кому. prottoss, еще раз спасибо за проделанную работу. fuse5 в норме. Если надо будет потестировать утилиты на работоспособность с чипсетами материнок не-Intel, всегда готов :)
  12. ucGoZilla

    Попробовал скомпилить под Линуксом avrdude 5.10 из svn, результат тот же, поэтому в дальнейшем использовал стандартный avrdude 5.10 У меня только xmega32a4, других не пробовал. Про биты только на чтение понятно, но ИМХО это должно приводить максимум к локальной ошибке при прошивке именно fuse5, но никак не убивать чип, из которого сигнатура теперь не читается. Linux Ubuntu 10.04 - VirtualBox 3.1.6 - WinXP SP2 Полноценной проверки не получилось, программатор подключился на COM16, после его вытыкания и повторного втыкания он уже не виден системой. Не помогает ни перезагрузка винды, ни тыкание в другие порты USB. Как удалить драйвер программатора вставшего на определенный COM-порт, я не знаю. Кстати, у FTDI есть специальная утилита, которая вычищает все свои установленные драйвера. Вот бы неплохо и здесь подобную утилиту иметь. Кстати, физически чипсет на этой машине - Intel, но виртуалбоксу это видимо не особо интересно - прошивание программатора в этой конфигурации не работает. И здесь возникает второе пожелание - возможно ли утилиту перепрошивки перевести на кроссплатформенные рельсы? Это было бы очень здорово, не зависеть от Windows... WinXP SP3 чипсет SiS Программатор встал на COM16, перетыкается нормально, не пропадает. При попытке прошивания xmega32a4 умирает на jtagmkii_open_pdi(), не может открыть порт (can't set com-state). Попытка перевода программатора на COM1 - то же самое. ATmega168PA шьется без проблем (все то же самое - avrdude COM1 jtag2pdi). WinXP SP2 чипсет Intel Программатор встал на COM6, перетыкается нормально, не пропадает. При попытке прошивания xmega32a4 ошибка как и в чистом Линуксе - "jtagmkII_program_enable(): bad response to enter progmode command: RSP_FAILED" и пр. ATmega168PA шьется без проблем.
  13. ucGoZilla

    Завтра проверю, но 3-й комп был просто третьим по счету, в тот момент я еще не знал о том, что нужно искать именно чипсет Intel. Первым был VirtualBox с виндой из-под Линукса, второй комп с родной виндой, вроде с чипсетом VIA, завтра уточню, все проверю и отпишусь. А это как-то связано с fuse5 в ATxmega32A4? У меня камень "умирает" как раз после его прошивания.
  14. ucGoZilla

    Здравствуйте! Вопрос может не совсем в тему. Имею обсуждаемый программатор, работает хорошо. За что большое спасибо автору :) Прошить его удалось только на 3-ем компе, с чипсетом Intel. Теперь собственно сам вопрос. Прошиваю ATxmega32A4 в режиме mkII (Ubuntu Linux 10.10 - avrdude - jtag2pdi). Проблема возникает при программировании фьюзов. Если я шью такой командой: avrdude -c jtag2pdi -P /dev/ttyACM0 -p x32a4 -U fuse0:w:0x00:m -U fuse1:w:0x00:m -U fuse2:w:0xFF:m -U fuse4:w:0xFE:m то все в порядке: avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.02s avrdude: Device signature = 0x1e9541 avrdude: reading input file "0x00" avrdude: writing fuse0 (1 bytes): Writing | ################################################## | 100% 0.00s avrdude: 1 bytes of fuse0 written avrdude: verifying fuse0 memory against 0x00: avrdude: load data fuse0 data from input file 0x00: avrdude: input file 0x00 contains 1 bytes avrdude: reading on-chip fuse0 data: Reading | ################################################## | 100% 0.01s avrdude: verifying ... avrdude: 1 bytes of fuse0 verified avrdude: reading input file "0x00" avrdude: writing fuse1 (1 bytes): Writing | ################################################## | 100% 0.00s avrdude: 1 bytes of fuse1 written avrdude: verifying fuse1 memory against 0x00: avrdude: load data fuse1 data from input file 0x00: avrdude: input file 0x00 contains 1 bytes avrdude: reading on-chip fuse1 data: Reading | ################################################## | 100% 0.01s avrdude: verifying ... avrdude: 1 bytes of fuse1 verified avrdude: reading input file "0xFF" avrdude: writing fuse2 (1 bytes): Writing | ################################################## | 100% 0.00s avrdude: 1 bytes of fuse2 written avrdude: verifying fuse2 memory against 0xFF: avrdude: load data fuse2 data from input file 0xFF: avrdude: input file 0xFF contains 1 bytes avrdude: reading on-chip fuse2 data: Reading | ################################################## | 100% 0.01s avrdude: verifying ... avrdude: 1 bytes of fuse2 verified avrdude: reading input file "0xFE" avrdude: writing fuse4 (1 bytes): Writing | ################################################## | 100% 0.00s avrdude: 1 bytes of fuse4 written avrdude: verifying fuse4 memory against 0xFE: avrdude: load data fuse4 data from input file 0xFE: avrdude: input file 0xFE contains 1 bytes avrdude: reading on-chip fuse4 data: Reading | ################################################## | 100% 0.01s avrdude: verifying ... avrdude: 1 bytes of fuse4 verified avrdude done. Thank you. Как только добавляю к команде 5-ый фьюз: avrdude -c jtag2pdi -P /dev/ttyACM0 -p x32a4 -U fuse0:w:0x00:m -U fuse1:w:0x00:m -U fuse2:w:0xFF:m -U fuse4:w:0xFE:m -U fuse5:w:0xF0:m получаю вот такой вывод ошибки в конце: avrdude: reading input file "0xF0" avrdude: writing fuse5 (1 bytes): Writing | ################################################## | 100% 0.01s avrdude: 1 bytes of fuse5 written avrdude: verifying fuse5 memory against 0xF0: avrdude: load data fuse5 data from input file 0xF0: avrdude: input file 0xF0 contains 1 bytes avrdude: reading on-chip fuse5 data: Reading | | 0% 0.00savrdude: jtagmkII_read_byte(): bad response to read memory command: RSP_FAILED avr_read(): error reading address 0x0000 read operation not supported for memory "fuse5" avrdude: failed to read all of fuse5 memory, rc=-2 avrdude done. Thank you. И после этого любая команда дает ошибку: avrdude: AVR device initialized and ready to accept instructions Reading | | 0% 0.00savrdude: jtagmkII_program_enable(): bad response to enter progmode command: RSP_FAILED avrdude: jtagmkII_program_enable(): bad response to enter progmode command: RSP_FAILED avrdude: jtagmkII_read_byte(): bad response to read memory command: RSP_ILLEGAL_MCU_STATE avr_read(): error reading address 0x0000 read operation not supported for memory "signature" avrdude: error reading signature data for part "ATXMEGA32A4", rc=-2 avrdude: error reading signature data, rc=-1 avrdude: jtagmkII_program_disable(): bad response to leave progmode command: RSP_ILLEGAL_MCU_STATE avrdude done. Thank you. В чем может быть дело? Микросхему можно заменить, но это не выход (уже менял, все шьется до 5-го фьюза, затем вышеописанный ступор). Версия avrdude 5.10, в программаторе последняя прошивка (заливал в него 110427). Сам программатор исправен, другие МК прошивает, как xmega, так и mega. Помогите советом, направьте мысль в нужное русло :)
  15. aaarrr, спасибо за наводку! Действительно, программа вылетала из процедуры раньше, чем нужно, а не зависала в ней, как я предполагал. Связано это с параметром FMCN_FOR_LOCK. Я измерил время, в течение которого процедура ожидает флагов, результаты такие получились: FMCN_FOR_LOCK = 5, t = 1 ms, сбой FMCN_FOR_LOCK = 48, t = 10 ms, норм Примерно та же картина и при записи страниц наблюдается: FMCN_FOR_WRITE = 72, t = 6 ms, сбой FMCN_FOR_WRITE = 720, t = 18 ms, норм Master Clock = 48 MHz, и почему приходится применять такие большие значения, я так и не понял. В даташите сказано: • FMCN: Flash Microsecond Cycle Number Before writing Lock bits, this field must be set to the number of Master Clock cycles in one hundred nanoseconds. When writing the rest of the Flash, this field defines the number of Master Clock cycles in 1.5 microseconds. This number must be rounded up. В итоге, если не обращать внимания на большие значения FMCN, все работает нормально. P.S. Про прерывания полностью согласен, так и сделал. Еще раз, большое спасибо! :)
×
×
  • Создать...