STM32vlDiscovery.
Простейшая конструкция - просуммировать элементы массива.

Не хочет работать, виснет в теле цикла, причем в отладчике, пошагово,
все работает как надо.
В чем дело, мозг сломал.
Подскажите, пожалуйста, куда копать?

Сообщение отредактировал domowoj - Mar 22 2015, 19:31

Так писать нельзя:
uint16_t GAME[m]={19,64,32,64,64,32,32,64,64,32,64,32,64,32,32,64,64,32,1152};
Вместо [m] должна стоять константа или оставьте скобки пустыми:
uint16_t GAME[]={19,64,32,64,64,32,32,64,64,32,64,32,64,32,32,64,64,32,1152};

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

Конструкция, может быть, и законна, но едва ли m соответствует числу элементов - иначе бы цикл не зависал.
Отсюда и мой совет оставить скобки пустыми, чтобы компилятор сам сосчитал число проинициализированных элементов.

А почему же в отладчике работает, когда шагаешь.
Кстати, размер массива ранее определен(первый пост отредактирую) .
И еще, та же самая конструкция успешно работает в STM32F3Discovery!

Если бы элементов было больше чем m - была бы ошибка компиляции. Если бы элементов было меньше - компилятор заполнил бы остаток массива нулями. При проходе по массиву самое страшное, что могло бы случиться - выход за пределы массива. А это привело бы либо к суммированию дополнительного мусора, либо к исключению, но не к зависанию. А поскольку в отладчике все работает - значит размер массива вычитывается из нулевой ячейки верно. В этом коде я криминала не вижу.
Интересно, а если этот цикл переместить в другое место - зависание будет снова в этом цикле? domowoj, а как определили, что зависание именно в цикле? Вообще, можно поподробнее о симптомах? Возможно неправильно настроены такты ожидания флеша и код улетает в исключение от неправильно считанного кода команды?

Просто из цикла программа не выходит.
А вот это как? Я этого делать не умею, подскажите, если можно.

Случаи, когда залезаешь в чужую память, под отладчиком часто работают нормально, потому как зависает оно обычно не тогда, когда в эту память пишется, а гораздо позже, когда выясняется, что попорчены адреса выхода из подпрограмм (стек возвратов). Увеличили бы вы размер стека - глядишь и баг бы пропал.


Все равно осталось неправильно, т.е. у вас m сперва используется как константа, а ее значение определяется позже.


У другого контроллера и память может быть распределена иначе.

А как это сделать?

У IAR'а это в Option.

А в Keil?

А Keil я не понимаю.

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

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



это че за хрень? без типа? описание типа какое?

Не знаю, что такого в этой процедуре, что может стек поломать...

Отключите оптимизацию, и воткните в тело цикла что-то вроде printf("I=%d\n",i); И посмотрите, на каком шаге виснет...



И это тоже согласен.

Вы можете поставть две точки останова: одну до цикла, вторую после цикла?

1. И когда, по вашему представлению, программа зависнет на выполнении цикла, остановть ее (нажать "паузу" или что-то там в Кайле нажимают) и посмотреть на переменную цикла и на сумму.

2. Попрбуйте поиграть с количество итераций цикла. Задайте в цикле просумировать один элент. Два элемента. Пять элементов... Просто попробуйте набрать статистику зависаний.

3. Кроме этого цикла, программа какие еще действия делает? Особенно интересуют какие прерывания Вы используете. Я к чему это говорю -- к тому, что возможно во время работы (конкретно -- во время выполнения этого злополучного цикла) возникает прерывание и оно как-нибудь не правильно обрабатывается. например, тупо не снимается флаг прерывания, который должен сниаться программно. Я не знаю, никто не знает что там у Вас происходит. Но наиболее вероятные версии нужно отработать -- проверить. Всё равно что-то делать надо.

4. Что еще могу предложить -- если есть осциллограф, то предлагаю вписать в тело цикла команду дергания какой-нибудь свободной ножки проца. и осциллографом попробовать уловить сколько итераций совершает цикл. Может быть он лупит бесконечность, а модет слелает пару-тройку и процесс уходит в обработку какого-нибудь прерывания.