В общем, понаблюдал, что происходит на пинах житага RST и TRST во время соединения с ядром.
На них ничего не происходит
То есть вообще ничего - активный уровень не появляется никогда! Ни при коннекте, ни при дисконнекте.
Дьявол
Понятно теперь, почему были проблемы...

Сброс при работе из JFlashARM.exe удалось запустить, установив value0 на 2:


Вот описание типов сброса из JLink User Guide:


Непонятно, почему не срабатывал тип 0 - по описанию это тот же тип 2, только с проверкой...

Скажите, какой тайный смысл предполагает данное действие? Экономия 80 мкА? На фоне поросёнка-PLL? Не смешите. Если бы Вы переходили не на PLL, а на LSE, например, это было бы понятно.


Возможно, проблема не в том, что "reference manual написан не очень доходчиво", а в том, что "по сравнению с другими" МК здесь более сложная периферия (возьмите хотя бы те же таймеры).
Сам я совсем недавно начал разбираться с stm32, до этого были str91, а до них - разные 8 битники, а также msp430. Но вот что я для себя отметил: это самый требовательный по отношению к разработчику МК. Я ни в коем случае не порекомендовал бы его для изучения начинающим. Данное замечание касается не ядра и задач ногодрыжства, а реальных задач, где необходимо задействование достаточно большого количества периферии. Многие вещи (в частности, распределение пинов, каналов ПДП) здесь взаимоисключающие, а так как периферии побольше чем у меги и она посложнее а также нет спасительного кроссбара как у силабсов , то уже на этапе рисования принципиальной схемы нужно четко представлять, что и как будет делаться, что программно, что через пдп, что через прерывания, что одним таймером, что несколькими с взаимной синхронизацией, каким именно таймером запустим АЦП и т.д.

А библиотеки у ST вполне нормальные. И разобраться с периферией во многом помогают.


А я наоборот - лезу в описание регистров только после того, как чего-то не понял в описании библиотек.
Да, быстрый ногодрыг через библиотеку получается плохо (как будет время - напишу о ногодрыге подробнее), но всё остальное, особенно инициализация периферии - сильно упрощается. Так что не изобретайте велосипед.

Не суть важно. Зато это помогло мне выявить баг МТ-Линка (или софта сеггера).


Бог с вами. Делайте, как считаете нужным. Я разве заставляю кого-то поступать, как я?

На форуме сеггера мне разъяснили, что у них в мануале ошибка.
По умолчанию (reset strategy 0) при коннекте эмулятора с ядром происходит сброс только ядра, без сброса периферии.
Только если подсоединиться таким образом не получается - и только тогда - ядро сбрасывается через пин Reset.

Так что если актуален "железный" сброс микроконтроллера перед программированием\отладкой - нужно устанавливать режим 2.

Ну вот я так и подумал что HSI остается выключенным "с прошлого" раза.
Иначе никак не объяснить что задержка перед процедурой выключения не помогала.
..вообще было в STM32 какое то узкое место где в дополнении к ресету глобальному приходилось реинитить вручную не то в юарте не то в идвацэ....

Спасибо, что подсказал. Я как-то и не подумал, что линия сброса вообще может не участвовать, так сказать, в процессе.
Поэтому в этом направлении и не копал

Тут вот возник у меня вопрос по прерываниям в STM32.

По NVIC - я понял так, что по завершении обработчика какого-либо прерывания не нужно ручками сбрасывать pending interrupt бит? Он сбрасывается автоматически?
Однако, применительно к контроллеру EXTI (external interrupts from GPIO pins) pending бит необходимо сбрасывать вручную. Об этом говорится в руководстве, но я, почему-то, сначала попробовал этого не делать и получил цикличный вызов обработчика EXTI без остановки... при этом у контроллера хватило сил ещё и достойно главный цикл обслуживать (непонятно, каким образом, правда)...

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

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

Если у всех прерываний приоритет одинаков они действительно не будут вызываться друг из друга. Я с этим налетел на здоровенные грабли.
Пытаясь разрешить вложенные прерывания в _изначально_заточенном_под_это_контроллере (NVIC) я понял что сделать это в полной мере и без обмана нельзя.
То есть да, прерывания изначально разрешены сразу при входе в обработчик прерывания , но только с большим приоритетом. И обойти это получилось только
с помощью асм враппера. Метод на том же форуме ST обсуждал до посинения

1. Тут я не совсем понял...
То есть сброс pending бита (защёлки?) происходит сразу при входе в прерывание, или только по выходу из него? Что-то в документации про это не нашёл...
А почему я спросил - у меня получилась интересная фишка с обработчиком прерывания от EXTI такого вида:

То есть при входе сразу сбрасываем pending бит.
Если вторую строчку оставить закомментированной - то после выхода из обработчика он вызывается ещё раз.
Получается переменная rpm_raw[0] увеличивается на два раза, когда должна только на один.
Если раскомментить строчку со сбросом pending бита NVIC - то всё нормально.
Получается, что сброс происходит сразу по входу в обработчик, и, если источник прерывания всё ещё активен - тут же устанавливается снова?

2. А зачем враппер был нужен? Ведь можно было установить различный приоритет для вложенных прерываний?
Их даже динамически можно менять - хоть прямо в обработчике?

сброс pending бита NVIC происходит сразу по входу в прерывания , во всех типах прерывания(механизм общий аппаратно). Но в EXTI источник прерывания не сбрасывается при сбросе пендинг бита(вручную), и получается как раз такой механизм как вы описали - вы сбрасываете источник , но после этого нужно сбросить и пендинг бит который только что выставился .
теперь домыслы которые подкреплены прочитанным на форуме арма:
Все это "вокруг" того чтобы не потерять последнее состояние входа. Во первых разработчикам камня упрощается жизнь в том что не надо реагировать на короткие пики (с момента выставления источника до момента его сброса как минимум пройдет время входа в прерывание). А во вторых для разработчика ПО эффект задумывался как раз противоположный наблюдаемому Вами : вы видите два входа в обработчик вместо одного , а можно видеть один вместо двух. Разположив сброс источника после чтения статуса входа не пропустим его последнее состояние, но дополнительного вызова прерывания не будет.

мне надо было организовать неограниченную вложенность прерываний самих в себяк примеру так

и друг в друга .
Выяснилось что манипулируя приоритетами это сделать не возможно в данном ядре.
NVIC постоянно проверяет приоритет прерывания которое пытается исполниться и текущий системный приоритет. Если мы в обработчике прерывания, то этот приоритет он берет из таблицы описателей прерываний. и получается, что меняя приоритет прерывания находясь в нем мы меняем оба числа и слева от знака неравенства и справа.
для верности я попробовал использовать пустой слот прерывания - выставлять ему приоритет наивысший , вызывать его искуственно , и выставлять низший приоритет... и получил хард фаулт эксепшн неизвестной природы, который мне не смогли объяснить в сапорте ST.
Так что без асм враппера не удалось обойтись. Кстати , если у кого есть сакральные знания на эту тему - прошу меня поправить.

Подскажите как подключить программатор на FTDI2232 к IAR 5.3.
Схема собрана как Luminary EvalBoar, еепром залил как Luminary. В результате в CrossWorks все работает.

В IAR при выборе дебагера LMI FTDI:
Fatal error: **ERROR**: Unable to open device 0x00000001 и т.д.

А при использовании выложенного выше openocd_ftdi_iar.exe,при загрузке openocd ругается что нет cygwin1.dll. Установил WinARM, стал ругаться, что нет точки входа в процедуру getreent в cygwin1.dll.

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

Сообщение отредактировал Student Pupkin - Mar 23 2009, 22:08

Да.

Кто-нибудь реализовывал управление моторами на сабж? Вроде он под это заточен. Интересует помехоустойчивость ядра к коммутационным помехам и некоторые особенности реализации петель ОС с использованием энкодеров (квадратурных и абсолютных).

говорить что реализовал рано, но уже замыкал петлю обратной связи, управляю Н-мостом електродвигателя пос.тока в рулевой машинке для авиамоделей в которой выкинуты потроха, на валу потенциометр -> АЦП -> ШИМ -> Н-мост. както оно заработало, но еще не отлажено. даже еще ПИД не запрограммирован.

просто квадратурные энкодеры PEC12- вешали на пины и опросом... работает.

Делал макет корректора мощности (около 400Вт) на STM32 и из-за неправильной ОС во время отладки создал такие помехи вокруг, что вся электроника (мультиметры, часы, термометры и т.д.) на расстоянии полуметра начинала жить своей жизнью. Но STM32 в центре всего этого бардака продолжал гнуть свою линию даже не моргнув глазом.