Добрый день уважаемые!
(Работаю в VisualDSP 5.1.2)
Подскажите что я делаю не так:
1.Сделал initcode.dxe для инициализации SDRAM - загружаю его в проекте.
Сдрам работает ,если там разместить массивы всё пишется и читается .

2. Я добавил заранее заполненный массив :


в .ldf файле прописал :


компилю программу, вывожу массив на экран - там одни нули.
Вроде как не проинициализировался, почему?

А как проверяете массив? В окне просмотра переменных или по адресу? В настройках есть галочка "уничтожать неиспользуемые переменные". если он у вас нигде кроме объявления не находится в тексте, то компилятор просто мог стереть этот блок.

А где у Вас инитится SDRAM? Как я понимаю - firmware у Вас грузится bootROM-ом откуда-то (флешь?) частично в SDRAM, потом стартует. После старта firmware внутри него делаете инит SDRAM?
Или может меняете какую-то частоту, от которой тактируется SDRAM? Не выходит ли она за допустимые пределы? Или может за допустимые пределы на новой частоте выходят предустановленные тайминги в регистрах контроллера SDRAM?
Если так - то перед этим надо SDRAM перевести например в режим Self Refresh и только в таком состоянии можно поменять тактовую SDRAM.

..в прошивке есть функция которая по команде выводит массив в терминал, вот и выводит одни нули.
Хотя если записать (по команде) в какуюнить часть массива какое-нить число - то оно там сохраняется и выводится.
Проверяю и через указатель на память и буквально по индексу массива.




..у меня грузится initcode , потом грузится основная прошивка - массив инициализирован в ней.
Частота PLL и sdram устанавливается в initcode и больше не меняется.

Нули - это подозрительно. Если SDRAM контроллер не настроен, то в SDRAM лежит "мусор".

Посмотрите содержимое образа - там должна быть секция, которая инициализирует массив по этому адресу. В вашем случае это должна быть секция с данными, а поведение такое, как будто секция ZEROFILL. Посмотреть содержимое образа можно утилитой LdrLoader.exe, подсунув ей .ldr файл (на самом деле он hex), утилита легко находится на просторах интернета.

..спасибо, посмотрю в будни.
Я заметил что если я какой проинициализированый массив или функцию переносил в sdram , то прошивка почему-то уменьшалась.

Содержимое SDRAM никак не зависит от настроенности контроллера SDRAM.

Правда? Вы это на практике с сабжевым процессором проходили или умозрительно изрекаете?

Объясните, как инициализация SDRAM (а это напрямую влияет на её содержимое), висящей на шине ADSP-BF533, может быть осуществлена без контролера SDRAM?

А если туда записать не одно число, а массив в несколько КБ? Он полностью сохраняется?
Проверять одну ячейку не корректно - может у Вас там в МК кеш включен и прочитаете обратно из него, не проверив никак саму SDRAM.
Судя по описанию - какие-то проблемы с компиляцией/компоновкой. Проверьте по map-файлу - по какому адресу размещается данный массив? Есть ли записи о его инициализации?
Попробуйте перенести его во внутреннее ОЗУ и сравнить что меняется в map.

PS: Неужто за полгода так и не решили проблему???


Вы думаете, что алгоритм работы SDRAM как-то зависит от МК, к которому она подключена?
Причём тут процесс инициализации контроллера? Вы внимательно прочитали что сами написали и мой ответ??
Контроллер может быть настроен, туда занесены данные, потом он может быть перестать быть настроен (процессор может быть сброшен или в sleep уйти например), но данные в SDRAM при этом никак не изменятся.

Пардоньте, но это вы невнимательно читаете. У меня было:



SDRAM может быть проиницилизирована только с помощью контроллера SDRAM и никак иначе. Поэтому он и был упомянут.



Во-первых, ADSP-BF533 - не МК, и у него процесс загрузки и инициализации весьма отличается от флешовых МК. Во-вторых, то, что вы написали в отцитированном: настроен, перестать быть настроен, опять стать быть настроен... - это ваши фантазии. Автор темы явно написал, что у него проблема при загрузке, т.е. после включения питания - данные массива не инициализируются правильно.

Причин тут две:

• правильно ли настроен контроллер SDRAM - за это отвечает код в .init секции загрузочного образа - именно это я имел в виду;
• имеется ли секция данных с инициализаторами этого массива в этом же образе.

У меня складывается впечатление, что с ADSP-BF вы дел не имели и пытаетесь экстраполировать свои знания из области МК серии Cortex-M на эту область.

Вы читать умеете? А понимать смысл прочитанного?
У Вас было то, что написано в сообщении #5. На него я ответил сообщением #7. Причём тут ваше сообщение #8???
Мой ответ из сообщения #7 касается только Вашего #5, он никак не может быть ответом на #8, так как оно было позже.
Вы понимаете, что причина должна быть ранее следствия, и не может быть после?
Вначале - причина, потом - следствие? Улавливаете?
Улавливаете почему моё сообщение #7 не может быть ответом на Ваше #8?


Да ладно?
Наверное те чудаки, которые подключали SDRAM например к AVR по GPIO, этого не знали.


А Вы сами-то читали, что написал автор темы?
А написал он, что у него сперва грузится одно ПО, которое инитит МК, PLL и SDRAM-контроллер, потом грузится другое ПО. Обычно при загрузке любого ПО, оно при старте настраивает периферию МК, в том числе PLL и контроллер SDRAM.
Вот как раз именно та ситуация, о которой я и пишу.
Очевидно Вы не имели опыта работы с SDRAM, а у меня в нескольких проектах именно так и делается: инитится PLL+SDRAM, затем они используются, потом они переинитятся на другие частоты, но при этом содержимое в SDRAM сохраняется.
Прочитайте выделенное несколько раз, пока не поймёте. Потому что между первой инициализацией и повторной переинициализацией контроллера SDRAM, данные у меня в SDRAM сохраняются, хотя контроллер её в это время не настроен.


И ещё раз - при чём тут Cortex или не Cortex? Да, с ADSP я не работал. Алгоритм работы SDRAM как-то от этого меняется???
Могу Вас успокоить - с SDRAM я работал и на OMAP L-137 (ARM9+DSP), а не только на Cortex-M.

..по map файлу массив попадает куда нужно и массив и переменную совал в сдрам .
Менял им значения при работе , тестил содержимое сдрам записью туда нескольких килобайт чисел и потом проверкой их.
Пока считаю что sdram настраивается корректно. Но почему-то инится нулями.

з.ы.
Я тогда начал разбираться и забросил, а сейчас время появилось. Обидно - все интерфейсы у блекфина попробовал и так или иначе запустил , а со SDRAMом какие-то проблемы .
И подозрение такое что просто где-то туплю.

Настройка контроллера SDRAM у вас где производится? В init? В основном приложении? Или в обоих?

map файл - это хорошо, но важно, чтобы в ldr была секция, содержащая инициализаторы, с правильным заголовком. И секция init до неё.


Не отчаивайтесь, там всё просто и надёжно работает, за 10+ лет интенсивного использования BF533 + SDRAM (да там ещё на этой же шине FPGA с самописным контроллером) ни одной проблемы не помню. Вам надо просто посмотреть потроха ldr упомянутой выше утилитой, и сразу станет ясно, где проблема.

Я спрашивал - если просто этой секции, в которую линкуется проблемный массив, назначить целевой регион вместо SDRAM внутреннюю ОЗУ, то его содержимое становится правильным или нет?
Смотрите
Инициализация си-переменных (и конструкторы статических объектов) выполняется си-стартап кодом. Инит контроллера SDRAM может выполнятся как в си-коде (после си-стартапа), так и до си-стартапа (в асм как правило, но можно и си-функцию написать).
Если есть какие-то инициализированные переменные (хоть нулями хоть другими константами или конструкторами), то нужен 2ой вариант. Ещё конечно возможен инит контроллера SDRAM скриптом эмулятора (полезно для отладки кода в SDRAM), но здесь не Ваш случай.
Вы пишете, что у Вас контроллер SDRAM инитит загрузчик, потом он грузит образ рабочей прошивки в ОЗУ и запускает его. А сама рабочая прошивка ничего не делает ни с PLL ни с контроллером SDRAM. Так?
Возможно она меняет какую-то периферию или перепрограммирует какую-то ногу контроллера?
И если секция, в которую линкуется массив, инициализируемая, для неё должна быть в образе прошивки секция-инициализатор с начальными данными, которую потом исполнит стартап-код. Она есть?

и настройка сдрам и pll настраиваются в init. В основном приложеннии ничего не трогаю из этого.



в ldr или в ldf ?



спасибо


вот массив

если строку с прагмой коментю то содержимое массива выводится.

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


я тогда не пойму почему если массив лежит не всдраме то в прошивке всё есть и инициализатор тоже по видимому , а если в сдраме то всё вдруг пропадает?

Это правильно.


Да, расширение файла ldf, но сам файл образа у них называется ldr. Вот, кстати, смотрелка для него.

Если правильно отработала утилита elfloader.exe (ей сообщили правильные опции), то в загрузочном образе будет секция с флагом INIT и он будет в первых рядах, а где-то за ней должна быть секция с данными, в заголовке которой должен быть адрес массива в SDRAM и его размер. Этим вьювером всё это вполне удобно проинспектировать - адреса, размеры и флаги он показывает читабельно.

открыл этой программой одну из старых прошивок (там массив лежал в самом начале sdrama - с адреса 0x68)
И вижу две прошивки , init и рабочую : DXE0 и DXE1 , в DXE1 вижу свой массив с правильного адреса заполненный правильными данными.
Ничего тогда не понимаю.
Может прошивка так быстро грузится что пишет в сдрам данные, а сдрам ещё в "промежуточном состоянии" находится ? Может после init прошивки нужно какую-то паузу создать?

Это вряд ли - если контроллер настроен, то он сразу работает. Вы можете в init добавить свой код, чтобы поэкспериментировать, в т.ч. и паузу. И потом, у вас, вы сказали, там нули лежат. А это означает, что данные-то туда грузятся - если бы контроллер не работал, то там лежал бы "мусор". Такое впечатление, что там кто-то поверх нули записывает. Посмотрите, не ли случайно ещё одной секции с этим же адресом и флагом ZEROFILL?

..других данных на тот же адрес в файле нет.

эмулятор есть? Поставьте watchpoint на первое слово вашего массива и увидите кто в него и что пишет.
Также можно записать перед стартапом какое-нить значение (при помощи эмулятора) в одну из ячеек массива и посмотреть после стартапа её содержимое.
Возможно у вас кто-то портит этот массив.
Отлаживать своё ПО можете только Вы сами, удалённо это не сделать.

..ооо! эмулятора нет, но в VDSP есть симулятор, может поможет?


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

Создал свою секцию в файле ldf


Массив стал выводиться но только почему-то по пол слова правильно , т.е.
Массив записан так :



а выводится это:


Почему?

Причём если ручками записать по адресу массива двухбайтное слово - то оно записывается правильно, и читается правильно.

А в ldr файле в соответствующий секции тоже такие же значения лежат?

У меня в коде инициализирумый массив описан так:

А в линкерном скрипте

Не помню никаких проблем.

я ничего не понимаю - посмотрел гляделкой LdrViewer.exe в файле NewProject.ldr и не нашёл там своего массива, хотя он (пусть половинчато) выводится и в файле NewProject.map.xml есть :

Да, я тоже не вижу в ldr (в моём есть такие секции - в адресом пространстве SDRAM, т.е. утилита отображает исправно). Если есть в мапе, следовательно, должно быть и в dxe. Если из dxe в ldr не попадает, надо смотреть процесс генерации образа - утилита elfloader. У меня её запуск:



где: LOADER - elfloader.exe

А вы не из под VisualDSP работаете?

Нет, IDE VisialDSP++ только для отладчика использую (точнее, использовал, пока не перелез на линух, кодирование и сборка внешними тулзами (slickedit + scons)).

У вас тоже нет препятствий напрямую запустить любой инструмент из пакета. Попробуйте руками (утилитой elfloader.exe) ldr файл сгенерировать.

По прежнему выводит по пол слова:

вывод моего терминала:


Хотя если пишу после включения ручками в память - пишет и читает нормально, но при условии что пишу по чётному адресу.
А если пытаюсь записать двухбайтное слово по нечётному адресу в памяти - всё зависает, почему?

У Blackfin есть требование по выравниванию. Однобайтные обращения можно делать по любому адресу, двухбайтные (halfword) - только по чётным адресам, четырёхбайтные (word) - только по адресам, кратным четырём. Если это нарушить, то возникает аппаратное исключение. Это всё описано в документации. Поэтому у вас проц и виснет.

спасибо.

Виснет не поэтому. Виснет потому, что нет обработки этого исключения.

Обработчик исключения там есть - обработчик по умолчанию. В нём процессор и сидит, а основная программа при этом висит.

Наличие обработчика не говорит о наличии обработки исключения. Обработчик может быть пустой. Или только осуществляющий индикацию.
Обработка исключения - это набор некоторых действий после исключения, позволяющих вернуть ход выполнения в штатное русло. В данном случае например: выполнить операцию побайтно в обработчике и вернуться в основной поток выполнения. Ну или нечто иное.
Раз у Вас там "сидит", значит никакой обработки у Вас нет.

Это после любого исключения можно вернуть "в штатное русло"? Наверное поэтому каждый видел сообщения ОС "Приложение выполнило недопустимую операцию и будет завершено". Невыровненный доступ на Blackfin - невыполнимая операция. И выполнить её "побайтно" вы не сможете. Там просто нет никакой дополнительной информации - какой был доступ. Кроме того, чаще всего такая ошибка возникает ни из-за того, что программист ошибся и выполнил такой доступ (на том же Си не так просто это сделать, т.к. компилятор правильно организует доступ). А возникает это из-за как правило из-за ошибок работы с памятью - порчи стека, ошибок адресной арифметики и т.д. - вот тут-то и лезет обращение по невыровненному адресу. И как тут прикажете исправлять?

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

Т.ч. у каждого свои понятия, что есть обработка. Какая-то она есть. А другую там и применить.

В зависимости от алгоритма работы ПО - возможно.


Вот это и есть - один из вариантов реализации такого Обработчика исключений. Не тупо зависнуть на заглушке, а собрать необходимую информацию об исключении. И выдать её пользователю. Либо сохранить её куда-то и перегрузиться. Это всё и есть - "штатные русла выполнения ПО после исключения". У меня исключения как правило именно так и обрабатываются. Если нет каких-то спец. требований.


Да ладно? Все могут, а я не смогу?
А значение PC при возникновении этого исключения разве не известно? Даже с учётом конвеера DSP я думаю возможно будет определить команду вызвавшую его.
А дальше всё штатно, как и для других архитектур, где есть такие же ограничения: декодируем код команды, режимы адресации, регистр, вычисляем результирующий адрес доступа и операцию, и выполняем её.


Как правило такая ошибка чаще всего возникает при некорректной работе с указателями.
Конечно - при разработке ПО её лучше исправить. Но в каких-то редких случаях может быть полезной и программная эмуляция невыровненного доступа.
Например - в Cortex-M я видел рекомендации по использованию исключения невыровненного доступа именно для программной эмуляции этой операции и возвращения выполнения в штатное русло.

И что это даёт? Ну, перезагрузилсь - и что? Проблема-то не решена. В программе баг, ваши перезагрузки его не исправят.


Насчёт PC не знаю. Но даже если это известно, это не поможет. При возникновении исключения из-за невыровненного доступа у Blackfin в регистре SEQSTAT лежит код 0х24 (Data access misaligned address violation), всё, больше никакой информации нет. Вы не можете определить, был ли 32-разрядный доступ по адресу, кратному 8 бит или по адресу 16 бит, или это был 16-разрядный доступ ко нечётному адресу. И как вы будете тут что-то исправлять?

А самое главное - в 99% (если) случаев это исключение возникает из-за "прострелов" памяти, т.е. тут даже если знать всё о точке возникновения исключения и о размерах выравнивания, это всё равно абсолютно ничего не даёт - бессмысленно исправлять доступ, когда ошибка совсем в другом. На ARMv7 тут и исключения не возникнет, т.к. эта ISA поддерживает невыровненный доступ, но это лишь отсрочивает обнаружение проблемы. А на Blackfin обнаруживается в том числе и по этому признаку, т.к. его аппаратура не поддерживает невыровненный доступ. Только и всего. И такие ошибки в программе на РС всегда заканчиваются выдачей Segmentation Fault и аварийным завершением программы.

И лучшее, что тут можно сделать - это организовать какую-то выдачу информации о коде ошибки. Но мне и это было не надо - если программа зависла, я делаю останов эмулятором и смотрю, что там произошло. Если висит в обработчике исключения, то смотрю код исключения. Если он указывает на невыровненный доступ, то даже не сомневаюсь, что где-то "прострелило" память. И в подобной ситуации практически на любом МК ничего принципиально иного - т.е. возможности исправить ход выполнения программы, - сделать нельзя. А ваши доводы - это теоретизирование.

Вы что-то не догоняете...
Причём тут баг? Баги надо исправлять, а не костыли для них делать - это несомненно.
Речь не о багах, а когда по каким-то причинам необходимо изредка обращаться к памяти невыровненно. Именно штатно, а не при баге.
При чём тут все эти разрушения памяти и переполнения стека?? Речь вообще не об этом.
Я же писал о штатном русле выполнения, в котором такие исключения - вполне стандартный путь поведения ПО.
Это во-первых.
Во-вторых - даже если это нештатное поведение программы, баг, то как раз запись точки события (со всем контекстом) в энергонезависимую память - это очень помогает в нахождении этого бага.
Похоже у Вас мало опыта в разработки сложных систем, работающих у заказчика круглые сутки. Иначе бы понимали, что возможны ситуации когда твоё устройство работает скажем месяц у заказчика не выключаясь без сбоев, а потом происходит внезапный сбой (например - неожиданное исключение). Т.е. - очень редкий. Воспроизвести это "на столе" практически невозможно, так как происходит оно при редком стечении множества факторов в определённой последовательности. Сколько не отлаживай на столе - не получается воспроизвести. И визуально не найти - объём ПО - десятки тысяч строк, а то и сотни.
Вот тут как раз очень помогает запись таких событий.
В опытной эксплуатации на объекте заказчика работает множество таких устройств, скажем месяц. Набирается статистика таких сбоев (если есть). И потом по ней уже можно искать причину. Я много раз сталкивался с такими случаями.


Опять-же - это Вы не можете, а у меня всегда почему-то получалось
Я ещё ни на одной архитектуре (где есть исключения/прерывания) не видел такого, чтобы не возможно было определить точку, где оно произошло. Адрес возврата всегда есть. А для тех исключений, где по адресу возврата не определить адрес исключения (в Cortex например такие есть), адрес сохраняется в спец. регистре.
А как именно определить какой доступ и скольки-разрядный и прочее - я писал выше.
Если не понятно, разжую:
Скажем по адресу возврата минус одна команда увидели команду: LDR R0, [R1] - попробуйте догадаться скольки-разрядный доступ был и по какому адресу?
И как именно программно сэмулировать это невыровненное чтение? Имхо - даже начинающий должен догадаться....


Очевидно, что Вы не знаете не только архитектуру Blackfin, но и в архитектуре Cortex-M тоже не разбираетесь.
В Cortex-M только некоторые команды поддерживают невыровненный доступ. Да и то - опционально. Большинство команд обращения к памяти его не поддерживают.


Ну да - теперь попробуйте это сделать когда это произошло на объекте заказчика за несколько тысяч км в ночь с 31-го декабря на 1-е января. И с учётом того, что работу объекта остановить нельзя ни на час.
У Вас совсем нет практического опыта работы как видно - не представляете как реально происходят такие сбои. Ваш настольный опыт тут не поможет.


"Давайте не спорить о вкусе устриц с теми кто их ел" (С) ...

Окей, давайте докажите на практике, а то ваша пустая болтовня уже поднадоела. Вот возникло исключение - в регистре SEQSTAT код 0х24. Ваши действия? Причину вы не знаете - может память испорчена, а может программист на ассемблере что-то писал и накосячил с доступом.

Доказываю я работодателю своей работой. Моё время дорого стоит. Хотите чтобы сделал за Вас работу? Докажите, что способны оплатить моё время!
А то Ваш пустой трёп поднадоел - как видно предмета обсуждения Вы не знаете, а пытаетесь что-то советовать....

Не сомневался в таком ответе. Вы не знаете, как это сделать, вот и юлите. Я утверждаю, что из исключения, возникающего на Blackfin из-за невыровненного доступа, невозможно вернуть программу в рабочее русло корректно. Вы же в своей манере менторским тоном как обычно порите чушь, что это можно. Раз утверждаете - докажите. Ваше словоблудие, на которое вы тут тратите ваше "драгоценное" время, - это не доказательство. Не можете показать, не надо выступать.

Вы "знаете"??? Ха!
Вы даже не знаете как узнать значение PC при котором произошло исключение. Значит Вы не знаете даже базовых основ работы системы исключений в том процессоре, о котором что-то "утверждаете".
А значит всё что Вы тут понаплели - как раз и есть словоблудие.
И я нигде не утверждал, что знаю Blakfin. Я с ним не работал. Но много работал с другими DSP и Cortex-M, про которые Вы тут тоже несли чушь не владея предметом.
И по аналогии с ними, могу предположить, что на Blakfin-е дела обстоят точно так же. И то что Вы этого не знаете - ни о чём не говорит.
Так что это уж скорее к Вам пожалуйста не тратьте драгоценное время всех читателей этой темя на чтение Вашего словоблудия.

ЗЫ: И так: Раз утверждаете что "невозможно вернуть программу в рабочее русло " - докажите.

Вот именно.

Ответа по существу так и нет. Ok, слив засчитан.

Впрочем, ничего иного от вас ожидать и не приходится - только постоянные попытки давать оценку личностям оппонентов и расчёсывание собственного ЧСВ.



















По двору разнёсся слух,
Что сильнее всех петух,
Что вчера в ужасной драке
Оторвал он хвост собаке,
Гусаку намял бока -
Покалечил гусака...

А распускает этот слух...
Сам петух

Оставайтесь колотить понты. Всего вам хорошего.

Так всё-таки - как узнать значение PC прерванного процесса в прерывании/исключении на Blackfin?