Перейти к содержанию
    

bf533 sdram инициализация массива

Если это нарушить, то возникает аппаратное исключение. Это всё описано в документации. Поэтому у вас проц и виснет.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Наличие обработчика не говорит о наличии обработки исключения. Обработчик может быть пустой. Или только осуществляющий индикацию.

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

Раз у Вас там "сидит", значит никакой обработки у Вас нет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Наличие обработчика не говорит о наличии обработки исключения. Обработчик может быть пустой. Или только осуществляющий индикацию.

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

Раз у Вас там "сидит", значит никакой обработки у Вас нет.

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

 

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

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Это после любого исключения можно вернуть "в штатное русло"?

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

 

Наверное поэтому каждый видел сообщения ОС "Приложение выполнило недопустимую операцию и будет завершено".

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

 

И выполнить её "побайтно" вы не сможете. Там просто нет никакой дополнительной информации - какой был доступ.

Да ладно? Все могут, а я не смогу? :biggrin:

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

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

 

А возникает это из-за как правило из-за ошибок работы с памятью - порчи стека, ошибок адресной арифметики и т.д. - вот тут-то и лезет обращение по невыровненному адресу. И как тут прикажете исправлять?

Как правило такая ошибка чаще всего возникает при некорректной работе с указателями.

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

Да ладно? Все могут, а я не смогу? :biggrin:

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

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

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

 

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

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Вы что-то не догоняете... ;)

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

Речь не о багах, а когда по каким-то причинам необходимо изредка обращаться к памяти невыровненно. Именно штатно, а не при баге.

При чём тут все эти разрушения памяти и переполнения стека?? Речь вообще не об этом.

Я же писал о штатном русле выполнения, в котором такие исключения - вполне стандартный путь поведения ПО.

Это во-первых.

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

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

Вот тут как раз очень помогает запись таких событий.

В опытной эксплуатации на объекте заказчика работает множество таких устройств, скажем месяц. Набирается статистика таких сбоев (если есть). И потом по ней уже можно искать причину. Я много раз сталкивался с такими случаями.

 

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

Опять-же - это Вы не можете, а у меня всегда почему-то получалось :laughing:

Я ещё ни на одной архитектуре (где есть исключения/прерывания) не видел такого, чтобы не возможно было определить точку, где оно произошло. Адрес возврата всегда есть. А для тех исключений, где по адресу возврата не определить адрес исключения (в Cortex например такие есть), адрес сохраняется в спец. регистре.

А как именно определить какой доступ и скольки-разрядный и прочее - я писал выше.

Если не понятно, разжую:

Скажем по адресу возврата минус одна команда увидели команду: LDR R0, [R1] - попробуйте догадаться скольки-разрядный доступ был и по какому адресу? :laughing:

И как именно программно сэмулировать это невыровненное чтение? Имхо - даже начинающий должен догадаться.... :laughing:

 

На ARMv7 тут и исключения не возникнет, т.к. эта ISA поддерживает невыровненный доступ, но это лишь отсрочивает обнаружение проблемы. А на Blackfin обнаруживается в том числе и по этому признаку, т.к. его аппаратура не поддерживает невыровненный доступ.

Очевидно, что Вы не знаете не только архитектуру Blackfin, но и в архитектуре Cortex-M тоже не разбираетесь.

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

 

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

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

У Вас совсем нет практического опыта работы как видно - не представляете как реально происходят такие сбои. Ваш настольный опыт тут не поможет.

 

А ваши доводы - это теоретизирование.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

<флуд поскипан>

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я утверждаю, что из исключения, возникающего на Blackfin из-за невыровненного доступа, невозможно вернуть программу в рабочее русло корректно.

Вы "знаете"??? Ха! :biggrin:

Вы даже не знаете как узнать значение PC при котором произошло исключение. Значит Вы не знаете даже базовых основ работы системы исключений в том процессоре, о котором что-то "утверждаете".

А значит всё что Вы тут понаплели - как раз и есть словоблудие.

И я нигде не утверждал, что знаю Blakfin. Я с ним не работал. Но много работал с другими DSP и Cortex-M, про которые Вы тут тоже несли чушь не владея предметом.

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

Так что это уж скорее к Вам пожалуйста не тратьте драгоценное время всех читателей этой темя на чтение Вашего словоблудия. :laughing:

 

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

Не можете показать, не надо выступать.

Вот именно. B)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

Видно что искусство чтения Вам недоступно.

 

Вот это похоже на правду - что не умеете читать.

 

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

 

Очевидно, что Вы не знаете не только архитектуру Blackfin

 

У Вас совсем нет практического опыта работы как видно

 

Вы читать умеете? А понимать смысл прочитанного?

 

Очевидно Вы не имели опыта работы с SDRAM, а у меня ...

 

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

 

Моё время дорого стоит.

 

По двору разнёсся слух,

Что сильнее всех петух,

Что вчера в ужасной драке

Оторвал он хвост собаке,

Гусаку намял бока -

Покалечил гусака...

 

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

Сам петух

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...