Имам мцу (за съжсление от Максим..), което чете един акселерометър и праща данни по спи интерфейс. Само това прави, като по уарта даже готовият пакет данни го засилвам с дма.. това на скорост от 921600 до 2.5мбода. И винаги след 2 милиона пакета почва да греши, получават се грешни символи и т.н....
Уарт към усб ползвам ftdi ft234xd, което го дават уарт до 3мбода. С два стоп бита....
Някой да се сеща от какво може да се получи това мислех си да е в ралика от кварцовете, та да се натрупва изместване ба символите... но защо първите 2 млн пакета е ок, а после почват проблемите...
Ако затворя конекцията и пак я отворя(от пц пробвах и длл на фтди и като виртуален компорт все тая, и с С# и със питон) пак чете без проблеми до кум 2 млн пакета...

Бахти чудесата, не бях пипвал уарт от 7 години...

Е ти пък хептен без 3-4 символа почивка ли ги ринеш тия пакети. Ако има пауза някъде няма причина да не се синхронизират. А и без пауза да е пак няма причина да се разсинхронизират. Все пак на всеки фронт би следвало да се синхронизира приемника. Ако е неработещ заради кварц(честота), ще е неработещ още на първия символ.

То разлика в clock-а трябва да се изравнява от старт стоп бит т.е. на всеки символ.
Ако се пращат еднакви байтове какво става примерно 0xAA ?

Ами акселерометъра има 16кхз output data rate.
Бие ми прекъсване320 думи(Nx(X2byte,Y2 byte,Y2byte) на всеки 6.5 мс(или там някъде) . аз изчитам фифото, и слагам хедър и дължина на пакета , тотално са 630 байта и засилвам на дма уарт. И така до откат.
Ама какво е това сакрално число дето след около 2 млн такива пакета се зацапват незнам....
План Б ми е да събирам Nна брой датасет по 2млн фрейма... като изпускам 10-20 мс да преинициализирам компорта....ама не е добре

UART-a не вдига ли някой ERR флаг?

Аз не схванах нещо постановката

1. Контролера получава прекъсване от акселерометъра на всеки 6.5 мс по жица
2. Контролера чете данните (320 думи по 6 байта) от акселерометъра по СПИ и ги записва в локална памет
3. Контролера използва вътрешно ДМА което чете събраните данни (320*6+хедър, нещо не пасва) и ги изпраща по УАРТ до ФТДИ чипа зад който стой ПЦ
4. След 2е6*(320*8+хедър) байта ПЦ-то получава единични грешни символи или всички символи, вкл. хедъра са грешни?

Всичко може да е. Аз бих закачил един логически анализатор да записва какво върви по серийния канал и примерно едно гпио на което да се изкара пулс като се засече грешка и по него гледаш дали всички битове и фреймове преди това са ОК. Т.е. да локализираш къде е проблема - в предавателя или в приемника. После чесане по главата. Евентуално с друг тест стесняване на локацията. И така докато не ти просветне.

Така съм гонил бъгове в блокиран УАРТ заради едновременно ползване с полиране и с прекъсване т.е. четене на статус регистъра при полиране сваля флага за прекъсване и така другата нишка която го чака това прекъсване никога не продължава. Класически дедлок. Разбира се за таймаут или лаещо куче и дума не може да става. Разбира се това ставаше в продукция. На устройство защитено от дебъгване. Дедлока се случваше веднъж на ден. Добавянето на още лог не помагаше защото разместваше във времето всичко и не се тригърваше ... мъка. От това по загубен бъг беше само с кофти възстановяване на статуса по време на изпълнение на Thumb ITE инструкция т.е. изпълняваше и IF и THEN ... трябваше да се пипа компилатора да не я генерира.

Като цяло е така, само т.3 е 320*2,(толкова е фифото по точно сетнал съм го на 312 думи watermark за интеръпа ) демек 624 байта всеки ~6 мс. След това слагам отпред старт на пакета 4 байта, фрейм брояч 4 байта , брой на полезните данни 2 байта и това е, което се дава на дма-то на уарта да си го засилва към фтди чипа. И безкрайно това се върти, докат не пратя команда за стоп, или да променя накой филтър на акселерометъра...
И след около 2 млн фрейма (пакета или както исскаш го наречи) почват грешки. Някой път в старт хедъра, някой път в брояча, някой път в дулжината на полезните данни, някой път в данните....
Не е като загуба на байтове като бройка са толкова около 98% приети от 2млн * 734 байта.....
Хня като цяло...

Проблема е че нямам лог анализер за голями масиви, само около 100мб.
Друготоо е ,че няма как да клатя гпио от страна на пц-то. Иначе си го мислех нещо подобно да снифя usb-то с някой плъгин на wireshark...

Като цяло ще го оставя на план Б N на брой дата сета по 2млн фрейма...
Три деня гоня духове...

Контролера ако има ресурси можеш ли да направиш някаква основна проверка на коректност на данните и от там да дадеш тригер на анализатора? Това само за дебъга

Е, в моя случай бяха 3 месеца ... 3 дни само нищо не е

Мисля, че имаше ЛА които стриймват всичко през бърз USB3 на диска т.е. може да запишеш дни ... ти си знаеш де. Но аз не бих оставил такъв бъг т.е. докато не си го хванал защо се получава нямаш никаква гаранция, че няма да започне да се случва в продукция по често отколкото ти се иска.

Можеш ли да възстановиш системата след грешка в работещо състояние? Фатално ли е ако се случи тази грешка? Имаш ли читава обработка на грешки и таймаут? Има ли куче да рестартира системата ако тотално забие?

Т.е. от доста време насам фокуса ми не е толкова да правя софтуер който не крашва ами такъв който отработва грешките и продължава да работи. Така и да стане някой фал клиентите са спокойни, че няма да им блокира работата. Е, зависи какво правиш все пак ...

сега, чисто теоретично грешки трябва да имаш, защо 2 млн пакета нямаш е божа работа. 2 млн пакета по 630 байта ... доближаваш се до sign int32 ама само се доближаваш но каква може да е връзлката идея си нихт, не би трябвало да има никаква
Пращай известни данни и виж дали грешката е само в хедъра или няма и грешка в самите данни. Пишеш хедър и дължинас на пакета, като че ли нямаш CRC т.е. напълно възможно да имаш и други грешки които не виждаш.

HCL вместо да изтрия моя двоен пост изтрих твоя ... ама невиждам как да го върна ....

Май не може

Мдааа, питах гугъл, рових ... тц ... съжалявам ..