[sonycman 0]

В общем, понаблюдал, что происходит на пинах житага RST и TRST во время соединения с ядром.

На них ничего не происходит :cranky:

То есть вообще ничего - активный уровень не появляется никогда! Ни при коннекте, ни при дисконнекте.

Дьявол :angry2:

Понятно теперь, почему были проблемы...

 

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

 

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

5.2.2 Cortex-M3 specific reset strategies

J-Link supports different specific reset strategies for the Cortex-M3 core. All of the

following reset strategies are available in JTAG and in SWD mode. All three reset

strategies halt the CPU after the reset.

5.2.2.1 Type 0: Normal

This reset strategy is the default strategy. J-Link tries to reset the core via reset

strategy 2 first. If this fails, reset strategy 1 is performed. It is recommended to use

this reset strategy to reset the target.

5.2.2.2 Type 1: Core

Only the core is reset via the VECTRESET bit. The peripherals are not affected.

5.2.2.3 Type 2: ResetPin

J-Link pulls its RESET pin low to reset the core and the peripherals. This normally

causes the CPU RESET pin of the target device to go low as well, resulting in a reset

of both CPU and peripherals. This reset strategy will fail if the RESET pin of the target

device is not pulled low. The CPU does not start execution of the program because JLink

sets the VC_CORERESET bit, which causes the CPU to halt before execution of

the first instruction.

 

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

[koyodza 0]

во время инициализации, после переключения на PLL, я полностью отключал внутренний HSI генератор.

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

 

Что касается библиотек и документации - почему-же, документация есть и в полном виде - как же reference manual?

Просто написан он не очень доходчиво, по сравнению с другими.

Возможно, проблема не в том, что "reference manual написан не очень доходчиво", а в том, что "по сравнению с другими" МК здесь более сложная периферия (возьмите хотя бы те же таймеры).

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

 

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

 

Поэтому вполне можно разобраться с работой периферии по описанию её регистров.

Мне пока что ни разу не пришлось лезть в код библиотеки. :laughing:

Тем более после прочтения нелестных отзывов про неё на этом форуме...

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

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

[sonycman 0]

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

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

 

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

 

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

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

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

:rolleyes:

[sonycman 0]

В общем, понаблюдал, что происходит на пинах житага RST и TRST во время соединения с ядром.

На них ничего не происходит :cranky:

То есть вообще ничего - активный уровень не появляется никогда! Ни при коннекте, ни при дисконнекте.

Дьявол :angry2:

Понятно теперь, почему были проблемы...

 

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

 

На форуме сеггера мне разъяснили, что у них в мануале ошибка.

По умолчанию (reset strategy 0) при коннекте эмулятора с ядром происходит сброс только ядра, без сброса периферии.

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

 

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

[cebotor 0]

На форуме сеггера мне разъяснили, что у них в мануале ошибка.

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

Ну вот я так и подумал что HSI остается выключенным "с прошлого" раза.

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

..вообще было в STM32 какое то узкое место где в дополнении к ресету глобальному приходилось реинитить вручную не то в юарте не то в идвацэ....

[sonycman 0]

Ну вот я так и подумал что HSI остается выключенным "с прошлого" раза.

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

..вообще было в STM32 какое то узкое место где в дополнении к ресету глобальному приходилось реинитить вручную не то в юарте не то в идвацэ....

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

Поэтому в этом направлении и не копал :rolleyes:

 

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

 

По NVIC - я понял так, что по завершении обработчика какого-либо прерывания не нужно ручками сбрасывать pending interrupt бит? Он сбрасывается автоматически?

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

 

И ещё вопрос - по-умолчанию у большинства прерываний одинаковый приоритет после сброса - 0.

Означает ли это, что все обработчики будут вызываться строго по очереди?

То есть не будет вложенных прерываний (так как для этого нужен больший приоритет, а он одинаковый)?

[cebotor 0]

По NVIC - я понял так, что по завершении обработчика какого-либо прерывания не нужно ручками сбрасывать pending interrupt бит? Он сбрасывается автоматически?

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

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

при срабатывании защелки прерывание будет "перевызвано" после выхода.

И ещё вопрос - по-умолчанию у большинства прерываний одинаковый приоритет после сброса - 0.

Означает ли это, что все обработчики будут вызываться строго по очереди?

То есть не будет вложенных прерываний (так как для этого нужен больший приоритет, а он одинаковый)?

Если у всех прерываний приоритет одинаков они действительно не будут вызываться друг из друга. Я с этим налетел на здоровенные грабли.

Пытаясь разрешить вложенные прерывания в _изначально_заточенном_под_это_контроллере (NVIC) я понял что сделать это в полной мере и без обмана нельзя.

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

с помощью асм враппера. Метод на том же форуме ST обсуждал до посинения :)

[sonycman 0]

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

при срабатывании защелки прерывание будет "перевызвано" после выхода.

 

Если у всех прерываний приоритет одинаков они действительно не будут вызываться друг из друга. Я с этим налетел на здоровенные грабли.

Пытаясь разрешить вложенные прерывания в _изначально_заточенном_под_это_контроллере (NVIC) я понял что сделать это в полной мере и без обмана нельзя.

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

с помощью асм враппера. Метод на том же форуме ST обсуждал до посинения :)

1. Тут я не совсем понял... :unsure:

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

А почему я спросил - у меня получилась интересная фишка с обработчиком прерывания от EXTI такого вида:

void    EXTI0_IRQHandler()
{
    EXTI->PR    |=    0x01;
//    NVIC->ICPR[0]    |=    (1 << 6);
    rpm_raw[0]++;
}

То есть при входе сразу сбрасываем pending бит.

Если вторую строчку оставить закомментированной - то после выхода из обработчика он вызывается ещё раз.

Получается переменная rpm_raw[0] увеличивается на два раза, когда должна только на один.

Если раскомментить строчку со сбросом pending бита NVIC - то всё нормально.

Получается, что сброс происходит сразу по входу в обработчик, и, если источник прерывания всё ещё активен - тут же устанавливается снова?

 

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

Их даже динамически можно менять - хоть прямо в обработчике?

[cebotor 0]

1. Тут я не совсем понял... :unsure:

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

..........

Если раскомментить строчку со сбросом pending бита NVIC - то всё нормально.

Получается, что сброс происходит сразу по входу в обработчик, и, если источник прерывания всё ещё активен - тут же устанавливается снова?

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

теперь домыслы которые подкреплены прочитанным на форуме арма:

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

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

Их даже динамически можно менять - хоть прямо в обработчике?

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

systick_ISR
{...  
       systick_ISR
       {...   
             systick_ISR
             {
             }...
       }...
}

и друг в друга .

Выяснилось что манипулируя приоритетами это сделать не возможно в данном ядре.

NVIC постоянно проверяет приоритет прерывания которое пытается исполниться и текущий системный приоритет. Если мы в обработчике прерывания, то этот приоритет он берет из таблицы описателей прерываний. и получается, что меняя приоритет прерывания находясь в нем мы меняем оба числа и слева от знака неравенства и справа.

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

Так что без асм враппера не удалось обойтись. Кстати , если у кого есть сакральные знания на эту тему - прошу меня поправить.

[Ivan79 0]

Подскажите как подключить программатор на 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.

[Student Pupkin 0]

получил демо плату PRIMER http://www.st.com/stonline/products/literature/bd/13942.pdf, круглая такая. Поставил Raid7, загрузил тестовый проект. Все дебажится, компиляется, GNU gcc-frendly, все бесплатно... короче меня вштырило. наверно на кортексы ползти начну. во всяком случае стало интересно. за 3 минуты без денег и борьбы началась внутрикристальная отладка. отраслевой прогресс налицо.

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

Изменено 23 марта, 2009 пользователем Student Pupkin

[zltigo 1]

В этой штуковине ограничение по объему только для отладки?

Да.

[khach 36]

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

[klen 1]

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

 

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

 

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

[gr9 0]

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

 

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