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

А неужели никто не сталкивался с этой проблемой 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, указанных явно, в маркировке не попадалось

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