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





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

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

Сообщение отредактировал HARMHARM - Sep 20 2007, 07:21

Не знаю, не знаю, над чем или кем этот "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 этот вопрос усилинно муссировался где-то в мае.