caxapa.ru :: Нет такого вопроса, это у тебя в голове какой-то пробел. HardFault вызывает какая-то АССЕМБЛЕРНАЯ инструкция, выполняемая в нетипичных условиях с нетипичными значениями. Никто не обещает, что разные компиляторы Кейл и ЙАР должны генерить одинаковый код. А источник проблемы все равно - в исходнике на Си. Самый распространенный случай - невыровненный доступ к памяти, который возникает из-за преобразования типов указателя. У Cortex-M3 есть инструкции, которые могут выполняться

il-2 (30.07.2023 10:34, просмотров: 190) ответил IBAH на В этом то и вопрос, почему в кейле работает? Где-то что-то нужно дополнительно указать.

Нет такого вопроса, это у тебя в голове какой-то пробел. HardFault вызывает какая-то АССЕМБЛЕРНАЯ инструкция, выполняемая в нетипичных условиях с нетипичными значениями. Никто не обещает, что разные компиляторы Кейл и ЙАР должны генерить одинаковый код. А источник проблемы все равно - в исходнике на Си. Самый распространенный случай - невыровненный доступ к памяти, который возникает из-за преобразования типов указателя. У Cortex-M3 есть инструкции, которые могут выполняться

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

И еще - в системных регистрах Cortex-M3 есть бит (не помню названия), который по умолчанию позволяет невыровненный доступ. Но его можно выключить, и тогда невыровненный доступ будет приводить к HardFault всегда. Ищите и обрящете.

Ответить

- Спасибо за развернутый ответ. "Ты ему разрешил". Так вот в этом и вопрос, где в настройках компилятора это разрешается? Может я недостаточно точно выразился: ИАР компилирует проект с файлами под STM32F107 как КортексМ3 (не работает, ХардФалаут), а Кейл компилирует проект с файлами под STM32F107 как GD32F107(все работает). Резонный вопрос, где в настройках то что отличает GD32F107 от стандартного Кортекса? - IBAH(30.07.2023 14:37)
  - Что ты прицепился к компилятору и его настройкам. Я просто в кач-ве примера привел как тыпрограммист может добиться невыровненного доступа к памяти: il-2(210 знак., 30.07.2023 15:38)
    - после такого приходится привыкать к memcpy :) - Vit(30.07.2023 15:59)
      - memcpy тоже иногда лажает. Помнится с fk0 срались тут на эту тему. - LightElf(30.07.2023 20:07)
        
        Кстати да. У себя, при высокой оптимизации ARM GCC, видел, как байтовый memcpy(), по факту, становится двухсловным. Просто потому, что шла работа с массивом 32-битных значений. Nikolay_Po(373 знак., 30.07.2023 23:45)
        
        Как я понял, компилер пытается подложить самую оптимальную версию memcpy основываясь на своём представлении о прекрасном. И иногда эвристика слишком оптимистична. - LightElf(31.07.2023 00:14)
        
        Если не забыть расставить volatile, где требуется, проблем не будет. Просто компиляторы становятся более совершенными и оптимизируют больше, чем программист мог себе это представить, но не больше, чем позволяет выбранный стандарт. - Nikolay_Po(31.07.2023 00:45)
        
        Не, там не в volatile дело было. Там именно компилятор терял информацию о типе и делал неверные предположения о выровненности указателя. LightElf(141 знак., 31.07.2023 01:14)
        
        "...компилятор терял информацию о типе и делал неверные предположения о выровненности указателя" - думаю, что именно из-за того, что указатель был слишком изменчив (слишком волатилен), за пределами контекста секции кода. Nikolay_Po(27 знак., 31.07.2023 07:47)
        
        volatile - это совсем не про это - SciFi(31.07.2023 07:50)
        
        Не удивлюсь, что про всё. Оптимизации случаются весьма и весьма изощрённые. Если, в контексте, обычный указатель меняется только с шагом двойного слова, то компилятор имеет право считать указатель выровненным. И, если программист, не объявив указатель volatile, вне контекста, прирастит эту переменную на байт - жди беды. - Nikolay_Po(31.07.2023 07:54)
        
        обычно оно должно быть вылизано и оптимизировано. если такое подводит, то либо закат Солнца вручную, либо закидывать такой компилер подальше - Vit(30.07.2023 20:47)
        
        В компиляторах Си давно уже окопались приплюснутые диверсанты. Норовят погубить ламповую Сисечку, рептилоды проклятые. :-( - LightElf(31.07.2023 00:10)
- На прошлой неделе нарвались, дело не в софте а в харде было, там 2 блока 19" и на дин рейке кое что. Несколько преобразователей с развязкой. Драйверы которые раньше ставили пропали, на транзисторах сделал, они вдвое больше жрут. И IRM03-12 стала вырубаться через пару секунд. - Visitor(30.07.2023 10:53)
  - Да понятно оно, что HardFault может произойти от чего угодно. Человек недоумевает, почему на одном компиляторе есть HF, а на другом нет. - il-2(30.07.2023 11:09)
    - Логично, но и тут сову на глобус натянуть можно: допустим в одном компиляторе время инициализации вдвое больше чем в другом, бред, конечно, но разного насмотрелся:-) - Visitor(30.07.2023 11:18)
      - О! На баг с разницей по времени инициализации и я попадал, ешё с PIC24F. - Nikolay_Po(30.07.2023 23:47)

ARM, RISC-V контроллеры