Все добрый день.
Надеюсь на помощь.
Перепроверил все что только можно... Пребываю в полной растерянности...
Может кто сталкивался с чем то подобный...
Помогите!


Есть собственная плата - прототип будущего устройства. (у меня две платы прототипов - ведут они себя один в один)
Она сделана на основе демо платы StarterKit SK-LPC2478-S3E; используется только ARM7.

На плате стоят:
- LPC2478 (rev. D с датировкой 1130)
- SDRAM Micron MT48LC16M16A2-75D
- для UART используется MAX3232E

На демо-плате прообразе стоят:
- LPC2478 (rev. C)
- SDRAM Samsung K4S561632H-UC75 (в прилагаемой схеме указан Micron MT48LC16M16A2)
- для UART используется AD3202 (в прилагаемой схеме указан MAX3232)

Схемы включения всех этих компонентов идентичны.

Остальные компоненты в рамках вопроса не важны.



Плата должна работать с linux, который загружается через U-Boot.

Версия U-boot 1.1.6... т.к. к ней есть набор патчей с портом под LPC2478.

В рамках текущей отладки работа ведется с встроенным "генератором" IRC 4MHz.
(U-Boot модифицирован под такие установки - Соответственно настраивается PLL.)
В результате имеем 60MHz.

U-boot загружается во встроенный флеш. И от туда стартует.


...а вот теперь увы и ах!

Одна и таже прошивка нормально работает на плате прородителе от SK и странным образом "разваливается" на моей плате.
(до загрузки linux пока недоходит)

Внешне этот "развал" проявляется как потеря в консоли части сообщений, отображением всякую кракозябру или печатью других текстовых фрагментов (они есть в коде, но должны появляться в другом месте и в другое время), как правило, много ляпов с переносом строк.
При этом пропадает только часть сообщений, другая часть работает стабильно... еще некоторая часть через раз...
!!! При этом программа нигде не виснет и доходит до ожидания приказов через консоль. А вот из приказов принимает только Crtl+C (на экране появляется <INTERRUPT>), команды U-boot игнорируются без вывода каких-либо сообщений (ну что команда мол не верная, например).


Первым дело под подозрение попал UART и все что с ним связано. Проверки показали что все в норме и по схемотехнике, и по настройкам, и по коду программы.
Эксперименты с изменением баудрэйта и изменением частоты проца никчему не привели - все тоже самое.
Так же - каких либо отличий от прородителя не нашел(и).

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


Заметил, что постоянная белеберда возникает в тех сообщениях, которых используется функция printf (не путайте ее со стандартной из библиотеки... но это ее аналог из модуля concole.c... который юзает vspfintf из одноименного модуля).
Все нормально при печати через функцию puts (аналогично... из модулей u-boot).
И периодическое проглатывание сообщений если в puts используется переменная, а не константа (сначала есть переменная, потом она переводится в строку, затем добавляется к тесту, который выводит puts)

Т.е. получается что-то не то с обращениями к некоторым функциям...


Стал копать глубже. Получилось, что U-Boot работает так:
1- старт Start.S (asm-овский файлик, который проводит первичную загрузку...)
2- lowlevel_init.c (настройка источника тактирования и PLL, настройка SDRAM, отображение нескольких сообщений своими силами...)
3- возврат в Start.S (остается только переброс на шаг 4. ...в когда-то здесь же был релокате в SDRAM, но сейчас он в коментах/define-ах а сам релокате далее (это не я так и было))
4- board.c (первым делом релокате в SDRAM; выделение памяти, задание нужных значений и настроек; вывод всяческих сообщений... и т.д.)
Далее Board.c перекидывает управление на main.c, а тут уже ждет команды от человека из консоли или бежит по настройкам по-умолчанию

Сам этот board.c лежит /lib-arm/ (т.е. специфичен скорее для ARM-ов, а не для самой платы)
В своей работе board.c использует разные функции из других модулей, например, serial.c, console.c и т.д.

При это п.1 (он же п. 3) стартуют с встроенного флэша.
П. 2 - тоже из флеша.
А вот все что идет далее сидит в конце SDRAM. (стартовый адрес этого сидения задается через параметр TEXT_BASE)


Т.е. возникают некие сбои при обращении к одним функциям сидящим в SDRAM.... но в тоже время другие функции SDRAM работают нормально или нормально через раз... мистика какая-то.


Стал проверять настройки SDRAM и контроллера памяти EMC в LPC2478.
Да и тут все в норме... даже с запасом все дано... переделал для авто расчета из Define подобно тому как ноте от NXP AN10771
Проверил весь код инициализации...
Обыскался отличий Samsung от Micron... ничего толком (есть мелкие в 1ns по ряду минимальных значений параметров...но не более - выбрал наиболее жесткие)


Прикрутил тесты SDRAM (пишем все потом все читаем):
- один тест в lowlevel_init.c, сразу после инициализации памяти и перед прыжком в board.c (т.е. перед релокатом работы в SDRAM) (по всей памяти)
- второй в board.c после выделения памяти и выставления минимально необходимых параметров и настроек. (память до области кода и стека)
(собственно SDRAM и его параметры тестировались еще при оживлении палаты после сборки - и все тоже было ОК)


Поигрался с параметрами:
Если что не так (зависание или ошибка теста), то сбой сразу и на прототипе и на демо.
Улучшений нет.


Смотрим u-boot.map и видим что адреса для printf и puts очень близки...
Так же заглядываем в образ u-boot.bin и выясняем что сообщения с фрагментами текстов от других сообщений вряд ли можно получить простым смещением адреса.
...мистика...


Начинаем двигать область кода по памяти ближе к началу (меняем TEXT_BASE на половину от максимума и еще ближе к началу)... изменений нет.
В U-boot.map все изменяется правильно в соответствии с новым адресом.
И опять на демо плате все ОК, но моих обоих прототипах "развал".


В чем причина не пойму!
Помогите.

Какая еще информация нужна?




--- Попробую подвести краткий итог проверкам, которые я сделал: ----------------------

1. Общая схемотехника (связи между MCU, SDRAM, UART-преобразователь и разъем RS232)
- SDRAM располагается прямо с обратной стороны от LPC2478
2. UART-хозяйство (так же в модуле выполняемом из флеш... или тестовых программках в KEIL все нормально)
3. Настройки SDRAM и контроллера памяти EMC в LPC2478
4. Добавлены тесты памяти работающие и при работе из флеш и из SDRAM (оба теста завершаются успешно) (и запись номера, и паттерна)
5. Двигал область кода в SDRAM
6. Пробовал все это при разных комбинациях основной частоты камня и разном баудрэйте

Напрашивается простой вопрос - осциллографом пробовали на линиях УАРТа смотреть? Настройки УАРТа проверяли, как то: наличие ФИФО, ДМА, прерывания и т.п? Еррату на процессоры нужных ревизий читали?

UART - осциллом смотрел... все в норме

В еррате - по UART ничего.
(в целом есть два отличия от ревизии С - в процах с определенной датой меньшая точность IRC; Memory Acselerator Module чуть другую архитектуру имеет, но в целом все так же)

А "кракозябры" от старта к старту меняются как-нибудь, или картина воспроизводится стабильно?

А честоту PLL или IRC никак нельзя проверить? Вывести ШИМ с таймера например.
Кстати, зачем вам релокейт с SDRAM? Его можно совсем исключить - U-boot из NOR-а прекрасно работает.

Может всё-таки от кварца стартануть попробовать?

Стабильно для одной версии сборки (причем на обоих платах прототипа).
Перезагрузки, ожидания и новые запуски, наличие помех поблизости - не влияют.

Меняются только при внесении изменений в код программы и новой сборке. И опять стабильны.



1. Частоту PLL приборами не измерял.
Для проверки влияния экспериментировал с установкой разных параметров частоты и PLL.
Если настройки неверные, то либо виснет... либо явный сбой с UART-ом и сплошные кракозябры вместо всех сообщений...
а вот так что бы половину потерять, а другую без искажений вывести... да с четкой зависимостью от используемой функции - такого игрой с частотой не получить

Заглядывал в регистры запущенного проца через JTAG:
Настройки PLL и установившуюся частоту смотрю - все ОК.
Настройки SDRAM - точь в точь как и прописано в коде программы.

Тоже по остальным параметрам.
...на нормально работающей демо плате в регистрах все тоже самое.


2. Релокэйт в SDRAM
U-Boot сволочь не хочет запускаться без релокэйта.
Он и компилиться уже с учетом этого и кушает адрес TEXT_BASE из конфига.

Хотя может я чего не понял, тогда подскажи те что подправить, что бы пошел работать только с флешки.



Подключил внешний генератор (не резонатор, а именно стабилизированный кварцевый генератор на 5MHz, перенастроил соответственно PLL).
Результат - платка запустилась, проблема та же.

Заглянул в регистры через JTAG на работающей плате - все нормально (так как задано и как должно быть).

В конфиге платы поищите

Вернее этот дефайн надо туда вставить. У меня такая настройка находится в include/configs/название_борды.h (у меня другой проц и другая плата). А используется он в Start.S соответствующей архитектуры.

P.S. Я не понял (или пропустил) Вы один и тот же бинарник прошиваете в обе платы? Или под каждую плату надо собирать свой?

Как раз писал об этом.


Почитал что пишут на DENX и на их форуме:

Рекомендация такая - достаточно поменять TEXT_BASE + отключить релокэйте.

Меняю TEXT_BASE, отключаю релокате операцию (+ memmap = запуск из встроенной flash)... проходит первый модуль lowlevel_init.c и виснет.
Пробую двигать адрес по встроенной флешке - все тоже самое - виснет в том же месте.
(мало ли месте на хватило - двигаю; проверяю в u-boot.map - пространства хватает и с запасом)




Прошивка (образ-бинарник) одна и таже.
(на демо прародителе - работает; на прототипах этот странный глюк)

Все эксперименты провожу и на прародителе (убеждаюсь, что нормально работает), и на прототипах.
В рамках данной части разницы быть не должно (в теории, по мануалам).

Исключение только последний эксперимент с генератором 5MHz.

У Вас же есть JTAG, так отладьте его пошагово.

Ура!!! Проблема решена.
Коллеги всем спасибо за участие.

Для U-Boot очень важен burst режим работы с памятью.
А у себя на плате я как раз нашел ошибку с ножками DQMx, которые участвуют только в этом режиме.
Обычные простые тесты памяти это не обнаруживаются, т.к. burst режим не используют.
Вот.

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

Мне помогли вот эти материалы:
1. http://www.denx.de/wiki/view/DULG/UBootCrashAfterRelocation
2. http://www.ece.umd.edu/courses/enee759h.S2...es/E0123N50.pdf