Пытаюсь таки впервые в жизни отладку при помощи gdb попробовать (т.к. непонятно в каком месте кода у меня явно вызывается hardfault, скорей всего, из-за невыровненного обращения к чему-то, т.к. на STM32F103 тот же самый код прекрасно работает). И как только подключаю USB, у меня ни прошивка через st-link не работает, ни отладка. Вот, что пишет openocd на это:

Отключал питание от st-link, чтобы только от USB было - не помогло. Пробовал другой st-link - тоже 0 реакции. st-link - обычный, с алиэкспресса за полтора или два бакса (не помню уж, почем брал).
Кстати, еще один глюк этого st-link:

Постоянно пишет, что не может определить тип флеша (но при этом МК прошивается и отладка без USB работает), а также постоянно пишет "NRST is not connected", хоть я и соединил NRST чипа и st-link. Может, ему нужно внешнюю подтяжку к NRST, чтобы он таки увидел, что "connected" (хотя, исходя из здравого смысла, проверка должна проводиться просто в режиме floating input, а выход RST прошивалки - подтянут к земле резистором в мегаом).

На тех свистках NRST для STM8, нужна доработка.

Reflector, что-то подозрительно это выглядит: ведь там предлагают ногу NRST камня из st-link соединить с NRST своего!

В общем, раскопал я старый st-link (который с jtag) - он не отваливается, когда я подключаю USB, но у него нужно 3.3В с моей платы на Vapp подключать, чтобы работало.
Запустил отладку и понял, что она бесполезна: как я выловлю, что у меня происходит, если сразу после ввода определенных данных по USB камень уходит в blocking handler? Пошаговую здесь не запустишь, разве что breakpoint'ов понатыкать на стадии обработки введенных пользователем данных - ХЗ, в общем…

UPD, ан, нет, факир был пьян:

Не знаю, что там st-link'у не нравится, но чуть начал "шагать" по коду после точки остановки, как связь обломилась.

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

Код для отладуи в flash или sram запускаешь? Стек инициализировать не забыл? Ремап делал?

Выбираем схему BMS для заряда литий-железофосфатных (LiFePO4) аккумуляторов

Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.

Подробнее>>

Код из флеша, конечно - я в RAM никогда не переношу исполняемый код. Стек инициирован, ремапа нет. Ноги SWD ничем не заняты.
А ведь во время работы отладчика прерывания обязаны работать? Получается, что пока он пошагово дергает исполнение, каждую миллисекунду идет SOF, и ведь чип как-то на него может реагировать (помимо синхронизации таймера).

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

Ну и зря. В SRAM быстрее и удобнее отлаживаться. Что значит прерывания должны работать во время работы отладчика? Пока программа не остановилась на точке останова всё работает штатно. Во время останова никакой код, естественно, не выполняется. Но периферия то продолжает работать, флаги взводятся, счётчики тикают. SOF-ы вообще аппаратно обрабатываются.

Не понимаю как можно зафейлить USB-код при переносе с F103 на F0. Там разница только в ширине PAM-буфера и встроенном резисторе. Остальное бит в бит рабтает.

У меня собственно USB нормально работал, пока я не решил перенести код с кольцевым буфером, чтобы повысить скорость работы USB (вдруг где понадобится). И вот, когда стал распихивать функции по образу и подобию F103 и F303 (чтобы был эдакий костяк работы с USB, который легко под другие серии портировать, а не так, как было), то где-то, видимо, "очепятался" или ХЗ, что там еще. Но "в красивом виде" не работает, а "в некрасивом" - работает!
Конечно, частота здесь взяла свое: если на STM32F103 у меня жирный буфер отправлялся со скоростью чуть ли не в 9Мбит/с, то на F042 уже до 6Мбит/с не дотягивает. Возможно, если еще как-то по-уму обработать код (скажем, запускать отправку следующего пакета сразу по прерывании об отправке предыдущего), будет чуть шустрей, но у меня так не заработало (из-за того, что прерывание, внутренности которого неплохо так весят, вызывалось слишком часто). Я просто в суперлупе на каждый проход вызываю функцию, которая и проверяет - не нужно ли очередную порцию данных отправить.

И вообще, сделал уже несколько вариантов работы с USB, но вижу, что все еще совершенно неоптимально. Тот же кольцевой буфер нужно и на прием реализовать. И с CAN, наверное, так же сделать: увеличить буфер и работать по прерываниям, а не поллингом (хотя, на достаточно хорошо забитой шине с 250кбод я не встречал пропуска пакетов, но он вполне может быть - ведь F042 достаточно медлителен).
В общем, с такими запросами мне и 32кБ ОЗУ не хватит!..

Ставьте точку останова на HardFault_Handler и когда выполнение дойдет до него, смотрите историю вызова функций (Call Stack). Примерно как здесь http://purebasic.mybb.ru/viewtopic.php?id=564#p7599
Тогда узнаете всю цепочку вызова функций, которая привела в сбою.

Мурик, спасибо, попробую.
Ну, охренеть, убивается на делении вот здесь:

При этом другой код с точно такой же функцией нормально работает (да и много где оно у меня используется)!

Добавлено after 57 minutes 47 seconds:
Вот же япона городовой! Взял Makefile из другого места, заработало! Видать, что-то я левое там накорячил, что у меня софтовое деление не работало... Сейчас гляну.

Вот же япона городовой! Не добавил LD_FLAGS += $(ARCH_FLAGS)!

Добавлено after 31 minute 14 seconds:
Итак, спасибо Мурик. Ошибка была в делении: т.к. оно софтовое. Однако, т.к. я про[censored] в Makefile указание архитектуры линкеру (видать, слишком "наоптимизировал" Makefile), то деление, видимо, пыталось вызваться аппаратное → хардфолт.
ОК. В кои-то веки не без пинков от VladislavS и прочих я оценил возможности gdb. Теперь надо литературы по нему скачать и почитать, там много чего интересного есть.
Правда, косяки в работе самих real-time протоколов таким образом отладить будет сложновато (и уж точно без "отваливания" от линии связи на время отладки это никак не сделать). Вот если бы gdb умел условный трейс с мониторингом в файл писать (а может и умеет? надо читать).

Однако, все это не отменяет того факта, что никакой st-link не работает с моим STM32F042 (плата отсюда, просто первая попавшаяся под рукой была, я и решил к ней кольцевой буфер на USB прикрутить). Стоит лишь подключить USB, как make flash отваливается. И отладка буквально через несколько секунд после подвисания помирает с матюками вроде

Прикол чисто для информации: при использовании CMSIS от STшников вдруг обнаружил, что название векторов в таблице прописаны не все! То есть объявляю обработчик от условного компаратора, включаю прерывание, а процессор сваливается в default_handler, что сильно сбивало с толку. Будьте внимательны с файлами от производителя, там могут быть подвохи!

Работу части периферии можно приостанавливать при работе в прерывании в регистрах DBGMCU -> APBxFZ. Например, если таймеры работают парой ведущий-ведомый, то можно замораживать работу ведущего, выполняя под отладчиком код ведомого.

>TEHb<, я базу стартапа стащил из opencm3 и понемногу туда нужные мне камни вручную копипастил, сверяясь, чтобы имена обработчиков прерывания в духе предыдущих были.
А вот описания регистров и флагов брал от ST (еще из SPL, кажись, выдирал), и там кое-чего не было, приходилось вручную дописывать. Ну, тут хоть не так все плачевно, как с STM8: для них мне вообще пришлось заголовочный файл вручную формировать по мануалу. Благо, хоть регистров и флагов там негусто. Из SPL для STM8 выдрать нельзя было, т.к. оказалось, что дурной sdcc не оптимизирует, если ты к регистрам как к элементам структуры обращаешься (а кроме sdcc под STM8 компиляторов не существует).

Уже не один год есть бесплатный от самой STM. Они его у кого-то купили. Почитай.

tonyk, cosmic что ли? Разве оно под линуксом работает?
Ну, мне все равно пока не нужно. Я прикинул по производительности, периферии и ценам, и решил, что таки STM32F030 гораздо приятней, чем STM8. А уж если брать STM32F0x2, то будет еще и USB (причем, без необходимости напаивать кварц); да и CAN будет работать одновременно с USB (собственно, на STM32F042 я и делаю простейшие переходники CAN-USB, а на основе F072 — всякие железки, где периферия побогаче нужна). Вот только грусть-печаль, что нельзя F042 программно в DFU-режим загнать, как F072, приходится кнопочки "boot" и "reset" напаивать для программирования, либо выводить SWD (а это не всегда возможно).

В общем, выложил код на гитхаб. Теперь у меня есть вариант USB с двумя круговыми буферами (и на передачу, и на прием), причем отправку и прием очередной порции данных я запихал в прерывания (раньше это поллингом делалось). Правда, на STM32F042C6T6 время передачи данных уменьшилось совсем незначительно по сравнению с поллингом (т.к. слабоват он, приличное количество времени на накладные расходы по работе с буферами тратится, так что выше ~5.1Мбит/с никак не выходит). Надо будет проверить, улучшилось ли на F303 - вдруг все 12Мбит/с вытянуть получится?

P.S. Да, st-link так и продолжает отваливаться через какое-то время после подключения USB. Приходится для заливки прошивки или старта дебаггера сначала выдернуть USB-шнурок из платы, а потом уже его вставлять. Правда, дебаг длительный тоже не сделать: буквально через 5-10с после останова оно ругается на разрыв соединения.

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

Куда уж нативнее? gdb - нативней некуда!

удалось разобраться? у меня такая же беда с f105, когда включаю usb