Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Проблема с USB на lpc1756
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
bseyur
Здравствуйте, уважаемые!

Столкнулся вот с какой проблемой... При первой загрузке контроллера после подачи питания на LPC1756 не заводится USB. Компьютер при этом не только не определяет устройство, но и не видит его. После многочисленных экспериментов обнаружилось, что это происходит при определенных настройках штатного "ускорителя" флешки.
В общем случае параметры тактирования процессора у меня читаются из специальной структуры, но ради эксперимента прописываю настройки жестко:

FLASHCFG = (2<<12); -- вот в этом случае USB работает прекрасно

FLASHCFG = (5<<12); -- на "безопасных" настройках USB также работает

FLASHCFG = (3<<12); -- а вот в этом случае USB не работает...
FLASHCFG = (4<<12); -- аналогично...

Тактовая ядра 48 МГц, причем судя по всему от выбора источника тактирования USB (выделенный PLL1 или дополнительный делитель от PLL0) происходящее не зависит. Пробовал поднимать частоту ядра до 72 МГц, но там вариант "3 CPU clocks" для ускорителя уже не работает, т.е. приходится сидеть на безопасных настройках.

Странно то, что глюк проявляется только при первом запуске контроллера после подачи питания. Другая часть программы, не связанная с USB, работает нормально. И в случае дальнейшего сброса по сторожевому таймеру или с внешнего источника USB заводится с пол-оборота.

Какие могут быть мысли у уважаемого сообщества? В какую сторону посоветуете копнуть?
goodwin
Требования errata соблюдены? (настраивать делители тактирования до старта PLL)
bseyur
Да, PCLKSEL настраиваются до PLL, CCLKCFG и USBCLKCFG - после.

Попробовал настраивать делители и ускоритель флешки до включения PLL - без изменений... Проц работает как ни в чем ни бывало, только usb лежит. ((
bseyur
Нашел причину.
Вот она, ключевая фраза: "FLASHCFG: Bit 11:0 - - Reserved, user software should not change these bits from the reset value."
Первый раз на эти же грабли наступил, когда записывал регистр PCONP - от этого GPIO начинал неадекватно работать. Чтож, и на этот раз будем знать... )
sonycman
Цитата(bseyur @ May 2 2010, 12:36) *
Нашел причину.
Вот она, ключевая фраза: "FLASHCFG: Bit 11:0 - - Reserved, user software should not change these bits from the reset value."
Первый раз на эти же грабли наступил, когда записывал регистр PCONP - от этого GPIO начинал неадекватно работать. Чтож, и на этот раз будем знать... )

Так что, в битах 11:0 не нули после сброса?
Блин, и в случае с PCONP тоже самое тогда - про бит GPIO в последнем мануале неверная информация!

Нехорошо косячить в мануалах sad.gif
klen
видимо не нули....
bseyur
Нет, не нули. Ну это ладно, на счет них в мануале все четко описано, можно списать на собственную невнимательность. cranky.gif
А вот на счет зарезервированных битиков PCONP ничего конкретного не сказано. Однако, даже нули туда писать не рекомендуется! Трудно сказать, что это, ошибка в мануале, либо баг, достойный включения в errata.
sonycman
Цитата(bseyur @ May 2 2010, 14:26) *
А вот на счет зарезервированных битиков PCONP ничего конкретного не сказано. Однако, даже нули туда писать не рекомендуется!

Не то что не рекомендуется - а категорически нельзя!
Если 15 бит PCONP сбросить в ноль - совершенно отвалится GPIO.

Причём в мануале сказано однозначно - бит GPIO сбросить невозможно, так как он устанавливается автоматически.
На самом деле ещё как можно smile.gif
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.