STM32L0 HardFault: заморочки с выравниванием Опции

[k000858]

Есть какие то ограничения в ядре, приводящие к HardFault?

Пришлось в одной функции привести указатель типа uint8_t* к типу uint32_t* изза чего получил HardFault.

В STM32F4 камне тот же самый код работает нормально.
Почему же M0+ вылетает в HardFault?

Сообщение отредактировал k000858 - Feb 1 2017, 03:59

[ViKo]

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

[demiurg_spb]

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

Нет. Это для того чтобы из принятого буфера прочесть переменную с произвольным смещением в этом буфере.
Такой вариант никто не предлагал:

Код

uint32_t __packed* p = &buff[33];
uint32_t x = *p;

Около года назад в gcc эта шляпа не сработала, а в кейле работала.

[ViKo]

Нет. Это для того чтобы из принятого буфера прочесть переменную с произвольным смещением в этом буфере.

Для M0 здесь нет решения, кроме как читать по байтам.

Такой вариант никто не предлагал:

Код

uint32_t __packed* p = &buff[33];
uint32_t x = *p;

Около года назад в gcc эта шляпа не сработала, а в кейле работала.

Поясните. Выше интересовался таким же вопросом. Указатель на упакованную структуру - как это помогает обратиться к слову по не выровненному адресу?
Ясно. Читает по байтам.

[jcxz]

Для M0 здесь нет решения, кроме как читать по байтам.
...
Ясно. Читает по байтам.

А Вы что хотели - некую чудесную инструкцию процессора?
M0 физически не умеет невыровненный доступ - нет таких инструкций у него!
Так что такой доступ можно только эмулировать. Либо встроенными возможностями компилятора (__packed) либо реализовав это самостоятельно (свой класс с перегрузками, например).

PS: Более того - даже для ядра M4 (и прочих) если переменная находится (или может находиться) по невыровненному адресу, для неё надо указывать спецификатор __packed.
А то, что у ТС "В STM32F4 камне тот же самый код работает нормально" - о говорит только о кривости написания этого кода, который сейчас работает, завтра перекомпилят его на другом компиляторе (или новой версии того же компилятора) - он будет падать в тот же HF на том же самом ядре M4. Так как никто не мешает компилятору для обращения к этим данным использовать не инструкции LDR/STR, а например LDRD/STRD или LDM/STM, которые не умеют невыровненный доступ. И компилятор имеет право это сделать, например при оптимизации.
Так что надо взять за правило: на любом процессоре, если переменная невыровнена, она должна быть объявлена как невыровненная.

[ViKo]

А Вы что хотели - некую чудесную инструкцию процессора?

Так что надо взять за правило: на любом процессоре, если переменная невыровнена, она должна быть объявлена как невыровненная.

Я руками (головой) размещаю переменные в структуре так, чтобы стояли ровно. Если есть дыры, забиваю их uint8_t RESERVED_n. А саму структуру линкер знает, куда разместить. Без указаний.
И компиляторы не пугают, ни прошлые, ни будущие.

[jcxz]

Я руками (головой) размещаю переменные в структуре так, чтобы стояли ровно. Если есть дыры, забиваю их uint8_t RESERVED_n. А саму структуру линкер знает, куда разместить. Без указаний.

Очевидно Вы не работали никогда например с протоколами передачи данных. В кадрах которых данные находятся упакованными. И объявлять такие кадры удобно структурами.
Поэтому Вам и сложно представить такое применение.
И дырок в таких кадрах нет - ну не заложили их разработчики этого протокола!