У Philips ARM LPC2131 (возможно и у других из этой серии) последней модификации (-
1. Не работает аппаратный I2C - I2C0
2. Ножки на которые выведены сигналы I2C в режиме GPIO остаются с открытым стоком
3. Не работает часовой генератор в режиме тактирования от внешнего кварца

У предыдущей модификации (-A) таких багов не было.

Странно,безумно... Ну что сказать, автор первоначального вопроса жаловался на "B" ревизию, так вот - ревизии '-', 'B', 'C' работают - лично проверял - исполлюзуется всегда и везде у меня для конфигурационного EEPROM. Насчет 'D' - не уверен, надо посмомотреть, может уже где в образцах и стоят.

Для 'B' уже нет.

Уже писалось - там абсолютно документированный OD. Используется, например, под светодиоды без проблем. Подтягивается чем-нибудь типа 3.3K тоже без проблем. О том, что 0.21 вообще к I2C ни сном ни духом вообще помолчу.... Короче - не собирайте слухи

Так вот C работает а D нет. Щас попробуем запоять ревизию D на старую плату, которая вроде как работала, чтобы точно узнать в плате проблема или в проце

понятно,ну рискнем. у меня lpc2131/01 rev.C
А еще вопрос по SPI. Если noga SSEL0 сконфигурирована, как GPIO выход или ШИМ-выход,то SPI будет в мастере пахать или нет? в доке не нашел

Те, получаетсь, как бы нибыло,а ноги P0.11, P0.14 всегда OC-выходы?
Просто вводит в заблуждение


Ничего не написано о том,что если пина скофигурена,как GPIO, она все равно OC

Будет раз в доке не нашли, значит будет Для старых было документированное ограничение.

Да. Прочитайте примечание - там все написано. Заодно, там и про 400KHz (фронты другие) написано...





Независимо от результата перепайки , сообщаю - добрался до железа, оказалось давно уже имею LPC2138 "D" ревизии выпуска 27 недели 2007 года с работающим без всяких проблем I2C0. Посему, свой список могу рассширить - ревизии '-', 'B', 'C', 'D' работают - лично проверял.

Сообщение отредактировал zltigo - Feb 22 2008, 10:34

- Это радует.

Действительно,спасибо!

А с STR911FAW42,44 STR911FAМ42,44 никто не работал?
Как оно в плане багов?

или может лучше уже сразу Кортекс STM32F103xx ?

Много, но правят, но документация очень так себе. http://aly.ogmis.lt/

А, простите, что они общего имеют? ну кроме букв ST в названии.

ничего, совсем другая архитектура.. по описанию довольно неплохо. правда периферия беднее

Ниша применения совсем другая, нежели у ARM9. Соrtex-M, коим является STM32F103 есть простой периферийный контроллер, который никак не может претендовать на замену ARM9. Предназначен в прервую очередь потягаться с младшими ARM7.

Если выберете STM, вам придется скорее всего использовать несколько другие средства отладки и прошивки, далеко не все железо умеет работать с CORTEX-M3. Правда аппартная поддержка отладки и трейс намного лучше чем и у ARM7 и у ARM9 ( поддержка со стророны софта есть в KEIL например).
И кстати компилеры тоже, официального GCC пока еще нет. IAR плохой код генерирует, но терпимо. Остается родной ARM компилер в варианте для KEIL или RVDS.

Пересмотрел доки,да, действительно слабовато..
Посмотрел эрраты. у атмела вроде наименее глючные чипы.. По крайней мере с at91rm9200 проблем небыло

Чипы, между прочим, хоть и ARM9, но заметно отличаются по наворотам. 9200 из первых простых девяток. На сегодняшний день весьма стар.





Да? И какое не умеет? Вот, например,более, чем распространенный http://segger.com/jlink.html
На Keil c его отладчиком тоже никто не жаловался...

Шутка такая "официальный GCC", да? Ну GCC уже вполне распространен http://www.raisonance.com

5.11 вполне нормальный код.

Wiggler + H-JTAG не поддерживает, MT-Link не пподдерживает, ULINK нужен новый 2 или ME.


Кстати у STM да и вообще Coretx-M3 похоже нет и не будет защиты прошивки

Ну и господь с этими Wiggler, если не поддерживает. Давно уже сколь-нибудь нормально НИ С ЧЕМ не работает. Меня его судьба совсем перестала волновать года 3-4 назад.

MT-Link есть клон J-Link и он поддерживает. Я же ссылочку давал:
Any ARM7/ARM9 core (including thumb mode) and Cortex M3 including SWD supported

Информация выдаваемая Вами становится все чудесатее и чудесатее. Защита, естественно, есть:
http://www.st.com/stonline/products/literature/pm/13259.pdf

Да это я не дочитал.
Про защиту конечно видел, но видел и что доступ дебагеру остается, но вот что в режиме отладке доступ к флеше отсутсвует не дочитал. Вопрос тогда что считается режимом отладки?
А кстати это проверяли? Если в рам загрузить прогу и запустить?
Или загрузить в рам, а потом поменять BOOTMODE на старт из рам и перегрузить проц, отключив дебагер?