sergik_vrn

Вынул тут из загашника хз когда купленный имитатор JTAG ICE, на COM-порт. подключили его к AT90CAN, шить пытаюсь с помощью IAR. Версия 3.х и 4.х видеть его отказываются, точнее, говорят, device not supported, а версия 5.11 видит, работает нормально, запускает отладчик, встает на нужный адрес, регистры и порты пишет, но вот содержимое flash не меняет, хотя пишет что downloading, и светодиод желтенький моргает. В какую сторону посоветуете рыть?

если устройство работает недолго, нужен ли ему буфер такого размера? справится ли dataflash по скорости? зачем вообще нужно хранение данных в энергонезависимой памяти, и не будет ли это из пушки по воробьям? или могут возникать сбои питания? если нужен буфер большого размера, почему именно SDRAM, а не SRАM например?

если Вам надо поместить массив по конкретному, заранее известному адресу, можно пользоваться директивой @ address, static const unsigned char NAME[200] @ 0xFFFFFFF; если же просто надо выровнять границу, то можно положить массив в блок с установленным выравниванием в конфиге линкера, например -- .icf --- define block USB_RAM with alignment = 16 { readwrite section USB_DMA_RAM }; -- .c --- static const unsigned char NAME[200] @ "USB_DMA_RAM";

Вашу мысль я понял, но кроме упомянутой фразы про исполнение кода о флеше больше ни слова :( Ладно, посмотрим что покажут испытания, хотя работоспособность/неработоспособность IAP при таких ошибках мне не совсем понятна. Если там тупо от частоты считаются циклы задержки, то ошибка в 1000 раз дала бы соответствующее ухудшение производительности, а если механизм другой, то вообще непонятно, как все это должно работать...

ну я IAP и имел в виду, разумеется. понятно, что ничего полезного, просто про флеш, тем более про его программирование, более нигде ничего вообще не написано :(

работа идет во вторичном бут-лоадере, перед обращением к функциям первичного устанавливается PLL и включается частота 72MHz. Нигде в документации на 2478 запрета не нашел, а в разделе Introductory написано: у меня тут другое выяснилось, я обнаружил, что параметр частоты требуется передавать в килогерцах, а не в герцах :) на это грешу, исправил, теперь пока что идет набор статистики

мысли аналогичные. может быть, стоит еще раз сверить настройки... какие они вообще нужны для внутреннего IAP, кроме SYSCLK, конечно?

этот вопрос все равно сводится к достаточности CRC16 для отслеживания возникающих ошибок связи. должен отметить, что подобная же прошивалка используется для записи STR710, там ни разу сбоев не наблюдалось...

указываю 72MHz, что в моем понимании и есть SYSCLK. На эту тему были подозрения, но вроде как все правильно. Может, ему на всякий случай чуток завышенную частоту передать, 75МHz скажем? скорость записи не является принципиальным вопросом перед каждой записью чипа производится его очистка через SBI void erase_user_flash() { prepare_sector(USER_START_SECTOR, MAX_USER_SECTOR); erase_sector(USER_START_SECTOR, MAX_USER_SECTOR); check_result(); }

Процессор LPC2478, загрузчик по ком-порту, все замечательно работает за исключением того, что иногда при верификации записанных данных появляются ошибки. Скажем, на 20 записей прошивки размером ~400k один раз возникает ошибка в одном бите (условно говоря, 0x49 вместо 0x4B) в произвольном месте памяти. При этом иногда даже верифицированная прошивка иногда подглюкивает. Когда пишу через j-tag, проблем не возникает, и в переписанной прошивке глюки пропадают сами собой. Процедура обмена по ком-порту использует блоки размером 1К, проверка CRC 16 На что грешить не знаю, может ли быть, что CRC-16 не покажет ошибку в подобной ситуации? Или может кто-то сталкивался с подобными проблемами в филипсовских процах?

если Вы используете указатель, никакой компилятор за Вас его инициализировать не станет. поэтому либо объявляйте статическую структуру в EEPROM, и работайте с ней, либо инициализируйте указатель сами, но тогда имейте в виду, что компилятор под эту структуру память сам выделять не будет (распределение памяти ложится целиком на Вас)

очередной глюк с data abort в отлаженном коде, при вызове виртуального метода. на этот раз с оптимизацией по скорости. полдня убил, лечится, как обычно, снижением уровня оптимизации в конкретной функции. Чувствую, откачусь я на 4.41, мне такие сюрпризы все нервы съедят :(

попробовал собрать проект с оптимизацией по скорости. размер вырос со 130К до 170К, глюки с data_abort в отлаженном коде пропали. Пока работаю так, дальше посмотрим

сами понимаете, просто так "взять следующий камень" не так просто, как хотелось бы, при серийном производстве. впрочем, 2478 тьфу-тьфу пока по этим параметрам не напрягает, речь была про STR710, а он-таки самый жирный в линейке. насчет предложенного способа - спасибо, попробую, как только образуется дыра в расписании. щас вот бьюсь, в другом месте вылезли глюки в многократно отлаженном на разных процессорах коде :( уже подумываю откатиться на 4.41 :(

попробую при случае. причина такого выбора метода оптимизации проста, проект здоровый, в самом большом варианте еле-еле помещается в ПЗУ контроллера. А разная компиляция - разные глюки :( Впрочем, надо будет попробовать все равно