eddy_em

Да, компилятор хоть и городил код для софтового деления (оказывается, M0 не умеет аппаратно делить целые числа), но на этом коде происходил затык (hardfault, наверное).

Вообще, надо gcc5 попробовать. Возможно, у него этого бага нет.

From:

Там есть другие проблемы, более серьезные.

Вообще странно, потому как у меня 4.8 работает без проблем, был достаточно сложный дизайн, там всяко было деление. А есть подробная ссылка на issue?

From:

Ты как собирал? Я простым crossdev -t arm-none-eabi. Версия arm-none-eabi-4.7.3, с 5.4.0 еще не пробовал. Возможно, там нет этого бага.

Уже и не помню, что там за функция вызывалась, что-то вроде __udiv_from_thumb. По ней гугол и выдал кучу матов народа, у которого деление вызывало hardfault.

Сейчас сравнить не могу: дома компилял.

Edited Date: 2017-01-20 06:46 am (UTC)

From:

Я не собирал, я ж не гентушник :) Взял собранный arm-none-eabi в ppa.

Hardfault у меня в ртоси отслеживается и вываливает корку. Такого не было. Ты на 0 проверял? В аппаратном делении тоже hardfault при /0, там нужно предварительно пару флагов поставить, чтобы оно вызывало usage fault. Вот я подозреваю что там криво сделана эмуляция и всего то.

From:

У тебя в /usr/arm-none-eabi/lib/thumb есть поддиректории под разные архитектуры? Вот в моей сборке они отсутствуют!
Кстати, в этом не сам gcc виноват, а newlib. У меня версия 2.0.0.

> Ты на 0 проверял?
Не проверял. Но, судя по дизассемблеру, ничего страшного быть не должно.

Обновил newlib до 2.5.0. Ничего не изменилось: железякозависимые версии библиотеки не собрались. В общем, этот crossdev хрень какую-то генерит!

Edited Date: 2017-01-20 07:02 am (UTC)

From:

Да, хотелось бы более подробного изложения причины падения.

From:

Это еще с неведомых времен:
https://gcc.gnu.org/ml/gcc-help/2012-12/msg00009.html

From:

Вечером ради интереса попробую деление на STM32F030.

From:

Надо тоже к своей девборде ноги припаять, и на 030 основные эксперименты проводить. А то, боюсь, пока дойдет до серьезной разработки, я флеш в nucleo выжгу вусмерть! Там не так-то и много циклов перезаписи гарантируется (конечно, это не 100, как у STM8S003 — 100 циклов я за полчаса уничтожу — но и не миллиард...).

From:

> Не проверял. Но, судя по дизассемблеру, ничего страшного быть не должно.

Далпаеб. Там даже системный флаг есть, который по такому условию hard/usage fault делает. Возможно где-то могли и эмулировать.

From:

Там же солюшн был:

> For a quick fix try adding --with-arch=cortex-m0 to GCC configure line.

Ты пробовал?

From:

У меня так:

-mcpu=cortex-m0 -mthumb -D__CORTEX_M0 -D__thumb2__=1 -mtune=cortex-m0

Все работает без проблем.

From:

Не пробовал: в ебилде gcc черт ногу сломит: там уйма внешних модулей вызывается.
Надо загуглить, как правильно gcc собирать с нестандартными ключами.

From:

Это — ключи, с которыми gcc вызывается. Они не помогут, если сам gcc криво собран.
Кстати, "-D__thumb2__=1" используется один-единственный раз (выбор типа инструкций в CMSIS), "-D__CORTEX_M0" — скорее всего для твоей собственной обвязки, "-mtune=cortex-m0" никакой роли не играет (абсолютно одинаковый выхлоп получается что с ним, что без него).

From:

Я не разбирался глубоко. Содрал с официальных самплов где-то. Оно just works.

From:

Попробовал, в arm-none-eabi нет такой проблемы. Деление корректно работает.

From:

Гента? Какая версия gcc?

From:

Стараюсь пользoваться mainstream решениями, поэтому Ubuntu. Впрочем под MacOs, где надо собирать arm-none-eabi все тоже самое.

gcc version 4.9.3 20150529

From:

Значит, проблема в гентовском crossdev.

К сожалению, кроме генты ничего приличного нет. Думал на кальку перейти, но там еще хуже — часть пакетов бинарных, устанавливаемых через ее менеджера, часть — гентовских, устанавливаемых портиджем. Остаюсь на генте, пока она не поцтеризуется — тогда, видимо, буду на BSD переходить.

From:

А почему не хочешь arm-none-eabi из исходников собрать?

From: