Ошибки записи FLASH через IAP Опции

[sergik_vrn]

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

[GetSmart]

Версия №1
Неправильно указывается частота SYSCLK при вызове IAP. Точнее в IAP передаётся заниженная частота, а на самом деле SYSCLK выше.

[sergik_vrn]

Версия №1
Неправильно указывается частота SYSCLK при вызове IAP. Точнее в IAP передаётся заниженная частота, а на самом деле SYSCLK выше.

указываю 72MHz, что в моем понимании и есть SYSCLK.
На эту тему были подозрения, но вроде как все правильно. Может, ему на всякий случай чуток завышенную частоту передать, 75МHz скажем? скорость записи не является принципиальным вопросом

Я где-то слышал, что в микроконтроллерах LPC для флэш есть ограничение: в каждый 512-байтовый ряд можно дописывать не более 16 раз (пачками, кратными 16 байт). Если число записей больше, то позже могут быть сбои при чтении. У Вас это ограничение не нарушается?

перед каждой записью чипа производится его очистка через SBI

Код

void erase_user_flash()
{
    prepare_sector(USER_START_SECTOR, MAX_USER_SECTOR);
    erase_sector(USER_START_SECTOR, MAX_USER_SECTOR);
    check_result();
}

[shahr]

кабель?

[zltigo]

кабель?

Увы , думаю, что нет. Сталкивался с подобными вещами . Была партия LPC2148, в которй не все чипы через IAP не записывались с первого раза, точнее так, после такой записи была неустйчивая работа - пред запуском загрузчик проверял CRC и вылезала ошибка. Явное тяготение всего к нескольким вариантам ошибки CRC. Иногда запускалось и в работу. Перезапись несколько раз приводила все "в норму" разбираться было некогда, под руками замены небыло. Десяток ушел на объект, ни с ними, ни с оставшимися на стенде проблем в работе нет. Дело с год назад, ревизий, и прочего не помню.
Сейчас есть два LPC2138 чипа, причем из разных партий, но довольно старые, но уже 'D' - из запаса для макетных работ. Там ситуация совершенно такая-же, только никакими перезаписями стабильной работы не добиться. Экспромтом увеличил waitstates со штатных 3, до 5 и все "заработало". Устойство в отладке - перезапись десятки раз в день. Через неделю опять начало сбоить. Поставил 6ws - "заработало". Дошли руки, чип был перепаян - все, как и положено заработало на 3ws. Был собран второй экземпляр, чип из другой партии - на пару месяцев позже. Опять та-же история, только много много реже сбои и 4ws ему помогли сразу и навсегда. В плотной работе месяц. Естественно, при этом все пляски с MAM были испробованы - влияет только ws. Несколько офигеваю. Сам загрузчик (8K)на свою сумму не ругается никогда. На блок памяти рсположенный сразу просле загрузчика размером под 256К - ругается редко. А вот на данные в старших блоках, практически всегда. При этом, как и в первом случае ошибки CRC не ссовсем произвольные - повторяются несколько вариантов.
Подобный звоночек был от серийного производителя (совершенно другое изделие, но LPC21x8)- один экземпляр точно так-же не загрузчик ругался. Заменили чип. Появилась новая мысль, может действительно попробовать через JTAG залить и посмотреть на результат. Выберу минутку - сделаю.
P.S.
Глючный чип не выбросил, могу предоставить, как информацию по дате выпуска, так и сам чип, нежели, это shahr интересно.
P.P.S.
Чипы всегда покупались в MT-System