Пичове здрасти. Далдисах на дълбокото и взех че се дезориентирах

Ситуацията е такава:
Ползвам СТМ32Ф401РЕ на Nucleo платка. Направих му драйвери за АЦП-то да взима 14 проби и да ги запазва в масив с DMA. Това нещо е управлявано от часовник. Часовникът работи на 16 МHz, сложил съм прескалер 1333, и зареждам ARR регистъра с функция, която взема за параметър желаната скорост на взимане на данни. Когато данните от всичките 14 канала са снети се генерира прекъсване. По време на прекъсването по УАРТ и DMA получените данни са засилени към ПЦ и програма, която ги чете, правена на QT.

Уарт работи на скорост 921600 baud rate. Отделно в програмата на компютъра, при натискане на бутон, изпращам масив от 16 стойности, които чета с борда. Първата стойност използвам за обновяване на ARR регистъра с ARR_set функцията.

Искам да отбележа че нещата работят. Ако програмно вдиигна прекалено много f_output (до 3000 ) QT програмата малко се задъхва, така да се каже. Не успява да обнови много добре стойностите, които получава по УАРТ и показва показвам в един QTableWidget, но този проблем е ясен. Стойностите са много, променят се прекалено бързо. Може да се поработи над някакъв тип оптимизация. Имам обаче друг проблем, който не разбирам от къде идва. В програмата (от компютъра) задавам стойност на масив и го изпращам на Нуклео платката, която го прочита на базата на прочетеното задава нова стойност на ARR регистъра. Това сработва на много ниски стойности, примерно 1,2,3 или 4 (тези стойности дават скорост на вземане на проби в секунда), но при по-високи стойности, всичко спира да работи, програмата спира да приема, а Нуклеото сякаш замръзва. Наблюдавам какво се случва чрез Live expression на дебъг конфигурацията в CubeIDE и там всичко спира. Странното е че когато ръчно задам стойност на ARR регистъра нещата работят, но не и когато това стане през УАРТ.

Знам се че нямам въобще опит и имам една такава тенденция да навлизам в детайли, а често общата картина ми убягва. За това се надявам на мнение от опитните хора.

Благодаря предварително!

Писано e s CMSIS и magic numbers основно се водя от туториалите на Izrael Gbati, ако някой проявява интерес мога да му споделя кода.

в PDF за ARR май пише: don't update ARR with newly written value until the next counter reload
навярно при твоите "скорости" ще трябва да забраниш периферия/прекъсване преди да
re-SET ARR

Здрасти Уйзард-е. Благодаря много ти благодаря за включването! Приемам намека за "скорости", поправям се на "честота", ако съм те разбрал правилно де
Утре сутринта ще го пробвам, но към АRR има следния коментар: The counter, the auto-reload register and the prescaler register can be written or read by software. This is true even when the counter is running. Това от Ref. manual 316, отбелязах си го защото се чудих дали е правилно да пиша в АRR, докато системата върви и проучих въпроса. От друга страна АЦП-то, което ползва часовника, работи и с ДМА, което трябва да се спре за да се преконфигурира.

под "скорост" имах в предвид ...
че пренастройваш системата(timer/adc/dma) в движение и все нещо може да се разсинхронизира
ако не ти пречи disable/set/enable - пробвай

Спрях АЦП, ДМА (изчаках за потвърждение за дма) и таймер, след промяна съдържанието на АРР ги пуснах отново но изглежда не е това, или не е само това. Ту сработва, ту не.
Успях да локализирам проблемът, всъщност Нуклеото продължава да си работи, но спира да вдига флагове за прекъсване при завършен ДМА трансфер от АЦП до паметта. Ползвам ги тия прекъсвания за да стартирам УАРТ Tx. Имаше там едни флагове за грешка при трансфер... продължавам да го мъча

Успях да локализирам проблема до обновяването на ARR стойността. Което правя така:


Какво се случва тук: На g_rx_cmplt задавам стойност 1 при прекъсване за получен трансфер, проверявам дали новата стойност е различна от старата и ако е, я задавам на ARR (което я проработи, я не). Ако обаче извадя ARR_set(); и я бутна в друго събитие, примерно при приключването на ADC трансфер, нещата работят доста по-добре. Защо се случва така не съм сигурен, явно при промяната на ARR нещо се бъгва. В последствие установих още един "фикс" така да се каже (по-скоро ми казаха де). В CR1 има една настройка Auto-reload preload, при която вместо да смени на момента ARR изчаква завръшването на цикъла. Така че върнах обратно ARR_set(); и сега работи безотказно.
Баси кефа

Всъщност изглежда че промяната на ARR е водила до невалидни данни, което вдига един бит 5 (Overrun) в ADC статус регистъра и това всъщност е причината да спрат конверсиите. Този бит просто си остава в регистъра и блокира следващите конверсии. При включването на Auto-reload preload избягвам да прекъсна предаването на данни и възможността да ги скапя, което ще повдигне OVR бита, но може би още по-добре да почиствам същия бит, след всяка промяна на ARR.