а я уже успел пройтись по этим граблям.
Спасибо тебе Филипс за наше счастливое детство :-)

А неужели никто не сталкивался с этой проблемой MAM?
У меня выглядит это так в большинстве случаев.
Запускаю прогу, и она падает в data или prefetch abort.
Начинаю выяснять, откуда упала, нахожу адрес, ставлю до этого адреса брейкпоинт.
Запускаю снова, прога останавливает на брейкпоинте.
Дальше- если сделать RUN, то падаем в аборт.
Если пройти участок кода в отладчике пошагово, то все выполняется верно.
Поведение зависит, от того, что там неверно извлекается из флэш. Может упасть в аборт,
может просто неверно провести какие-то операции.
Так вот, вчера несколько походил по эти граблям, экспериментально и интуитивно начал играть с
настройками MAM. Помогло. Потом скачал свежую errata. Там рекомендовано делать MAMCR=1.
Сделал, был счастлив до сегодня. Сегодня получил и с MAMCR=1 аналогичные глюки.
Ушел на MAM=0, глюки исчезли. Но с MAM=0 это же не жизнь совсем, когда ядро на 60МГц молотит.

Столкнулся с тем же поведением.
Понижал тактовую аж до 42МГц. Помогало, но не всегда.
Решил померять напряжение питания ядра которое дает внутренний стабилизатор на ноге процессора - оно оказалось 1,5В, если запустить на частоте 60МГц.

На плате сделан отдельный источник 1,8В, подключил его. Проц стал работать стабильнее, мог работать даже на частоте 60МГц. Но все равно, нет нет да и выпрыгнет в аборт.

Вобщем затрахался я с этим чудом вражеской техники и решил отложить пока на пару месяцев в надежде на то что в будущем прояснится.

Но все же терзают меня смутные сомнения, что руки кривые. Ведь у starterkit.ru работает же.
Да и кейловская борда тоже по отзывам вроде фунциклирует.

Вобщем, ступор какой то.
Может вместе чего нароем?

Аборт аборту рознь. Нужно разбитаться в каждом конкретном случае.
В моем случае достаточно стабильно глючило и одинаково в пределах варианта сборки проекта.
Видимо, как карта ляжет. Также сборка проекта глючила на разных камнях одинаково.


Для начала нужно учесть известные баги, того же МАМ, а потом дальше разбираться.

У меня LPC2364 тоже выпрыгивал в дата аборт (48МГц), не стал глубоко копать, "отключил" МАМ и повысил до 64 МГц, с тех пор ни разу не видел дата аборт (звучит странно, но на 48МГц без МАМ "прыжки" наблюдались).
А вообще NXP как-то нам сказали что эту семью пока не будут продавать из-за множества ошибок (может это они только нам не будут).

Эту проблему они запихнули во все errata! Поскольку остальные чипы используются уже много лет, то пожалуй глюк действительно редчайший. В многочисленных проектах на 2124-2138-2148-2294 чипах необоснованных падений не наблюдал ни разу. Скорее всего и у Вас причина не MAM 2.

На днях запускал плату на LPC2378 - тоже какие-то падения и т.п. как-будто были. Осмотрелся и нашёл - кварц в конфиге в 4 раза отличалсяот реального, джампер на RTCK не стоял, ну и какое-то прерывание от часов не запрещал)) Ах, да, и поначалу версия Сеггера была слишком старая, которая просто не знала о 23-й серии 8-D, ну и кайла 3-11-го ещё не было...

Заметьте, что для 2124-2138-2148-2294 и для 23xx проблема, описанная с МАМ
разная. Для 21-22 рекомендуется work-around - включить MAMCR = 2
(оно так и сделано у меня в тех проектах и проблем я не наблюдаю). Причем проблему они относят к ревизиям силикона вплоть до B.
Может у меня datasheet старый:
Date:June 16, 2006
Document Release:
Version 1.6
Device Affected:LPC2138

В 23xx наоборот, рекомендуется частично включить MAM, MAMCR = 1.
Но у меня и с MAMCR = 1 глюки продолжались, пока не перевел его на MAMCR = 0.
В этом уверен, объяснения другого найти не могу. После MAMCR = 0 больше
аналогичных глюков не наблюдал.

Естественно, Вы же писали, что в новый errata внесли, а я ответил, что они на все чипы в новые
errata это внесли.
V1.2 для 2378 от 7 июня,
V1.5 для 2148 от 8 июня,
и
V1.7 для 2138 от 8 июня:



Совпадают полностью, до последней буквы.

Мля. На сайте NXP на видном месте лежит только старый. Поиском находится тоже только 1.6
Можно ссылку или сюда выложить?

Все документы на все чипы берутся тут:
http://www.standardics.nxp.com/products/mc...1&zoom=none

Спасибо за ссылку.
Теперь внимательно изучаем смысл документа.
Эти м...ки при попытке коррекции фичи MAM.1 в ревизии A и B наваляли дохрена так,
что получили фичу MAM.2 в ревизиях C и D.
Если для обхода MAM.1 рекомендовалось включить MAMCR = 2,
то теперь для обхода MAM.2 рекомендуются включить MAMCR = 1,
хотя реально на 2368 у меня и при MAMCR = 1 наблюдались глюки.
то есть реально надо сделать MAMCR = 0.
При этих условиях будет действовать MAM.1 в ревизиях A и B.
MAM.1 судя по описанию достаточно редкая фишка, и лечится наоборот
включением MAM на полную. А вот чтобы наступить на MAM.2 мне, много времени
не понадобилось.
Получаем ситуацию:
Если в проектах на ревизиях A и B юзается MAMCR=2 (а он юзается) а также возможно и MAMCR=1,
то при установке чипов ревизий C и D в те проекты мы огребаем по полной.
Выключая MAM по багу MAM.2 мы теряем в скорости выполения раз до 4-5, это существенно и
в некоторых проектах может быть критичным. То есть использование C и D ревизий в них
становится невозможным, а A и B не уверен что выпускаются, да и как их заказывать.
Мля, трындец. Это серьезно.

Не понял, в еррате от 7 июня нет упоминания о B C D ревизиях ...

Просьба ткнуть в расшифровку версионности. А то таких букв, как A, B, C, D, указанных явно, в маркировке не попадалось

Смотрите третью страницу ...

Ревизии B C D относятся к LPC2138 (ну и все прочие 213x),
Date:June 8 2007
Document Release:Version 1.7
Device Affected:LPC2138

плюс все прочие семейства LPC видимо имеют свою errata на этот счет.
В этом то и заключается особая дерьмоватость ситуации.
Если 2368 чип свеженький, и в новые проекты массово вряд ли у кого то не идет,
то все остальные то трудятся уже давненько. И что теперь с теми проектами делать?

Я поумал Вы про LPC23хх ...
Зачем что-то делать со старывми проектами, которые давно трудятся?

У меня 2378-е с ревизией Y - надпись не попадает в формат со стр.3 -
ZSG0646-Y
Как бы узнать какая эррата на них распространяется?)

И правда зачем? Я бы и не притронулся.
Я пытался объяснить выше суть проблемы.
Короче, во всех ревизиях LPC с добавленной проблемой MAM.2
нельзя исключать ситуации, когда старая работающая программа
в старых проектах на старых чипах перестанет работать.





Кстати, почитал свой архив форума на lpc2000@yahoogroups.com
Там эту проблему начали обсуждать в начале мая.

Да,уж.... Хотя по MAM.1 может MAMCR=2 как-то всуе помянуто .
А MAM.2 это нет слов
Девайсы которые сейчас в отладке на 2138 практически все ревизии 'C' - проблем с падением не наблюдал. Пока в процесе работы буду так испытывать, ну а вообще придется разные bootloader-ы сделать и убрать переинициализацию из основной программы, но потеря производительности это тоскливо очень.

Недавно собрали плату на LPC2364 с ревизией Y. Дата выпуска микроконтроллера - 1-я неделя этого года. Сначала не мог всосать почему мой код виснет в стартапе... Потом подробно наблюдал ассемблерный код...виснет в бесконечном цикле в обработчике data abort! Так собственно вопрос: что же мне настройку MAMRC делать еще до инициализации стэков? Ведь проц входит в состояние DataAbort еще до того, как начнется функция настройки системной периферии.

Все критические настройки можно сделать в low_level_init
Но по ресету MAM выключается. Вряд ли у вас ситуация, связанная с багом MAM.
Посмотрите, откуда он падает в исключение, дальше дело техники найти причину.

Это уже для вызова стек должен быть.

Да, стек есть, но это ничему не мешает.
Потом стек юзается уже в самой low_level_init() если она так написана.
Если ее написать на асме, то можно обойтись без использования стека, но это, имхо,
не нужно, в контексте MAM.2

Эту проблему я подробно описал здесь http://electronix.ru/forum/index.php?showt...970&hl=2364

Пролистывал LPC23xx/24xx Example Software для Keil, и наткнулся на фразу:

В errata для LPC2368 такое описание бага MAM.1:

Не значит ли это, что проблемы с MAM возникали при установке нечетного CCO divider, и про этот баг можно забыть? У кого-нибудь получалось достоверно воспроизвести этот глюк с выпадением в Data Abort? Может быть, стоит провести эксперимент с MAM=2 и нечетным CCOdiv...

Не совсем однозначно можно понять, что кейловцы называют "CCO Divider", но у меня "делитель" записываемый в PLLCFG '1', что с другой строны соответствует делению на 2. Множитель соответственно '3' = 4. Проблем, как уже писал, не наблюдал и не наблюдаю.
Действительно интересно, какие множитель/делитель у тех у кого они есть.

у меня


то есть в делитель записано значение 4, что соответствует делению на 5.
сейчас нет под рукой плат тех устройств, скоро должны подойти, обязательно попробую.


Есть более новая errata от 20 июля, там действительно говорится о том, что нельзя использовать четное значение для регистра CCLKSEL.
У меня сделано

то есть как раз четное.
но в erreta филипсовцы не связали этот баг с МАМ, а добавили его в баг Flash.1
Но проверить все же стоит

Ждем.

А это то значение, при котором возникали проблемы, или новое - найденное путем проб и ошибок?

это пока то, с которым были проблемы





взял устройство на 2368, пока так вот влоб при включении МАМ свалить в аборт его не удалось,
видимо раз на раз не приходится и зависит как там карта в памяти ляжет.
Соответственно нет смысла и пробовать менять делитель тактовой.
Как буду работать в следующий раз с этим устройством, включу МАМ по полной, и как начнет глючить, буду экспериментировать с делителем.

В конференции lpc2000 на yahoo.com накопал тестовый проект для издевательств над MAM (под GCC), прилагаю.
* Ошибся, файл прибит.

Не знаю, не знаю, над чем или кем этот "Hello World" издевается. Ссылку на сообщение дайте.

Похоже я ошибся, файл прибил. Ссылка.

А кто нибудь с ревизией А чипов LPC2368 уже имел дело?

Ну так чем все это кончилось/продолжилось? У меня проблема так и не проявилась.

можно забыть. сейчас отгружается ревизия B, где все проблемы с MAM пофиксены.

На LPC2134 с ревизией С пока проблем не наблюдаем.
На LPC2364 отлаживаю тестовый проектик с USB, пока не проявляется.

Да-уж. "Посоветовали". Напомню, что поминаемый баг описан ДЛЯ ВСЕХ СВЕЖИХ РЕВИЗИЙ LPC2000 и является свежеприобретенным для, например, LPC213x/4x. Я должен в свою очередь производителям своего оборудования посоветовать "забыть", выкинуть наработанное, дождаться (уже с некоторым трепетом ожидая новых проблем) новых ревизий при этом призывая своих заказчиков "забыть" о своем существовании. А куда денут поставщики "неправильные" ревизии? Выкинут в мусорник и "забудут"? Нет, будут продолжать распихивать. В общем "забыть" может позволить себе только NXP - он большой, ему можно. Очень хотелось бы получить от NXP вместо "Under certain conditions..l" что-то более конкретное о возникновении проблемы и соответственно менее "радикальное" решение проблемы, нежели не пользоваться MAM 2, особенно хорошо смотрящимся в сочетании с предыдущим советом не пользоваться MAM 0 и MAM 1 и невозможностью определить ревизию чипа иначе, чем рассматривая литеры на корпусе.

Я вот одного не понял, ну Data Abort, ну не получилось с первого раза флешину считать..
Разве нельзя выйти из Обработчика и продолжить работу дальше? Со второй попытки то должно считаться!

Да? Со второй?
Это кто Вам сообщил условия возникновения и степень повторяемости эффекта ?
Да и Data Abort тут совсем случаен, ибо последствия :

вообще не предсказуемы.

Да, тут я не прав. Data Abort скорей всего случайность.
Вполне может быть и Undefined Instruction.
Я поначалу на этот баг тоже наступал. Правда это было Полтора года назад. JTAG у меня не было, но выяснил, что программа падала после того, как я поторогаю МАМ.
Все устаканилось лишь после того, как я прописал его инициализацию в cstartup.s79, причем сначала устанавливал режим 0, Потом тайминг (3) и режим работы 2.
Точно уже не помню, но вроде если вначале не ставить режим 0, то программа падала.

Полтора года назад этого бага не было. Совсем не было. Это баг появившийся летом этого года, видимо при коррекции старого, почти безобидного бага лечащегося инициализацией MAM до момента доступа к RAM.

С каких пор этот баг является для 214х свежеприобретенным?
считаю что он все-таки свежеобнаруженный.

LPC2148 Erratasheet 1.6

Этот баг явно добавлен при коррекции бага МАМ.1
Явно это прослеживается во всех errata на все LPC.
Потом филипки подправили errata так, что типа "ой, этот баг был и везде в других ревизиях, просто не обнаруживался".
Чушь. Для МАМ.1 и для МАМ.2 даны взаимоисключающие workaround. То есть все прошлые ревизии вообще не должны были работать. А для серии 213х - это ревизии "-", "А", "В". И выпускались они неверное пару лет, а то и более. И вот ведь совпадение, никто этого бага не заметил на них.
А где-то в начале этого года вдруг обнаружился, и на ревизиях именно с коррекцией бага МАМ.1.
В буржуйсной конфе по LPC этот вопрос усилинно муссировался где-то в мае.

Моя память тоже говорит мне именно о таком развитии событий - надо взглянуть на предыдущий V1.5.

Чтоб новую тему не заводить, напишу здесь. Недавно столкнулся со "знаменитым" глюком MAM'а на одном из своих LPC2103 (MAM=2, MAMTIM=3, частота 70 MHz (10x7)). При чтении из флеша (простой ldr) прошивка падала, в строго определённые моменты времени (в другие моменты времени читалось оттуда нормально). Причём, при небольшом изменении кода (последовательности выполнения нескольких команд, не влияющей на вычисления) проблема исчезала (естественно, при отключении MAM тоже всё работало), воспроизводимость 100%. Дык вот, вместо того, чтобы традиционно снизить частоту, уменьшить MAM до 1 или вовсе его отключить, я попробовал увеличивать MAMTIM. Сначала до 4-х. Глюк исчез, но, как оказалось, не полностью: он вылез в другом месте кода. И только когда я установил MAMTIM=5, всё заработало как надо! Так что большие значения MAMTIM иногда приносят пользу. Вот такая история...

Остальные настройки, например PLL? Проверить при четных делителях частоты с PLL сможете?

А разве так можно? 70 МГц / 3 = 23, о скорость флэша вроде всего 20 МГц.

А у меня и так чётный: MSEL=6, PSEL=1 (т.е. div=2), кварц 10 МГц. На других значениях, к сожалению, не пробовал (но, кажется, пробовал вообще без PLL - всё работало).



Цитата из manual для 2103: "while in systems with system clock faster than 40 MHz, 3 CCLKs are proposed.", т.е. если следовать "букве закона", то можно. И, в общем-то, на простых задачах работает, похоже, на пределе. А вот при MAMTIM=5 никаких проблем вообще не замечено. Вообще, есть чувство, что где-то что-то иногда не успевает...