IgorMarx

Батенька, вам учить язык C нужно :), а не на форумах такие вопросы спрашивать. Пардон за банальный совет )

Это flashloader. Правда, моя по I2C, но низкоуровневый модуль заменить - полчаса. Угощайтесь на здоровье ) Если прицепите SPI и выложите здесь же - лучшая благодарность с вашей стороны за мою работу. Забыл добавить - для LPC2138 нужно поправить виртуальный адрес EEPROM (там 0x00020000), иначе он "налазит" на внутреннюю флешь eeprom_LPC2134_test.rar

Я это сделал для IAR. Сейчас бегу на работу - некогда. Могу поделиться. Подоставайте меня через PM, если закручусь...

Именно так. Например, резервируем 7-й сектор: ... define symbol __ICFEDIT_region_ROM_end__ = 0x00006FFF; // Уменьшите здесь адрес так, чтобы не налезал на резервируемые сектора ... define region SETTINGS_region = mem:[from 0x00007000 to 0x00007FFF]; place in SETTINGS_region {readonly section SETTINGS}; do not initialize { section SETTINGS}; ... В Вашей программе на Си: #define SETTINGS _Pragma("location=\"SETTINGS\"") ... SETTINGS const int some_var; // объявление переменной Примерно так (код не тестился, написан на лету)

Я много работаю с этим камнем (причём с ревизией /01), спрашивайте, чем могу, помогу. А если будете отлаживаться в IAR, то вот вам ещё файл, я его исправил: товарищи из IAR выводят на вкладки просмотра регистров всё что попало, совсем не задумываясь о том, что некоторые регистры отладчику считывать не следует (например, FIFO, VicVecAddr и прочее). Вставьте это описание вместо дефолтного в свойствах проекта -> отладка, и вам не придётся испытывать весь тот гемор, который проходит новичок. Тёзка опередил, пока я пост набирал ) Добавление: на этот чип два мануала: UM10114 и UM10120 iolpc2134.zip iolpc2134_fixed.zip

Дошёл до положительного результата, как мне кажется. Раз уж я тут сам с собой общаюсь, то выложу результат. Наверняка кому-нибудь эта информация станет полезной, дабы не тратить чудовищное количество времени. Как написано в user manual на микросхему, для перевода микроконтроллера в режим пониженного энергопотребления, среди прочего, нужно выполнить USBCLKEN = 0; На практике этого совершенно недостаточно. Оказывается, нужно сделать следующее: 1. Подать на шину AHB частоту не менее 30 MHz 2. Подать программно-аппаратный сброс на устройство USB (оказалось, что иначе после пробуждения при попытке обратиться к регистрам USB ядром последнее подвисает, и отвисает, только если на входных линиях что-то дёрнется). 3. Разрешить клок; 4. Разлочить регистры USB; 5. Подать программный сброс через регистр USBMODE; 6. Дождаться бита статуса suspend; 7. Установить бит GOSUSP в USBMODE; 8. Запретить клок. MODE1_7 = 0; MODE0_7 = (1<<0); SetCoreModeeMode60MHz); USBRES = 0; USBRES = 1; USBCLKEN = 1; USBLOCK = 0xAA37; USBMODE = 0x10; USBMODE = 0; while ((USBINTSTAT & (1<<3)) == 0); USBMODE = 0x20; USBCLKEN = 0; SetCoreMode(eMode12MHz); Вот только тогда USB будет реально отключен. Но и это не всё. Не знаю, насколько корректно вешать подтяжки на аналоговые входы USB, но это позволяет спасти ещё примерно микроампер 200. Спасибо всем за поддержку. P.S. Хотелось бы всё же увидеть этот рецепт в юзер мануале на микросхему. Хотя бы в будущих редакциях.

Наберите "also allow for a port pin to be read at any time regardless of its function." в строке поиска гугля.

Потратил день, стараясь добиться ухода в спячку процессора с присланным кодом. Ничего не получается - те же самые 4 mA. Те же изменения тока потребления при изменении потенциала на входах USB контроллера. Один раз чип всё же ушёл в PD, но тот же код перестал работать при перезапуске. В присланном примере не всё ясно: шина AHB программируется на 60 MHz (понятно для чего - на AHB должно быть не менее 30 MHz, чтобы получить доступ к регистрам контроллера USB), а мосты APB - на 32 kHz. Это не даёт топать отладчиком. Явно чего-то не хватает, какие-то условия не выполняются. Достал свой проект, в котором приведённый выше рецепт сработал - уже не срабатывает. Чудеса в решете, впечатление такое, что я не в своём уме: то работает, то нет. Ошибиться сложно, у меня стоит Perforce, я могу после экспериментов всегда откатить код на контрольную точку. Проверял на нашей многослойке. Завтра проверю на Olimex'е, когда попадёт в руки родная Nohau, посмотрю на ней. Пока результат отрицательный.

shahr, да, спасибо, ответ сегодня получил по почте. То, что написано выше, снижает ток потребления до 600 мкА. Посмотрю, как будет работать присланный тестовый код. Насчёт закрытия вопроса в NXP support: пока не удалось успешно повторно усыпить процессор после пробуждения (остаётся 8 мА) - с моим кодом. Там много устройств инициализировано.

Разобрался сам. SetCoreMode(eMode60MHz); USBCLKEN = 1; USBLOCK = 0xAA37; USBTEST = (1 << 4); USBMODE = USBMODE & 0xfe; //clear SOFTCT USBMODE = (USBMODE & 0xfe) | (1<<4); // issue soft reset USBMODE = USBMODE & (0xfe & ~(1<<4)); // remove soft reset for (volatile unsigned i=0; i<60000000UL / 100; i++);// wait at lest 3 ms (we wait more) USBTEST = 0; USBLOCK = 0xAA37; //Issue soft reset USBMODE = (USBMODE & 0xff) | (1<<4); // issue soft reset USBMODE = USBMODE & (0xff & ~(1<<4)); // remove soft reset // wait for suspend interrupt while ((USBINTSTAT & (1<<3)) == 0); USBMODE = (USBMODE & 0xfe) | (1<<5); // GOSUSP USBCLKEN = 0; SetCoreMode(eMode12MHz); Плюс резистор с D- на землю. P.S. Тут есть лишнее.

Сумничали? А что скажете по теме? Извините, если обидел и это не личное, но на этом форуме не придраться просто не могут.

Здравствуйте всем. Делаю проект на LPC2888/01 (корпус BGA 180 с шагом 0.5). Пока было всё "хорошо", но настал момент, когда проц нужно положить спать. Процедура, описанная в юзер мануале, реализована; пины на вывод, внешних нагрузок нет, аналоговые цепи отключены через регистры, осциллятор остановлен, JTAG не подключен и т.п. Камень продолжает потреблять примерно 4 мА, из которых примерно 1,5 через стабилизатор уходит в шину 1.8V. Код, написанный в среде IAR Embedded Workbench, проверен на плате Olimex-H2888 и на плате разрабатываемого устройства, результат одинаковый. Мало того, взят пример из оригинального code bundle от NXP, разработанный для платы Nohau в Keil и доработанный, чтобы уходить в спячку на этих платах, даёт те же результаты. Перерезание дорожек на плате показало, что ток течёт по шинам питания, кормящим встроенный USB. Мало того, подача разных уровней на аналоговые входы немного влияет на ток потребления в этом режиме. Интересные факты: 1. В readme на code bundle написано, что данный проект сгенерирован, но НЕ ТЕСТИРОВАЛСЯ (Ого! Это что же помешало, интересно?) 2. В Интернете нигде нет упоминания о том, чтобы какое-либо батарейное устройство было успешно реализовано на этом чипе; 3. Звонок куратору и написание письма в NXP с просьбой предоставить образец реально работающего кода, уводящего камень в спячку пока остались без ответа. Вопрос в следующем: есть ли кто-либо, имевший дело с процом и добившейся его нормального засыпания?

Это отличное решение для IRQ (главное не забыть запрограммировать VICDefVectAddr, иначе при spurious interrupt поимеем переход на нулевой адрес). Но я не уверен что для FIQ такой номер прокатит. Если мне не изменяет память, то инструкция LDR PC,[PC,#-0xFF0] загружает в PC значение, считанное по адресу PC,#-0xFF0, то есть VICVectAddr, и это хорошо подходит для векторных прерываний. FIQ к ним не относится. Могу ошибаться, поправьте, если я не прав (сам не пробовал). Но вряд ли FIQ понадобятся самому бутлоадеру, можно сделать обычный переход в нужную страницу.

Мне симулятор иногда нужен только когда я отлаживаю какие либо математические алгортмы (например, делал реализацю AES для бутлоадера), или когда есть необходимость посчитать временные задержки (если симулятор позволяет подсчёт тактов проца). JTAG рулит, однозначно. Без него тяжело. Можно, но геморно.

Ну, это Вы сумничали :) Кстати, о птичках. В примерах можно часто видеть конструкции вида <regisetr>_bit.<битовое поле> = <ещё что-нибудь> (предполагается, что будет считан регистр, потом его битовое поле замененио новым значением и записано обратно в регистр). В опять - же в документации написано, что при чтении некоторых битов этого регистра можно получит неопределённые значения, но писать в эти биты единицы ни в коемь случае нельзя. То есть, биты, не входящие в <битовое поле>, могут наделать вам неприятносте.