Форум РадиоКот

Уже вторую неделю происходит чудное. Keil, питание через ST-LINK платы, простейшие операции манипуляции GPIO не приводят к результатам. Вернее - через 5 раз на 6й. Порт какой - неважно, операции вывода, подтягиание пробовал разное, нагрузка светодид с резистором. Ноги, идущие на ST-LINK - не трогаю. Резервированные - тем более. Поначалу убивал платку (видимость с компа), приходилось делать erase через утилиту.
Простые операции битового вывода с SPL. Ситуации: один бит переключается, меняю в коде номер пина на том же порте- и все, новый назначенный не работает! Возвращаешь - первый работает. Какие то порты/пины - работают, какие-то нет, причем работал/работал, перевел вывод на другой пины, а когда вернул - первый не работает. SPL уже излазил. Дай, думаю, попробую на CubeMX? Заработали все 14 назначенных!!! Через таймаут ставлю им же все Reset - не гаснут!
Комментирую строки, иду по отладчику - на включение уже перестали работать, причем в BRR пишется нужная единичка!!! Т.е. в коде НИЧЕГО не поменял - включаться уже перестали! И так на двух компьютерах!
Код не привожу, инициализация инфраструктуры после разрешения тактирования и задание бита в 0/1. Дальше кнопки даже не ходиллл!!!!
Такое впечатление, что отладчиком хожу по какому-то виртуальному устройству, а не по реальной плате! Хотя ота реагирует миганием на заливку.

Спустя четверть века полного отсутствия в профессии (профильная была), решил опробовать девайс, чтобы понимать его возможности в промавтоматике... 2 недели учу матчасть и пробую, пробую, но явно чего-то еще и просто идет нестандартно. Мысли иссякли... Чувствую себя идиотом. Абидна, да!!!?

В какую сторону бечь?!?!?!?

попробуй так... https://www.youtube.com/watch?v=Bf3wlLC ... Vv0ic24jqV хотя хз какой у тебя проц...

Pavel_1978 писал(а):попробуй так... https://www.youtube.com/watch?v=Bf3wlLC ... Vv0ic24jqV хотя хз какой у тебя проц...

Намек на урок "DMA для обслуживания UART" я не понял... Вязать комп через канал с Nucleo, чобы чтто-то трассировать? А зачем? Я в отладчике и так хожу по библиотечным кодам по шагам и вижу, что оно должно бы все работать, никаких fault-ов не наблюдается, кроме как иногда отваливается плата при случайном залезании/путании ног, идущих на лапы SWD. ???
Проц - STM32F411RET6, от 407G отличается частотой 100МГц, меньшим количеством портов.
Я наверное невнятно пояснил ситуацию: не могу заставить работать выводы GPIO на выход несмотря на то, что программа из нескольких строк выполняется! Дамп контроллера и Hex программы идентичны.
Может что-то с блокированием/защитой пинов/режимов, может с защитой записи памяти контроллера (пришлось снять защиту каких-то секторов, чтобы сделать общий erase при очередном отваливании), может что-то с общей настройкой частоты не то (411 почему-то не самая распространенная плата, файлы для конфига приходилось выковыривать с разных мест). Может надо бы где-то найти оригинальну прошивку и карту защиты секторов?
Тупо заставить поднимать назначаемые выходы не когда погода подходящая, а по заказу!
Вот в чем дикость тормоза! Да и в очереди аж 4 практических жизненных проектика на этом (или потом проставить Mapple Mini) контроллера.

Вот при возврате на StdPeriph и попытке помигать своим штатным LED пошел новый глюк - в отладчике при старте на команде из asm-startup-файла - BLX R0 - пошло непрерывным потоком сообщение "Cannot acess memory"!!! Что бы это значило?

Reset_Handler PROC
EXPORT Reset_Handler [WEAK]
IMPORT SystemInit
IMPORT __main

LDR R0, =SystemInit
BLX R0

Намек на урок "DMA для обслуживания UART" я не понял...

Вообщето я дал ссылку на цикл уроков, и если Вы не смогли увидеть очевидного и перейти на первый урок....
Удачи.

Pavel_1978 писал(а):

Намек на урок "DMA для обслуживания UART" я не понял...

Вообщето я дал ссылку на цикл уроков, и если Вы не смогли увидеть очевидного и перейти на первый урок....
Удачи.

Спасибо! Уроки касающиеся GPIO просмотрены. Кста, показанный там blink на CMSIS гарантированно убивает связь с Nucleo 401/411 из-за наглого прямого прописывания константами режима в весь порт (порт А у STM32f401/411, часть которого назначена под связь с ST_LINK.

Идей ни у кого нет. как "поймать" проблему?
Десяток строк кода на Си и нужен то? Мне не хватает понимания, "как"...

Logman писал(а):Вот при возврате на StdPeriph и попытке помигать своим штатным LED пошел новый глюк - в отладчике при старте на команде из asm-startup-файла - BLX R0 - пошло непрерывным потоком сообщение "Cannot acess memory"!!! Что бы это значило?

Reset_Handler PROC
EXPORT Reset_Handler [WEAK]
IMPORT SystemInit
IMPORT __main

LDR R0, =SystemInit
BLX R0
...

===========

StdPeriph тут не причем оказался.

- тут получается в stm32f411xe.s мы при инициализации не можем перейти на SystemInit, определяемый в system_stm32f4xx.c, и таким образом корректно настроить среду выполнения пользовательской программы... (((((
В отладчике пошаговое выполнение далее не предполагается, кружит "Cannot access memory". Но как этот момент пролетается, если поставить точку останова на какую-либо команду в уже моей программе??? Какой то системный watchdog срабатывает и пролетаем без инициализации? Совсем не понятно.

Еще малеха разобрался - тут полная хрень получается с системой:
1. Попадаю в asm-код я на отладчике УЖЕ при исполнении первых строк такой программы:
int main(void)
{
uint32_t i=0;
uint32_t j=0;
uint32_t k=0;

i = 0xFFFFFFDF;
j = 0x00000040;
...
2. Переменная i определена. Переменные j и k "not in scope"!!! На присваивании j я и вываливаюсь в "cannot access memory"

Из этого вывод - система не рабочая. Смена компиллятора в настройках проекта в Keil ничего не меняет. Используемый startup - Asm файл НИЧЕМ не оригинален по сравнению с таким же для других камней/плат, ну кроме объявления ресурсов конкретного камня.
Если что-то кривит уже на уровне среды исполнения / распределения памяти контроллера, то ... ???

Как лечить ситуацию, куда бечь???

дальше эти переменные используются? Добавьте volatile. Лучше минимальный неработающий проект проект выложить - имхо быстрее подсказка будет.

oleg110592 писал(а):дальше эти переменные используются? Добавьте volatile. Лучше минимальный неработающий проект проект выложить - имхо быстрее подсказка будет.

Переменные дальше не используются, поскольку "уже приехали". Проект подцепил. Там библиотека, startap s, листинги, объектные, hex и :

#include "stm32f4xx.h"

int main(void)
{
uint32_t i=0;
uint32_t j=0;
uint32_t k=0;

i = 0xFFFFFFDF;
j = 0x00000040;
//Вот здесь уже имеем Cannot access memory
k=i|j;

while(1)
{
for (i=0;i<1000000;i++) {}
}
}

C HAL такой скетч тож при отладке уходит в Cannot acess memory (забыл, правда, про тактирование, но тут не важно пока ):

#include "stm32f4xx_hal.h"

volatile void _delay_ (uint32_t delay)
{
while(delay--);
}

int main(void)
{
GPIO_InitTypeDef GPIO_InitStructure;

HAL_Init();

GPIO_InitStructure.Mode = GPIO_MODE_OUTPUT_PP;
GPIO_InitStructure.Pin = GPIO_PIN_5;
GPIO_InitStructure.Pull = GPIO_NOPULL;
GPIO_InitStructure.Speed = GPIO_SPEED_LOW;

HAL_GPIO_Init(GPIOA, &GPIO_InitStructure);

while(1)
{
HAL_GPIO_TogglePin(GPIOA, 5);
HAL_Delay(1500);
}
}

Что-то надо придумать как "восстановить" плату, видимо... upgrade firmware делал не раз, не помогает как-то...

Logman писал(а):411 почему-то не самая распространенная плата, файлы для конфига приходилось выковыривать с разных мест

Надо же . Можете продолжать танцы с бубном, а можно же посмотреть примеры в паках Keil - STM32F411RE-Nucleo

Что по пути Keil\ARM\Pack\Keil\STM32F4xx_DFP\2.4.0\Projects
Взять с них все необходимое , не заморачиваясь ни с калокубом ни с RTE ни с SPL ..

Это еще при том что Keil у мну не свежий 5.14 и паки не последние 2.40 ....

Logman писал(а):поскольку "уже приехали"

"not in scope" можно сделать "scope" как и говорил с помощью volatile: там где dosikus указал, еще есть в папке Templates готовый шаблон проекта Keil и пр. для Nucleo F411RE

Перекинул из примера GPIO Keil (кстати, он с HAL) все библиотеки приямо в проект, прописал - замигало... Но глюки продолжаются.

Кстати, запустил сначала пример из католога Keil, после предупреждения readonly, мне высказали, что у вас не Nucleo F411RE! Меня смущало на днях, что вроде бы поменялась строка опознавания платы в вкладке Debug/settings: А в окне Flash download по прежнему (иногда пропадает полностью, приходится добавлять.

Программируется через раз на третий, вернее меняет мигание при изменениях времени задержки, просто горит диод и не гаснет и т.д.
Экспериментирую пока с глюками, статистику пойму...

Logman, обновите прошивку STLink , через STLink utility .
Насколько помниться там даже варианты есть ...

Может диод c частотой несколько МГц мигает?
Теоретически это может объяснить сразу два момента:
- диод не мигает (а на самом деле мигает очень быстро)
- программируется по SWD с проблеммами (у меня было такое, когда длинные провода и наводки с проводов дисплея на SWD).

balmer писал(а): - программируется по SWD с проблеммами (у меня было такое, когда длинные провода и наводки с проводов дисплея на SWD).

Ну Nucleo же, какие провода? Хотя может USB шнурок???

Там и до края платы достаточно большое расстояние. Скажем SWD = PA13/PA14, а мы выдаем на PA12 или PA15 прямоугольные импульсы, то данные на SWD иногда путаются. Видимо в Hi-Z состоянии какое-то время находится эта линия связи.

Но это было предположение в качестве бредовой идеи

Переменные кстати могли быть не видны, потому как компилировалось в Release (-O3), а не в Debug (-O0).
Если не вызывался Startup код, то элементарно могло быть Access Violation при записи в переменную (из-за того, что стек не настроен).

Вернулся к теме, частично разобрался и немного пробился... СПАСИБО всем поучаствовавшим!!!
Проблемы крутились в нескольких плоскостях:
1) не свои настройки из-за файла asm и неких древних не помню откуда взявшихся библиотек, причем часть бралась из Keil, часть из этого треша, который я вывел на уровень выше проекта, часть внутри папок проекта... Налицо "нарушение ТБ", сам себе режиссер.
2) +глючащая нестандартная внешняя периферия, частично под толстым слоем лака и без даташита
3) до сих пор непонятно как работающий отладчик Keil, часто выносящий в цикл while(1) при прохождении первых шагов программы ДО него...

Вот пример - один из случаев, которые ставят в тупик так же, как и перепрыгивание отладчика в цикл while(1) ДО исполнения предшествующих команд (прошлый пост):

int main()
{
SystemCoreClockUpdate();
SysTick_Config(SystemCoreClock/100000); // 100 000 000 / 100 000 = 1 ms
SysTick_timer_Init(1);
USRButton_ini();
SevenLED_ini();
Timer2_Init(10);// 25 Hz/40ms = 4 * 10 mS for each digit
fLED7sh(SystemCoreClock/1000000); // = 100 - restored on 7LED !!!!!!!!!!!!
//============
while(1)
{
if (USR_Button.but_Long_Pressed == 1)
{ fLED7sh(5555); // test for error on 7LED
// USR_Button.but_Long_Pressed = 0; // command is competed
}
}
}

fLED7sh прописывает параметр в переменную, которая выводится на семисегментник, изначально 100, а после попадания УЖЕ в цикле while(1), из которого нет ходу, в нажатие Long_Pressed кнопки (по sistick) там должно быть 5555 (вывод "---") и духу сотки не должно быть! А 100 после отображения постоянно ВОССТАНАВЛИВАЕТСЯ!
Вот подозревать что-либо кроме регулярного аппаратного reset ничего в голову не идет... В отладчике из=за глюков поведения не ловится.
Что можно предпринять?