STM32: Трудности при освоении

TDuke

Интересный глюк словил. Переменная объявлена глобально. Считает количество некоторых вхождений в функцию обработки прерывания УАРТ. Изменяется четко только в обработчике. Принимает значения от 0 до 3 Больше нигде не модифицируется.

Так вот если эту переменную объявить как int8_t или uint8_t, то она самопроизвольно меняет свое значение. И пофигу ставлю я volatile или нет. Произвольно меняется и все.

Если обявить ее как двухбайтовую и больше, тогда все ОК.

Этот глюк вылез при переходе на Кейл. Под gcc такого не было. Программа уверенно работала. При переходе на кейл, начались глюки. Не очень мне нравится такое положение вещей. Глобальная переменная не должна меняться непонятно где. Не зависимо от ее размера. Очень неприятное впечатление.

Нужно будет попробовать как 4-й кейл будет себя вести, если тулчейн там другой.

Ладно.

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

ЗЫ
Блин любая глобальная переменная объявленная как байт произвольно меняет свое значение. Но только тогда, когда она используется в теле обработчика прерывания УАРТ.

Например если вот так в обработчике упомянуть переменную:

testwar=testwar

То она произвольно меняет свое значение. Если не использовать ее в обработчике все ОК. Похоже не все правильно сохраняется в стеке при входе в обработчик.

Реклама

HHIMERA

TDuke писал(а):Интересный глюк словил. Переменная объявлена глобально. Считает количество некоторых вхождений в функцию обработки прерывания

"Интересный глюк словил, оказалось, что забыл!"(С)
Идентификатор volatile А.С. Пушкин за вас присваивать будет???

Ещё и про атомарные операции почитайте... а то вдруг туманность Андромеды нахлынет...

Реклама

menzoda

TDuke писал(а):Блин любая глобальная переменная объявленная как байт произвольно меняет свое значение. Но только тогда, когда она используется в теле обработчика прерывания УАРТ.

Слушай, а ты через отладчик смотришь это, через окошко Watch, или просто наведя курсор? Что-то я припоминаю такое... Попробуй посмотреть через Memory, только сначала конечно узнай, по какому адресу располагается переменная. Был как-то у меня случай, тоже именно с однобайтовыми переменными, если я следил за их значением через окошко Watch, то получал белиберду, в действительности же все работало как надо и в Memory отображалось правильно. Действительно какой-то глюк был.

HHIMERA писал(а):Идентификатор volatile А.С. Пушкин за вас присваивать будет?

Читать за вас И. Ф. Крузенштерн будет?

TDuke писал(а):Так вот если эту переменную объявить как int8_t или uint8_t, то она самопроизвольно меняет свое значение. И пофигу ставлю я volatile или нет. Произвольно меняется и все.

TDuke

HHIMERA писал(а):
TDuke писал(а):Интересный глюк словил. Переменная объявлена глобально. Считает количество некоторых вхождений в функцию обработки прерывания
"Интересный глюк словил, оказалось, что забыл!"(С)
Идентификатор volatile А.С. Пушкин за вас присваивать будет???
Ещё и про атомарные операции почитайте... а то вдруг туманность Андромеды нахлынет...

TDuke писал(а):Так вот если эту переменную объявить как int8_t или uint8_t, то она самопроизвольно меняет свое значение. И пофигу ставлю я volatile или нет. Произвольно меняется и все.

Химера, я хоть здесь и новичок, вернее редко бываю и даже язык С юзаю не плотно, хотя уже много лет в общей сложности, в основном на диалекте Лиспа пишу, но императивные бяки еще не забыл полностью. Так что не нужно меня тут к ламерам причислять.

Ладно.
Чуток позже проведу исследования этого бага. Но в кокосе с gcc все работало. Это точно какой-то глюк.

Мне бы сейчас научиться исключения отлавливать. тоесть написать обработчик. А то у меня из процедуры отправки байтов в УАРТ выбрасывает в HardFault_Handler.

Реклама

Myp3ik

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

Реклама

TDuke

Скорее всего так и есть. Я слишком по быстрячку написал хендлер для УАРТ. Вполне мог забыть какой-то случай обработать.
Однако у УАРТ обработчик всего один. Все что случается с УАРТ сваливается в одно прерывание.

Реклама

TDuke

Нашел в Cети такое решение для обработчика HardFault:

Эта функция извлекает регистры прерванной по исключению программы из стека. Компилится нормально.

Код: Выделить всё

void prvGetRegistersFromStack( uint32_t *pulFaultStackAddress )
{
// These are volatile to try and prevent the compiler/linker optimising them
//away as the variables never actually get used.  If the debugger won't show the
//values of the variables, make them global my moving their declaration outside
//of this function.
volatile uint32_t r0;
volatile uint32_t r1;
volatile uint32_t r2;
volatile uint32_t r3;
volatile uint32_t r12;
volatile uint32_t lr; // Link register.
volatile uint32_t pc; // Program counter.
volatile uint32_t psr;// Program status register.

    r0 = pulFaultStackAddress[ 0 ];
    r1 = pulFaultStackAddress[ 1 ];
    r2 = pulFaultStackAddress[ 2 ];
    r3 = pulFaultStackAddress[ 3 ];

    r12 = pulFaultStackAddress[ 4 ];
    lr = pulFaultStackAddress[ 5 ];
    pc = pulFaultStackAddress[ 6 ];
    psr = pulFaultStackAddress[ 7 ];

    // When the following line is hit, the variables contain the register values.
    for( ;; );
}

А вот следующая часть с инлайн асмом не хочет:

Код: Выделить всё

// The prototype shows it is a naked function - in effect this is just an
//assembly function.
static void HardFault_Handler( void ) __attribute__( ( naked ) );

//The fault handler implementation calls a function called
//prvGetRegistersFromStack().
static void HardFault_Handler(void)
{
    __asm volatile
   (
        " tst lr, #4                                                \n"
        " ite eq                                                    \n"
        " mrseq r0, msp                                             \n"
        " mrsne r0, psp                                             \n"
        " ldr r1, [r0, #24]                                         \n"
        " ldr r2, handler2_address_const                            \n"
        " bx r2                                                     \n"
        " handler2_address_const: .word prvGetRegistersFromStack    \n"
    );
}

Код под gcc. Компайлер ругается на это - "tst lr, #4", говорит, что не знает что такое lr.
В асме под АРМ я пока вообще не шарю. Но по докам lr он же r14. Однако после замены на r14 всеравно не компилится.

Как быть?

HHIMERA

TDuke писал(а):императивные бяки еще не забыл полностью.

А как же... откровения здесь и на ИзыйдиЭлектроникс???

А то через год я сам могу наколоться на ней, когда забуду что она делала.

???

Так что не нужно меня тут к ламерам причислять.

Я подумаю... над вашим предложением...

в кокосе с gcc все работало. Это точно какой-то глюк.

Или сломалось???

Достал меня кокос. После настройки конфигурации начал тупо выдавать внутреннюю ошибку. Решил я забить на это мазохистское чудо и поставий Кейл.
Но Кейл преподнес сюрприз.

Мне Кейл нравится... не жалуюсь...

Мне бы сейчас научиться

Да кто спорит...

Как это обойти? Подозреваю, что это в настройках компилятора. Но где?
Разобрался. У кейла свой компайлер не gcc. Подсказали на радиокоте, как правильно нужно делать. Нужно явно указать приведение типов

=======
А по поводу volatile... недочитал в спешке... да...

TDuke

Аааа!... понял! Обычный тролль) Я таких много видывал.

HHIMERA писал(а): А как же... откровения здесь и на ИзыйдиЭлектроникс???

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

HHIMERA писал(а):А по поводу volatile... недочитал в спешке... да...

после напыщенного выступления, успокоиться уже не может. Свое эго поднимать нужно.

Родной думаю у тебя может быть не меньше откровений в соответствующих ситуациях. А трындеть - не мешки таскать.
По теме ничего сказать не можем, но трындим в общем.

HHIMERA

TDuke писал(а):у тебя может быть не меньше откровений в соответствующих ситуациях.

Размечтался!!! Инфы в инете хватает вполне... чтобы не сорить на форумах вопросами...

TDuke

HHIMERA писал(а): Размечтался!!! Инфы в инете хватает вполне... чтобы не сорить на форумах вопросами...

Ага, типа форумы, для частного закрытого общения считающих себя продвинутыми. А где спросить как не на форуме? Инфы хватает. А вот хрен ее найдешь сразу, и именно ту, что нужна. Мне легче спросить. Жадный или гордый, пройдет мимо, а нормальный скажет.

ЗЫ
Есть один форум в Сети, где намного толерантнее все к вопрошающим. О чем бы кто-не спрашивал. А все потому, что там модерация жестче. И горчичники выписываются без раздумий. Я там частенько отвечаю на простые вопросы. И мне и в голову бы не пришло искать посты спрашивающего, на другом форуме, чтобы потом упрекать.

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

ibiza11

TDuke, скинь свой проект, потестю у себя. Может что найду.

dosikus

TDuke писал(а):Аааа!... понял! Обычный тролль) Я таких много видывал.

Весьма характерное поведение для нуба :
просит помощи , и если нихрена не поймет (ее помощь) обсирает помогающего .
Ну дык не лучше ли, как обычно пнуть вопрошающего читать документацию , чем помогать ему ?

TDuke

О! Еще один!) Весма характерное поведение для защитника тролля. Вероятно они даже в друзьях.
Господа тролли! Помощь от троллей не исходит. От вас двоих тут никакой помощи и не было.
И помогают здесь те, кто не троллит. Вот Мурзик например. А некоторые просто болтают.

dosikus писал(а):просит помощи , и если нихрена не поймет (ее помощь) обсирает помогающего .

Что вы говорите? Ни одному помогающему я слова плохого не сказал. Наоборот благодарность выражал.
Нихрена не поймет? А что тут понимать? Вы и ваш подшефный тролль не сказали по сути ничего. Я понимаю, подсказали бы, как заставить работать под кейлом тот ассемблерный листинг, что я приводил. Ага. Дождешься. Тут некоторые только трындеть умеют. А ведь этот хендлер бы помог не только мне при отладке.

В общем тем кто попижониться сюда зашел или просто потроллить - просто говорю - не мешайте.

dosikus писал(а):Ну дык не лучше ли, как обычно пнуть вопрошающего читать документацию , чем помогать ему ?

Если бы кто-то таки пнул на нужную документацию, а не трындел бы здесь попусту.

Ладно. Продолжим.
Итак вернулся на gcc и кокос. Хендлер HardFault с инлайн асмом таки откомпилировал. Теперь из стека извлекается состояние регистров прерванной программы. А это оказалось вовсе и ненужным. Хендлер под кокосом вовсе не срабатывает. Нет у меня исключения шины под gcc. Нет и все. Тот же проект. Под кейлом IMPRECISE исключения шины.
В отладчике обнаружил самопроизвольное изменение индекса массива. Всякий мусор в переменной. Вот и вылетаем далеко за пределы оперативки. На этот раз даже не в обработчике прерывания. В обычной функции.

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

Вообще лучше один раз увидеть. Наверно сниму ролики трассировки под отладчиком кейла и странного поведения переменных. Так наверно лучше всего будет.

ibiza11

я предлагаю Вам выложить проект Кейл (обрежьте свой, если там такая серетная инфа), в котором 100% встречается этот глюк и дать другим потестить его. Может не в Кейле дело?
Ролики - дело хорошее, но не убедительное.

HHIMERA

TDuke писал(а):Итак вернулся на gcc и кокос.

Тогда к чему твой ламерский словопонос???
Тема Про Keil uVision 5 !!!
Не засоряй эфир!!!

menzoda

ibiza11 писал(а):я предлагаю Вам выложить проект Кейл (обрежьте свой, если там такая серетная инфа), в котором 100% встречается этот глюк и дать другим потестить его.

Поддерживаю, а то какое-то гадание на байтовой гуще.

TDuke

Ребята, я подумаю как вырезать глючный код. Потом выложу.

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

Снял скринкаст под 5-м кейлом и кокосом. Программа одна и та же. При поступлении прерывания вызывается глючный участок кода. Прерывания могу генерировать вручную. Под кокосом никаких глюков. Под кейлом глюк возникает через одно прерывание. Тоесть в одном нормально, а в другом, переменная произвольно меняет свое значение.

Переменная глобальная tx_wr_index, индексирует данные в кольцевом буфере УАРТ и никак не связана с тем кодом в котором выполняется.

Кроме того, поведение отладчика станное. При входе в цикл выполняется все тело цикла. А в следующих шагах, первая строка внутри цикла пропускется.

http://youtu.be/jsNs5OB52vA

Myp3ik

А если переключить оптимизацию в level0 ?

TDuke

Пробовал кажись. Иду поставлю именно 0 уровень.

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