Добрый день! А работать с этими процами под Linux в Эклипс+OCD+GCC... кто-нибудь уже пробовал?

На Techtrends 2008 анонсировали (пока неофициально - обещают официально выдать только в мае) расширение линейки STM32 как вверх - до 512 кБ FLASH и 64 кБ ОЗУ с кучей новых вкусностей, так и вниз до блох, сравнимых с ATmega88.
Предварительные доки выложил на ftp в /upload/DOCs/ARM/STM32/
и в пески
hччp://upload.caxapa.ru/STM32_ref_man.zip
hччp://upload.caxapa.ru/STM32F101xCDE.pdf
hччp://upload.caxapa.ru/STM32F103xCDE.pdf

Что-то у меня никак не получается связать Кейл и отладочную плату STM3210B-EVAL.
Имеется в наличии STM3210B-EVAL и USB J-Link иаровский.
Стоит RealView MDK-ARM v3.20, Segger J-Link ARM V3.80.
По отдельности все работает - кейл проект компиллирует, с помощью J-Flash hex-файл во флеш прошивается, программа работает (демо-пример).
А вот все вместе - никак.
В Кейле в Flash->Configure Flash Tools на вкладках Debug и Utilites установлено RDI Interface Driver, длл-ки указаны не кейловские, а сеггеровские ( в обоих случаях JLinkRDI.dll).
Если делаем Start/Stop Debug Session задумывается на пару минут, потом выбрасывает в окно Disassemly
А грузить и стирать флеш из Кейла вообще не хочет. Что я забыл настроить?

У меня проблема с компиляцией проектов для STM32F103 - использую Keil MDK v. 3.20 при компиляции примеров от Keil получаю ошибку:

STM32F10x.s: error: A3903U: Argument 'DARMSTM' not permitted for option 'device'.

Подскажите, пожалуйста, что не так сделал.....

Может кому-нибудь пригодится: ошибка была в лиценции к Keil - стояла "RealView MDK Enterprise" - с ней проект не компилировался, сменил на "RealView MDK Professional" и всю заработало....
Даже не понятно почему такая разница в лицензиях...

Запустил АЦП на отладочной плате STM3210B-EVAL. Показания плавают в пределах +-5LSB. Выходит, что по точности не больше 10-ти разрядов. Кто испытывал АЦП поделитесь впечателниями.

Сообщение отредактировал gregory812 - May 9 2008, 08:02

Имеется STM32F103RBT6 (на плате от Olimex STM32 P103) и МТ-Линк (версия железа 5.0, серийник 11111117).
Почему-то дебаггер заливает прошивку в контроллер через раз.
То есть соединение всегда проходит на ОК, но вот дальше дебаггер обязательно споткнётся на стирании, или на записи страницы. Выдаётся сообщение о таймауте стирания или записи...
Причём если сразу-же повторить попытку - то запись и проверка записи завершаются успешно.

Юзал заливку из под JFlashARM из пакета дров сеггера (версия 4.0), так и из под кейла MDK3.40.
Скорость соединения выставлял от 5 до 200 килогерц - без разницы.

В этом топике тоже пишут про "пляски с бубном" с дебаггером - это что, у всех так?

Причём вот что интересно - до этого юзал этот-же дебаггер с самопальной платой с LM3S601 - ни одной проблемы с дебаггером! Запись, стирание, проверка - быстро и чётко, без запинок.

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

А в STM32 разве нет возможности обращаться к периферийным регистрам через бит-бэнг области?
Что-то в мануале не нашёл упоминаний...
Почему-то показалось, что такая фича есть у всех кортексов, а не только у Stellaris...

ЗЫ: А, сорри, нашёл! Уря, я просто перепутал, когда искал - правильно пишется "band", а не "bang"...

Год почти полет нормальный. в том числе и на пятой версии j-линка и Мтлинка (дебаггер - ИАР)
а Вы что под дебаггером подразумеваете ?
Пляски были, не отрецаем,- но плясали вокруг GDB сервера и(или) SWD, кажется , а если работать напрямую и не по СВД ,то там все как часы.

Дебаггер - МТ-Линк
Кейл с ним работает через RDI.
Хотя, если пробовать через родную JFlashARM.exe - то запись во флеш тоже через раз. Не знаю, JFlash работает через RDI или напрямую?

Посмотрел по логам - сложилось впечатление, что дело такое:
1. Сначала в оперативу контроллера заливается код "прошивальщика".
2. Потом с ним ведётся многократный обмен данными путём перезаписи регистров и рестарта кода.
Вероятно, здесь идёт стирание нужных страниц флеш.
После окончания обработки данных код стопорит ядро и таким образом даёт знать ожидающему дебаггеру о возможности продолжения "диалога"
3. Только теперь ему начинает передаваться код программы для флеш в виде кусков определённой длинны.
4. Считывание флеш и верификация записи.

Зависание происходит на втором этапе. То есть до передачи данных для записи дело не доходит.
Перестаёт отвечать "прошивальщик". Спрашивается - какого хрена?

Было-бы интересно посмотреть, что происходит "внутри" кода загрузчика? На чём он стопорится?
Но как это сделать? Есть где-нибудь его исходники?

По схемотехнике JTAG вроде у Олимекс STM32-P103 всё в порядке - все подтягивающие резисторы на месте.


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

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

Это была строчка кода в моём стартапе, которая, после переключения ядра на 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?
Просто написан он не очень доходчиво, по сравнению с другими.
Поэтому вполне можно разобраться с работой периферии по описанию её регистров.
Мне пока что ни разу не пришлось лезть в код библиотеки.
Тем более после прочтения нелестных отзывов про неё на этом форуме...