В общем нашёл я причину нестабильной записи/стирания флеш памяти контроллера отладчиком МТ-Линк.

Это была строчка кода в моём стартапе, которая, после переключения ядра на PLL, отключала питание внутреннего RC генератора (HSI). Типа за ненадобностью.

Выкинул это из кода - загрузка программы в камень попёрла без сучка и задоринки!

Вот блин. Но ведь отладчик подключается к камню после сброса, когда HSI генератор работает по-умолчанию!? Видимо, на самом деле это не так.

ЗЫ:А пойду-ка я спрошу на форуме сеггера, что за фигня такая с их отладчиками...
Авось не сразу выгонят с моим клоном

ЗЗЫ: Flash access control register (FLASH_ACR) вообще нужно программировать? Это где задержки для доступа к флеш памяти находятся?
А то камень работает на 48 МГц, а я совсем про этот регистр забыл. Туда ведь в этом случае надо записать 1 (один цикл ожидания)?

поздравляю что разобрались!
у меня была похожая проблема после включения WD в первых строках программы оный не позволял залить ни по жтагу ни по SWD ничего во флэш , хотя СВД должен уметь подцепляться !даже! с активным уровнем ресета. после определенного момента (с выходом очередных дров от Сеггера) фича пропала . так что "документированная ошибка - это не ошибка а особенность работы ПО"

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

Спасибо!
Оказывается, при записи или стирании флеш в STM32 надо, чтобы работал HSI. Об этом как-бы невзначай написано в STM32F10xxx Flash programming manual, но ни черта нет в разделе Reset and clock control (RCC) референсного мануала. Точно документацию у ST пишут какие-то индейцы
Весьма невразумительная штука

Я не пользуюсь функциями фирменной либы (наверняка они не менее невразумительные, чем их документация). Сам разбираюсь.
Заюзал вчера Flash access control register (записал единичку), осциллограмма импульсов (приведённая выше) стала ровной - полупериоды теперь равны друг другу. Ну и частота импульсов упала немного, конечно.
Однако в комнатных условиях этот камень работает на 48 МГц и безо всяких задержек.
Тем не менее тоже не вижу причины насиловать железку

Одним глазком увидел Ваш вопрос на форуме СТ. и хотя Вам не ответили (пока) - раз вы разобрались может поясните?

Каким образом пауза в 800 ms между ресетом и выключением HSI не способствует корректной работе , тогда оставленный "на совсем" включенным HSI способствует?
Jlink позже коннектиться к ядру нежели 800 милисекунд после собственноручно выданного ресета ?
Если я что то не правильно понял поясните , если не трудно.

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

Насчёт HSI генератора я и сам не понял, почему так происходит. Поэтому и спросил на других форумах. К сожалению, ответа нет до сих пор...
Дело такое (ещё раз): во время инициализации, после переключения на PLL, я полностью отключал внутренний HSI генератор.
В этом случае МТ-Линк v5.0 под управлением дров сеггера последней версии (и не только последней версии) при попытке записи во флеш выдавал ошибку - таймаут стирания/записи. Это происходит из-за того, что HSI в это время всё ещё выключен, и по каким-то причинам не был включен после коннекта эмулятора.

После ошибки эмулятор автоматически дисконнектится. Если повторить попытку записи - то всё пишется\сверяется без проблем.
НО ТОЛЬКО СО ВТОРОГО РАЗА. И введённая мной задержка в 800 миллисекунд (после сброса и до команды отключения HSI) никакого эффекта не дала.

Это мне тоже не понятно.
В настройках reset strategy установлено hardware, halt after reset (normal). Пробовал как с задержкой (30 ms), так и без.

Ещё что заметил - запускаю JFlashARM.exe. Выбираю из меню ->Connect:

Подключились, ядро остановлено. НО - был ли активен reset? У меня к микроконтроллеру подключен ЖКИ, который (если бы контроллер был сброшен и его пины перешли бы в начальное состояние) тоже бы сбросился и очистился. Однако этого не происходит

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

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

В общем, понаблюдал, что происходит на пинах житага 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к или же можно только писать набольшие приложения под предлагаемую ось?

Да.

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

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

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

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

Моторами не управлял, но инвертор на 6 кВт делал. Двухслойная плата с земляным полигоном. Помехоустойчивостью весьма доволен.

Имеется ли в семействе STM32F103x возможность прошивки внутренней флэши (имеется ввиду "чистая" микросхема) через последовательный порт ?

конечно

Спасибо, еще один вопрос

Обнаружил в терраэлектронике - Встраиваемый модуль TE-STM32F103 "Махаон" http://www.terraelectronica.ru/news_postup.php?ID=1669
Одна из фич
"Модуль содержит аппаратный мост USB-UART на базе микросхемы FT232RL,
который позволяет загружать код программы во внутреннюю память (SRAM) микроконтроллера."

Этот bootloader где-то имеется в свободном доступе или это проприетарный код терраэлектроники?

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

Да я не про прошивку спрашиваю, а про некий предварительно прошитый (пользователем) мониторчик, который позволяет грузить программу через последовательный порт прямо в внутреннюю SRAM.

А зачем Вас загрузка именно в SRAM интересует?
Что-то я не почувствовал такой необходимости в процессе работы.

Устройство после включения должно загружаться с компьютера. Прошивать флэш при каждом включении процессора "некрасиво".

Читайте AN2606 http://www.st.com/stonline/products/literature/an/13801.pdf и будет почти все понятно, а что непонятно можно найти на форуме поддержки на сайте ST.

А USB загрузчик для STM32 никто не встречал?
...чтоб как у ATMEL SAM7

А то что у них на сайте лежит
DfuSe USB Device Firmware Upgrade STMicroelectronics Extension
это не подходит?

Упс, просмотрел как-то.
Спасибо.

Я как раз использую DFU. Отлично работает

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

Программа копирует себя в RAM, и оттуда шьет флеш.

Понятно, спасибо. Тогда интересно, STM32 всегда копираует часть кода в RAM для выполнения или если только его попросить об этом, и описан ли этот процесс где-то в документации или это можно увидеть только из примера программы DFU?

Столкнулся с тем, что кейл не поддерживает inline ассемблеровские вставки в Thumb режиме. Как-нибудь это можно обойти ? Что бы избежать лишних переходов при использовании функций в которых всего-то пара команд.

На кортексе нет тамб или аэрэм режимов, у него всегда thumb-2.
Чем не устраивают inline функции?

Я писал не про кортекс, а про компилятор.



Вы меня не поняли, поясню на конкретном примере.
Для arm можно было записать так:

static __inline int FASTABS(int x)
{
int t=0;
__asm {
eor t, x, x, asr #31
sub t, t, x, asr #31
}
return t;
}
А что делать для thumb чтобы получить тот же результат ?

Причем здесь компилятор?
Надо взять ARMv7-M Architecture Application Level Reference Manual
там есть все команды, которые поддерживаются в THUMB2

А вы попробуйте откомпилировать приведённый мной код, тогда узнаете.


А это здесь причём ???

Повторю вопрос: как заинлайнить выше приведённый код в кейле в случае компиляции под THUMB2 ?

Не знаю как в KEIL, а полноценный RVCT от RVDS не умеет использовать inline asm для THUMB и THUMB2. Нужно использовать embedded asm примерно так.

но тогда функция не будет inline.
Но вот если gcc использовать тут можно уже расширенный асм использовать.

ДОБРЫЙ ДЕНЬ !
Вот сейчас начал изучать STM32F103RET6 был очень рад наличию у него двух 12 битных АЦП но радость пропала когда узнал что в курпусе LQFP-64 не выведены пины под истоники опорного нпаряжения Как спрашиваеться опираясь от общего питания АЦП (VDDA) пожно добиться путевой точности ?? И еще интересный факт как я не перерывал документацию я не нашел ток который потребляеть по выводу VDDA два АЦП и два ЦАПа вместе тоесть в попытке всетаки улудщить аналоговое питания посколько оно же и опорное напряжение есть удея поставить туда чтото типа REF3033 но вот не задача нигде не написано сколько это все будет кушать!! И не просядить ли источник опорного напряжения!! Зато сказано сколько потребляет от VREF мах 220мкА но а сколько остольное кушает кто нить знаеть ??? или может померить ???

asen

Страницы 52,53 даташита: DAC - 0.72mA, ADC1 - 1.9mA, ADC2,3 - 1.7mA.

Спасиб чтото пропустил

Для этого есть внутренняя опора. Оттдельно измеряйте ее и корректируйте результат измерения внешнего канала.

продолжаю делится впечатлениями....

доделал проект моста USB<->Arinc 429 RX/TX жужжыт на скорости 100кbs

порадовал время(стабильность) входа и выхода из прерываний, после LPC2148 просто глоток воздуха
порадовал bit-band, но както пока низнаю куда его применить.
до 120 мгц гонится и работает, дальге не помню что происходит.
сильно вперед продвинутый набор инструкций, если правильно писать на си уметь!! то асм непонадобится. получил код обработчика прерывания от компиллера в который руками некуда залесть! на каждую строку с-кода 1 2 или 3 инструкции. лепота.

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

огорчило что к тактовой USB нельзя присунуть делитель отличный от 1 и 1,5. так могли сделать только враги!!!
огорчили таймеры, 16 бит..... просто фашисты, всю малину обгадили

ктонит RS485 уже реализовывал?

Радует хотя бы это. На SAM7S вообще кроме х1 ничего нет

Кстати, хотел спросить про макс. частоту SPI.
С какой бы это стати в мануале указана частота 18 МГц?
Что помешает SPI1, висящему на APB2, работать на частотах вплоть до 36 МГц?

Ведь делители такое позволяют? Никто не пробовал?

Я делал (по прерыванию, без DMA). Все достаточно просто и прямолинейно. Хотя маленькая ложка дегтя - отсутствие аппаратного управления направлением передачи.

я прально понимаю что прерывание tx complite используете для передергивания выводом порта 485-микруху в режим приема для отпускания шины? Если так то не сильно криминально.