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

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

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

Откуда дровишки?!

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


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

кабель?

Partial (Less than 512 bytes) Flash Programming

Увы , думаю, что нет. Сталкивался с подобными вещами . Была партия 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

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

Насколько я понял - проблема не в искажении данных при их передаче через интерфейс связи - а проблемы в "качестве Flash" (условно).
Я на данный момент пока что с таким не сталкивался. Были ранее проблемы с глючностью программы, непонятными вылетами в Data и Prefetch Abort в LPC2368, но связано было с проблемой MAM в ранних ревизиях чипов. Описываемого эффекта не наблюдал (пока?).
По поводу способа заливки софта (JTAG, ISP, IAP). Если я правильно понимаю, то во всех случаях используется встроенный IAP, разница только в способе (и интерфейсе) передачи данных для записи Flash. Тем не менее, если настройки для IAP в собственном загрузчике выполнены корректно, то разница в "качестве записи" между собственным IAP и JTAG мне не понятна.

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

Устойчиво программируем LPC2138 десятками тысяч.

Верю, но тем не менее

Вот подробный пример программирования FLASH для LPC21xx.
Взято в своё время с сахары.ру
Обращаю внимание, что этот пример - для компилятора CrossStudio v1.4 Build 5,
поэтому для иара и кейла не годится.

При программировании прошивки через UART/RS232 важно иметь:
1) корректный преобразователь уровней RS232 с крутыми фронтами;
2) стабильное напряжение питания +3.3v на LPC21xx
3) указывать правильную входную тактовую частоту, которая по документации должна быть в пределах 10МГц...25МГц.
Автор темы указывает 72МГц - чего быть не должно.

Если вызывать IAP при включенном PLL, то 72 МГц вполне допустимо. Другое дело, что встроенный bootloader после ресета работает при выключенном PLL и для него допустимо 10..25 МГц.

Да, когда-до на что-то старое типа LPC2114, помнится, была errata по недопущению использования, PLL. У "современных" такого нет. Лично у меня PLL настройки вычитываюся прямо из регистров при задании частоты. В неизвесности только частота кварца, но она уменя всегда одна и та-же. Кроме того, указывать частоты повыше реальных, полагаю, безобидно

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

у меня тут другое выяснилось, я обнаружил, что параметр частоты требуется передавать в килогерцах, а не в герцах на это грешу, исправил, теперь пока что идет набор статистики

Ничего полезного здесь не написано. А первичный бутлодер не вызвать из вторичного, кроме как общим сбросом. А вот IAP можно вызывать, у него есть "точка входа".


Интересно у zltigo что тогда было

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

В том то и дело, что не про программирование, а про чтение/исполнение кода.

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

Было и есть Сейчас на стенде один заторможенный контроллер в работе. Экспериментов пока никаих дополнительно не делал - не до этого.