Значи имам си два проекта. Двата са за леко различен хардуер (все с STM32) и леко различно приложение. В случая трябваше да подкарам стария проект (приложната част) с новия хардуер. Нищо сложно като се има предвид, че приложението е напълно изолирано от хардуера.
Малко copy&paste и тръгвам да тествам и установявам че USART3 не бачка... И като се почна 3-4 дена не мога да открия разликите, щото кодът дето бачка с хардуера е 1:1 с единия проект и там си работи. Зареждам единия проект - бачка, зареждам другия - не ще. Гледах USART-a няма нищо подозрително и тъй беше с ДМА пък те обичат да правят мизерии го направех без ДМА, но ефект никакъв. Викам си нещо я клокове, я пинове - и там дърво няма разлика. Даже си играх да сравнявам стойности на почти всички регистри от RCC, GPIO, УАРТ изобщо квото се сетя и то в момента в който тръгвам комуникацията. Викам си да не би нещо да маже по паметта междувременно...
И така сума си дни сравнявам, анализирам... щото то има някакви дребни разлики, ама нито една няма връзка с проблема. Накрая тръгнах ръчно да пиша по регистри, щото то да се подкара УАРТ са съвсем малко регистри. И кво ми прещука че го проиграх ръчното още преди да съм пуснал мой код. И изненада в единия проект работи, в другия не ще.... Та тогава се сетих че имам и .gdbinit дето ресетва платката. И в стария проект прави пълен ресет, а в новия чатичен, вече не помня кога точно съм я направил тая промяна но е преди мноооо време. Май беше покрай луминари щото те имаха по-шибан ресет...
Иде реч за младжите 3 бита на Application Interrupt and Reset Control Register от System Control Block-a на куртекса, които в по-старите документации са описани така:


a в по-новите така:


Очевидно по някое време АРМ са решили, че тия регистри не бачкат и затова са добавили "behaviour is unpredictable" a пък защо при STM32 се набъзиква само (или поне аз само това съм забелязах) USART3 си е пълна мистерия. Във всеки случай все бях настъпвал мотики, обаче тая ми разказа играта...