Использую процессор STM32F103, среда IAR 6.21. Пытаюсь на нем запустить GUI STemWin. Как будто уже заработало, но никак не могу избавиться от досадной ошибки. Обнаружил, что при иннициализации GUI процессор вылетает в ошибку CMSIS UsageFault_Handler. Отладчиком прошел и обнаружил, на какой именно команде вылетает - ассемблерная команда BLX R1, и что интересно, если в отладчике поставить брэйкпойнт на эту команду, а после остановки запустить выполнение программы дальше, программа в ошибку не вылетает, иннициализация GUI проходит и дальше все работает. Загружал уже много примеров из GUI, начал делать свое приложение. Но ошибка никуда не делась, программа остается нерабочей, запустить можно только с дебаггером. При вылете в UsageFault_Handler в регистре CFSR устанавливается флаг ошибки INVSTATE. Вот тут http://badembed.ru/hard-fault-memmanage-fa...ault-cortex-m3/ прочитал, что это может происходить при некорректном переходе из режима Thumb в ARM при выполенении команды безусловного перехода BLX, из-за неправильной установки младшего бита в команде из-за разности выравнивания по границе слова при переходе из 16-битного в 32-битный режим. При проходе отладчиком ничего некорректного не обнаружил (ну да оно и не зависает при пошаговой отладке этого места). Самое главное, что что-то изменить в этом коде я не могу, так как не имею исходников GUI, а подключаю откомпилированию библиотеку, скаченную с сайта st.com, и кусок ассемблерного кода с зависанием оттуда. Размеры и адреса памяти у меня вроде заданы правильно, увеличение размера стека не помогает. Также как и попытки методом тыка поменять опции проекта и настройки компилятора. Я понимаю, что наверное мало кто работал именно с emWin, и может быть это какой-то баг GUI, но уж точно кто-то сталкивался с такой ошибкой или просто хорошо разбирается, и подскажут что можно сделать

Исходить надо из того, что Cortex-M не может иметь ни корректного ни "… некорректного перехода из режима Thumb в ARM… ". Нет у него режима ARM.
Младший бит в R1 (BLX R1) - "0" наверное? Линкер неверно адрес назначает?

Значение R1 0x08004C30, да, ноль
Получается ошибка? А как исправить?

может где-то можно поставить ключик линкера/компилятора - чтобы оно собиралось для THUMB/THUMB2 режима?

Да вот пытаюсь что-то найти, в настройках компилятора есть переключатель ARM/Thumb, но при выборе ядра Cortex M3 он (как выяснилось логично ) становится недоступным
и встает в режим Thumb.

Может надо не обобщённое ядро M3 выбирать, а конкретно контроллер STM32F…?
Версия GUI последняя, свежая, стабильная?

Нет, я конечно выбираю контроллер STM32F10XXE. Версия GUI не самая последняя - июль 2013, но эта та версия, которая в свободном достипе на сайте stm. А самую последнюю с исходниками покупать надо

Пробовал компилировать в разных версия IAREW ARM (6.50, 7.40). В принципе ничего не меняется. В зависимости от кода, опций компилятора и еще непонятно чего вылетает в разных местах кода,
ошибки разные (HardFault_Handler, BusFault_Handler, UsageFault_Handler), биты в регистре CFSR выскакивают тоже разные (INVSTATE, IACCVIOL, PRECISERR, IMPRECISERR, BFARVALID).
Никакое изменение опций проекта не помогает. Взял все настройки из примера проекта, который идет с библиотекой, не помогло.
Кроме младшего бита 0 в команде BLX программа может также вылетать по команде перехода по адресу, превышающему размеры FLASH (больше 0x807 FFFF). Как такое может быть?
Может кто-нибудь подскажет, куда обратиться за техподдержкой?

Вылетать fault из-за попытки переключения в ARM-режим может например если у Вас есть функция в asm-файле и перед ней Вы забыли указать директиву THUMB.
По дефолту IAR скомпилит функцию в ARM-режим и при попытке её вызова и будет означенный fault.


Из-за тысячи причин. Например: внутри функции разрушаете стек и при попытке возврата из функции происходит переход по левому адресу.
Очевидно Вам следует заняться отладкой своего кода и поиском багов в нём.

Так я же объясняю, у меня нет исходников GUI, я подключаю в проекте библиотеку STemWin522_CM3_IAR.a, внутри при выполнении GUI_Init() зависает.

На удачу, может письмишко в ST написать? За спрос денег не возьмут.

А стек и кучу Вы размещаете "снаружи". Может там инициализация так накручена и требует/размещает на буферы столько памяти, что съедается стек и/или куча.

Вы что пытаетесь сказать? Библиотека кри вая и поэтому глючит? Тогда выкиньте её - ничего всё равно не добьётесь.
Если же всё-таки считаете, что библиотека рабочая - ищите ошибки у себя.
Выясните хотя-бы - откуда у Вас берётся адрес с 0 в мл. бите в BLX? Воспользуйтесь отладчиком. Возможно библиотеку взяли не для того ядра. Хотя, если у Вас там разные fault-ы сыпятся, то тут какая-то системная ошибка, может что-то разрушаете
. Оглядите весь остальной код (кроме работы с библиотекой).


Проигнорят и правильно сделают.

не проигнорят, ответят что разберутся, и вот тогда проигнорят...
Только если проблема такая только у вас, то ответа будете ждать очень долго....

Нет, не только у меня! Вот у товарища Muhammadа такая же проблема, товарищ Хайзенберг хотел ему помочь, но все заглохло, а мне не отвечают.
https://my.st.com/public/STe2ecommunities/m...currentviews=84
А вообще планирую попробовать перейти на CooCox

Если посмотреть код и значения регистров, видно, что есть непроинициализированные структуры. В частности, инструкция по адресу 0х0800680E загрузила в R0 некоторый указатель. Затем со смещением 0x0C относительно него грузится R1, а затем по R1 со смещением 0x30 - регистр R2, по которому происходит улет. Похоже на таблицы виртуальных функций. Однако R0 равен NULL! Поэтому ни R1, ни затем R2 не могут быть правильными вообще. Из этого я предполагаю, что инициализация библиотеки произошла не полностью. Возможно, кроме GUI_Init() надо вызвать какие-то функции еще. Например, <гадание> драйверы железа, и т.п. </гадание>

Я не думаю, что библитека совсем кривая. Я думаю, что она тестировалась ими не для всех возможных входных данных: процессоров, драйверов индикаторов, интерфейса соединения типа компиллятора и т.д. Хотя и утверждается,
что EmWin обладает гибкостью в этом плане, но понятно что все протестировать нереально. У них на определенной демо-плате заработало, а при переходе на другое железо появляются ошибки. Может конечно ошибка у меня, но я брал за основу этот самый пример с демо-платы, модифицировал его, и все что можно уже кажется менял....

Вы сами себе противоречите.
Если она не кривая: то тестируй-не тестируй - работать всё равно будет.
Если кривая: то тестируют для того, чтобы выявить баги (а Вы думали - для чего?) и по результатам тестирования их исправить. После чего она опять-же станет не кривой.
Т.е. - кривая она может быть только если не тестировалась.

Сомневаюсь, что от типа интерфейса или индикатора она станет вылетать в fault-ы (если написана не криво), просто изображения не будет или оно будет кривое.
Насчёт процессора: у Вас же Cortex-M3? И библиотеку Вы именно для M3 взяли (я это спрашивал ещё ранее)? Т.е. - Вы думаете, что библиотека, собранная для ядра M3, тестирровалась на другом ядре???

Библиотека называется STemWin522_CM3_IAR.a, а для какого она ядра, я не знаю, я уже ни во что не верю