Jump to content

    
_Desh_

Разместил таблицу векторов и код обработчика в ОЗУ, при прерывании вылетает в HardFault

Recommended Posts

18 минут назад, MasterElectric сказал:

короткая таблица это только системные прерывания. т

И даже ещё меньше. Только stack pointer и reset - 8 байт. Остальные вектора в ОЗУ, раз уж таблица туда переехала. 

Share this post


Link to post
Share on other sites
2 hours ago, Arlleex said:

Случаем, не загрузчик под Cortex-M0 пишете?

Оно самое) В теме про YModem недавно упоминал как раз) И вашу тему про загрузчик тоже читал)

Share this post


Link to post
Share on other sites
4 часа назад, _Desh_ сказал:

я на STM32F4 с Миландровского 1986ВЕ1Т пересел. Там обязательно было код записи/стирания флэш-памяти в ОЗУ размещать. Перемещаемой таблицы там не было, потому что Cortex-M0/M1

Там любое обращение к флеш-памяти в процессе её программирования/стирания приводит к хардфолту. Поэтому все функции программирования должны выполняться из RAM. 

А вот организовать обработку прерываний во время записи/стирания флеша там нельзя. Никак.

Регистра VTOR нет, ремапа памяти нет, таблица векторов непереносима и навечно прибита гвоздями к нулевому адресу, по которому расположена флеш-память. Так что любая выборка ядром адреса обработчика из таблицы векторов приводит к гарантированному хардфолту. Не важно, где именно при этом располагается сам обработчик - во флеше или в RAM. До него дело все-равно не дойдет. Хардфолт случится раньше.

Так что единственный правильный способ работы с прерываниями при одновременной записи/стирании флеша там - это полный запрет прерываний на это время.

Share this post


Link to post
Share on other sites
30.08.2020 в 14:46, _Desh_ сказал:

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

Объясните - как это сделать программисту?

30.08.2020 в 14:49, Reflector сказал:

Без разницы, компилятор может объединить оба эти массива как раз потому, что они оба во флеше и обращение к нему будет в любом случае. А массивы находящиеся во флеше и RAM компилятор объединять не будет.

Так у ТСа изначально функция находится во флешь. Он потом её вручную в ОЗУ копирует. Не предупредив компилятор. И откуда тогда компилятор узнает, что функция будет выполняться из ОЗУ?

Слово __ramfunc как раз и уведомляет компилятор о таком случае (в IAR).

30.08.2020 в 15:12, Arlleex сказал:

А после векторов (ну никак не между ними) кладу размер прошивки и контрольную сумму. И все то же самое относится к случаю расположения таблицы в ОЗУ.

А почему "не между"?

30.08.2020 в 20:12, Darth Vader сказал:

А вот организовать обработку прерываний во время записи/стирания флеша там нельзя. Никак.

Можно. Всегда есть вариант организовать её поллингом.  :unknw:

Share this post


Link to post
Share on other sites
1 hour ago, jcxz said:

А почему "не между"?

Маленько не в тему. Вы, случайно, не знаете, если у NVIC для конкретного микроконтроллера есть неиспользуемый(ые) вектор (в документации обычно помечен как reserved), я могу там разместить свой обработчик? И вызывать его программно? Или такое поведение недокументированно? 

Share this post


Link to post
Share on other sites
1 час назад, jcxz сказал:

А почему "не между"?

Ну потому что сегодня я не использую какую-то периферию, а завтра логика девайса чутка изменится и я добавлю, например, таймер.
А этот таймер потянет за собой обработчик прерывания, в котором... находится, например, CRC32 и размер приложения.
В итоге под раздачу попадет еще и загрузчик (ему же надо знать, где лежит CRC и размер пользовательского кода для startup-проверки валидности).

Share this post


Link to post
Share on other sites
5 минут назад, haker_fox сказал:

Вы, случайно, не знаете, если у NVIC для конкретного микроконтроллера есть неиспользуемый(ые) вектор (в документации обычно помечен как reserved), я могу там разместить свой обработчик? И вызывать его программно? Или такое поведение недокументированно? 

Если работает, то почему нельзя? Можно конечно. Но на некоторых МК это может не работать - могут не активироваться программно прерывания неиспользуемых векторов. Видимо это зависит от особенностей реализации NVIC каждым производителем.

Share this post


Link to post
Share on other sites
10 минут назад, haker_fox сказал:

Маленько не в тему. Вы, случайно, не знаете, если у NVIC для конкретного микроконтроллера есть неиспользуемый(ые) вектор (в документации обычно помечен как reserved), я могу там разместить свой обработчик? И вызывать его программно? Или такое поведение недокументированно? 

Сам NVIC на уровене архитектуры может поддерживать до 496 прерываний.
Но в конкретном МК реализовано столько, сколько лежит в регистре NVIC.ICTR.
Естественно, там регистр кодирует кратное кол-во прерываний, поэтому это тоже надо учитывать.

Так вот, реализация полноценного вектора (хоть и резервного) отдается на откуп производителю МК.

Share this post


Link to post
Share on other sites
4 минуты назад, Arlleex сказал:

Ну потому что сегодня я не использую какую-то периферию, а завтра логика девайса чутка изменится и я добавлю, например, таймер.
А этот таймер потянет за собой обработчик прерывания, в котором... находится, например, CRC32 и размер приложения. 
В итоге под раздачу попадет еще и загрузчик (ему же надо знать, где лежит CRC и размер пользовательского кода для startup-проверки валидности).

Вот именно поэтому я и не располагаю указатель на таблицу со своими данными после таблицы векторов. А располагаю его внутри, в неиспользуемом векторе.  :wink2:

Потому как часто бывает пишу код, компилируемый в дальнейшем на линейку устройств. С разными МК. У которых разная длина таблицы векторов.

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

Share this post


Link to post
Share on other sites
3 минуты назад, jcxz сказал:

Вот именно поэтому я и не располагаю указатель на таблицу со своими данными после таблицы векторов.

А, я понял. У Вас именно указатель на таблицу, которая находится сама по себе где-то еще.
У меня просто 2 32-битных числа (для загрузчика больше ничего не нужно в моем случае).

В целом, у меня все равно почти не бывает проектов, в которых загрузчик можно стянуть с другого проекта на уровне бинарника.
Где-то да как-то какая-то логика в нем дорабатывается под нужды и возможности конкретного девайса.
Поэтому там автоматом меняются расположения ключевых информационных полей.

Share this post


Link to post
Share on other sites
5 минут назад, Arlleex сказал:

А, я понял. У Вас именно указатель на таблицу, которая находится сама по себе где-то еще.
У меня просто 2 32-битных числа (для загрузчика больше ничего не нужно в моем случае).

Да, конечно указатель. Так гибче. Может в каком-то конкретном проекте у меня тоже в этой таблице будет всего 2 числа. Но в другом может и больше (например: таблица описания опций аппаратного исполнения или цифровая подпись или какая-то привязка к сер.номеру железа или еще чего). Просто удобнее чтобы всегда было однотипно. Так что даже если в каком-то проекте хватает двух чисел, я всё равно делаю указатель + таблица.

Да и загрузчик в текущем проекте у меня тоже обновляемый. Его формат может меняться  :wink2:

Share this post


Link to post
Share on other sites
1 hour ago, jcxz said:

Можно конечно. Но на некоторых МК это может не работать

Спасибо)

1 hour ago, Arlleex said:

Но в конкретном МК реализовано столько, сколько лежит в регистре NVIC.ICTR

Низкий поклон) Спасибо!

Share this post


Link to post
Share on other sites
On 9/1/2020 at 2:04 PM, jcxz said:

И откуда тогда компилятор узнает, что функция будет выполняться из ОЗУ?

Из атрибута, в котором указано, в какой области памяти находится код функции.

Share this post


Link to post
Share on other sites
2 часа назад, _Desh_ сказал:

Из атрибута, в котором указано, в какой области памяти находится код функции.

Какого атрибута? Где указано?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.