LPC23xx. Опубликован новый errata, с багами Flash и MAM Опции

[Andy Mozzhevilov]

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

[Andy Mozzhevilov]

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

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

[Abo]

Сделал, был счастлив до сегодня. Сегодня получил и с MAMCR=1 аналогичные глюки.
Ушел на MAM=0, глюки исчезли. Но с MAM=0 это же не жизнь совсем, когда ядро на 60МГц молотит.

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

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

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

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

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

[Andy Mozzhevilov]

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

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

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

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

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

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

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

[OVladimir]

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

[zltigo]

А неужели никто не сталкивался с этой проблемой MAM?

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

[sensor_ua]

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

[Andy Mozzhevilov]

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

Заметьте, что для 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 больше
аналогичных глюков не наблюдал.

[zltigo]

Может у меня datasheet старый:
Date:June 16, 2006

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

Under certain conditions in MAM Mode 2 code execution out of internal Flash can fail.
Introduction: The MAM block maximizes the performance of the ARM processor when it is running code in Flash memory. It includes three 128-bit buffers called the Prefetch Buffer, the Branch Trail Buffer and the data buffer. It can operate in 3 modes; Mode 0 (MAM off), Mode 1 (MAM partially enabled) and Mode 2 (MAM fully enabled).
Problem:Under certain conditions when the MAM is fully enabled (Mode 2) code execution from internal Flash can fail. The conditions under which the problem can occur is dependent on the code itself along with its positioning within the Flash memory.
Workaround: If the above problem is encountered then Mode 2 should not be used. Instead, partially enable the MAM using Mode 1.

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

[Andy Mozzhevilov]

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

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

[zltigo]

Можно ссылку или сюда выложить?

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

[Andy Mozzhevilov]

Все документы на все чипы берутся тут:

Спасибо за ссылку.
Теперь внимательно изучаем смысл документа.
Эти м...ки при попытке коррекции фичи 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 не уверен что выпускаются, да и как их заказывать.
Мля, трындец. Это серьезно.

[3.14]

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

[sensor_ua]

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

[3.14]

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

[Andy Mozzhevilov]

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

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

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

[3.14]

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

[sensor_ua]

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

[Andy Mozzhevilov]

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

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





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

[zltigo]

что получили фичу MAM.2 в ревизиях C и D.
Если для обхода MAM.1 рекомендовалось включить MAMCR = 2,
то теперь для обхода MAM.2 рекомендуются включить MAMCR = 1,

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

[Цырен]

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

[Andy Mozzhevilov]

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

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

[zltigo]

Все критические настройки можно сделать в low_level_init

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

[Andy Mozzhevilov]

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

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

[Цырен]

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

[HARMHARM]

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

(1) Due to the MAM fix and User Manual Update, CCO divider with
the odd number for CCLK is no longer allowed. Update PLL setting
example accordingly.

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

MAM.1: Under certain conditions in MAM Mode 2 code execution out of internal Flash can fail.Introduction: The MAM block maximizes the performance of the ARM processor when it is running code in Flash memory. It includes three 128-bit buffers called the Prefetch Buffer, the Branch Trail Buffer and the data buffer. It can operate in 3 modes; Mode 0 (MAM off), Mode 1 (MAM partially enabled) and Mode 2 (MAM fully enabled).Problem:Under certain conditions when the MAM is fully enabled (Mode 2) code execution from internal Flash can fail. The conditions under which the problem can occur is dependent on the code itself along with its positioning within the Flash memory. Workaround: If the above problem is encountered then Mode 2 should not be used. Instead, partially enable the MAM using Mode 1.

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

[zltigo]

при установке нечетного CCO divider

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

[Andy Mozzhevilov]

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

у меня

Код

        PLLCFG = (72-1) | ((5-1) << 16);   /* FCCO = 288 MHz */

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


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

Код

        CCLKCFG = (5-1);                  /* Set clock divider */

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

[zltigo]

Но проверить все же стоит

Ждем.

[HARMHARM]

У меня сделано

Код

        CCLKCFG = (5-1);                  /* Set clock divider */

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

[Andy Mozzhevilov]

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

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

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

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

[HARMHARM]

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

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

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

[zltigo]

тестовый проект для издевательств над MAM (под GCC), прилагаю.

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

[HARMHARM]

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

[Velund]

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

[zltigo]

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

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

[shahr]

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

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

[Andy Mozzhevilov]

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

[zltigo]

можно забыть.

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

[Alechek]

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

[zltigo]

Со второй попытки то должно считаться!

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

Код

code execution from internal Flash can fail.

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

[Alechek]

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

[zltigo]

Правда это было Полтора года назад...

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

[Alechek]

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

LPC2148 Erratasheet 1.6

Код

Functional Problem Short Description                 Errata occurs in device revision
MAM.1              Incorrect read of data from SRAM                   -
MAM.2              Code execution failure can occur with MAM Mode 2   -, A

[Andy Mozzhevilov]

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

LPC2148 Erratasheet 1.6

Код

Functional Problem Short Description                 Errata occurs in device revision
MAM.1              Incorrect read of data from SRAM                   -
MAM.2              Code execution failure can occur with MAM Mode 2   -, A

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

[zltigo]

Потом филипки подправили errata так, что типа "ой, этот баг был и везде в других ревизиях, просто не обнаруживался".

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

[ГУ-49А]

Изучаю доку на LPC23XX.
Не понятно с досупом к флешке.
Смутило меня следующее :Насколько я понимаю, во избежание циклов ожидания надо иметь один такт доступа до флешки (128 бит) к четырем тактам ядра, тогда зачем усложнять ... мксаимальная частота 72М -> указывать MAMTIM=4 и в путь, и зачем задается по умолчанию MAMTIM=7 ?

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

[zltigo]

(MAM=2, MAMTIM=3, частота 70 MHz (10x7))

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

[StupidGuru]

Недавно столкнулся со "знаменитым" глюком MAM'а на одном из своих LPC2103 (MAM=2, MAMTIM=3, частота 70 MHz (10x7)).

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

[ГУ-49А]

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

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

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

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

[brag]

сижу,читаю,и вспомнил,что когда-то,года 3 на зад у меня были непонятные prefetch і data abortы в LPC2106... Видимо тоже на это натыкался..не помню конкретно,что делал, помню, только, что были пляски с бубном,типа втыкал куда-то(не помню куда) инструкцции типа, mov r0,r0
Помню точно,что мам был 2 и частота 75мгц(немного оверклокнул)

[StupidGuru]

Цитата из manual для 2103: "while in systems with system clock faster than 40 MHz, 3 CCLKs are proposed.",

Ну дык! У них же документация постоянно кривая, а точнее древняя, унаследованная от предшественников типа LPC2104..6 или LPC213x, у которых рабочая частота была официально ограничена 60 МГц. Поэтому там стоит циферка 3. А на самом деле должна быть 4. Так что это не бага. А вот почему на 4-ех тоже глючит, а на 5 уже нет - это вопрос интересный.

[zltigo]

Ну дык! У них же документация постоянно кривая...

Тем не меннее для всех, в том числе и 72MHz моделей в документации уже много лет указывается всего 3ws и работает, хотя с точки зрения "здравого смысла" продолжая ряд ws должно быть 4ws после 60 MHz. Это если 50ns FLASH, а если, например 45ns или чуть поменее?

[brag]

ну если учитывать,что все(почти) можно разогнать, то должно и на 3 работать.. я не помню уже, у меня вроде даже на 2 заводилось на 60мгц.давно дело было

[zltigo]

ну если учитывать,что все(почти) можно разогнать

Ну явно разгонять это последнее дело. Не стоит.

[meister]

Это если 50ns FLASH, а если, например 45ns или чуть поменее?

Где можно посмотреть время доступа к флэш? В даташите и юзермануале нету.

[zltigo]

Где можно посмотреть время доступа к флэш? В даташите и юзермануале нету.

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