Добрый день!

Железо - STM32F105VC rev.Z.

ПО - Keil 4.21, компилятор armcc 4.1.0.644

Случилось вот что. Понадобилось мне одну 32битную сохранить в буфер, и адрес поменять на следующую ячейку буфера:



Ситуация стандартная. Но на мою голову компилятор засовывает инструкцию "STM":

тем самым пытаясь выполнить запись+инкремент за раз, но при выполнении которой происходит ошибка (HardFault).

Пока выяснял почему, начитался всякого. Вплоть до того, что вставленная 16битная инструкция STM является устаревшей и не используется для ядер ARMv6 и выше. А в другом месте (в ссылке про STM) вообще написано, что 16битная STM не поддерживается в Thumb-2EE, который для ARMv7, т.е. нашего Cortex-M3.

Но тогда почему именно эта инструкция была вставлена? Неужели косяк компилятора? Или же все-таки эта инструкция поддерживается Cortex-M3, но есть ограничения для ревизиии Z?

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

Результат экспериментов: инструкция работает, но если адрес массива не кратен 4, то вылетаем в Hard Fault.

Люди добрые, прокомментируйте случившееся. Помогите подвести итог.

А почему вы не определили pPDU как указатель на 32-битовую переменную, а увеличиваете его на 4?
По состоянию битов в xxx Fault Status регистрах можно определить причину вылета. Их можно увидеть в Keil - посмотреть соответствующий диапазон памяти (0xE000ED28 и др.).

Есть 16 битное кодирование, в ARMv7M reference manual называется Encoding T1 - тут все ок!

А в Hard Fault скорее всего вылетает из-за не выравненного доступа! STM нельзя так использовать. Если это так то в исходнике некорректное приведение типов, надо приводить к не выравненному типу или писать макрос.

To ViKo:

pPDU - указатель на байт, поэтому прибавляю 4. Fault Status завтра гляну, все железо на работе.

To KRS:

Да, ошибка возникала при не выровненном доступе. Но я не нашел где написано, что нельзя с не выровненными использовать. Подскажите в каком доке? Кто знает, может там для меня еще что-нибудь найдется.

Да, приведение корректно до некорректности. Как бы это обойти. Есть буфер, и в него пишутся разные вещи, в том числе 32битные. А структуры этих вещей выровнять не могу, т.к. этот буфер для связи с внешним устройством. Тут точно надо избавляться от "STM", но как бы это компилятору объяснить.

__packed

Процитирую помощь к Кейлу, правда, не уверен, что если указатель определен на байтовую переменную, а потом приводится к указателю на целое, то будет работать.

Unaligned pointers
By default, the ARM compiler expects conventional C pointers to point to an aligned word in memory, because this enables the compiler to generate more efficient code.

If you want to define a pointer that can point to a word at any address, then you must specify this using the __packed qualifier when defining the pointer. For example:

__packed int *pi; // pointer to unaligned int
When a pointer is declared as __packed, the ARM compiler generates code that correctly accesses the dereferenced value of the pointer, regardless of its alignment. The generated code consists of a sequence of byte accesses, or variable alignment-dependent shifting and masking instructions, rather than a simple LDR instruction. Consequently, declaring a pointer as __packed incurs a performance and code size penalty.

arm architecture v7m reference manual
так же полезно будет
Cortex™-M3 Technical Reference Manual

Огромное СПАСИБО! Использовал _packed для структур, а применительно к указателям не знал)
И мануальчики почитаю.


Наверное, топик надо в раздел "помощь начинающим/программирование". Скандалы, интриги, расследования закончены. Их просто нет, все банально просто.

А что это за макрос __REV16_W?

Эта функция меняет местами байты в каждом полуслове и выдает результат. В CMSIS есть такое: Но,как видите, они зачем-то аргумент сделали 16-битным. Поэтому я сделал тоже, только с 32-битным:

Похоже на косяк в CMSIS?

Может у них так и было задумано)

Реверсируется-то порядок байтов в обоих полусловах, и в младшем, и в старшем.

Получается, что фолт на cm3 может произойти лишь при адресации не выравненных объектов больших байта?
А указатели на байт в принципе не нуждаются в атрибуте packed.
Я правильно мыслю?

Поэтому аргумент и 16-ти битный в старшем полуслове будут всегда нули. Баги в CMSIS я не вижу.

Кстати, в литературе есть мнение, что

Понятно, что при 16-битовом аргументе будет работать. А если нужно проинвертировать порядок в обоих полусловах, придется писать свою функцию, как сделал ISK2010. Хотя команда та же.
А можно было задать в функции REV16 32-битовый аргумент. Если кому-то нужно было проинвертировать порядок байтов в 16-битовой переменной, то эту 32-битовую функцию можно было бы использовать без переделок.

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

Это да.
Разумеется.

Вопрос зачем ему это? Какой-то middle-endian формат получается. Ведь для смены эндианизма есть инструкции REV и REVSH.
Как я понял речь идёт в контексте формирования PDU одного из протоколов (modbus?), где используется не нативный для cm3 сетевой порядок следования байт.
ИМХО расширять функционал CMSIS - крайняя мера...

Да, ModBus) Решил оптимизировать функции обработки запросов. Например, сразу по 2 регистра читаю-записываю. Адрес региста+количество тоже за раз обрабатываю.

Ой не там экономите. Завтра нужно будет для 8-ми битника modbus ваять, после завтра...
За такой оптимизацией теряется прозрачность идеи.
Опять же ИМХО.

Везде по чуть-чуть. Еще с расчета CRC немного высвободил. На данный момент загрузка ~70%.

От одного модбаса?

От всего