Помимо передачи, у меня есть ещё и приём. UDRE будет возникать в обоих случаях. Насколько помню, для разделения процессов приёма и передачи TxC/RxC и были придуманы. По крайней мере до этого я использовал именно их, и сейчас, после отключения лишних прерываний, данный код отлично работает.

Да ну?





RxC - флаг приёма.
TxC - байт передан, нужен для определения окончания передачи пакета (RS485 и тп)

Вы предполагаете, что компилятор засунул структуру в регистры? Зря. Даже если убрать #pragma pack(1), этого не будет.
Адрес берётся от расположения структуры или массива в ОЗУ, а нем от того, куда в итоге засунули данные.
Тем не менее, первое что я сделал, ещё до создания этой темы, это сделал волатайлом всё. Ничего не поменялось.


Попробую, раз такая пьянка.
Но принимать данные то по RxC прерыванию?

Похоже так, volatile нипричом.
Указатель в прерывании правильно меняется.
Может delay_cycles заменить чем-нибудь синхронизированным от таймера.
И стеки увеличить.


Да, приём в USART0_RXC_vect или проверкой бита RxC, передача в USART0_UDRE_vect или проверкой бита UDRE (если USART0 используется).

Все верно. 01, 02, 03 остались на своих местах и передаются. Значит прерывание и передача работают, и работают правильно. Портится содержимое структуры. Либо стеком, либо при записи по указателю где-то за пределы массива улетаете.
Начните с увеличения DATA STACK - 32 байта как-то несерьезно для серьезной программы. Если виноват стек - то его надо увеличивать минимум на размер этой структуры, ибо она портится вся. И то - это если она последняя перед стеком, а ведь весьма вероятно, что портится не только она. Радикальное решение - подправить скрипт линкера, чтобы он размещал RSTACK и CSTACK от конца памяти. Тогда для CSTACK автоматически будет доступна вся свободная память и вопрос выделения памяти под него отпадет автоматически. Насколько помню, это достигалось заменой '=' на '#' в командах размещения этих сегментов (и размещение RSTACK должно идти в скрипте до размещения CSTACK).

Запускал программу TC в симуляторе - данные только один раз передаются.
Но у меня ИАР 5.



А каким образом глобальные переменные стеком могут портится?
ИАР располагает их так(адреса увеличиваются):
СSTACK- RSTACK-глобальные переменные.
Стек растёт вниз.
В ИАР-е 3 и 4 по-другому что ли?

Почитал про UDRE.
Получается, прерывание оное надо держать всегда выключеным. Включать только когда пошёл первый байт, и отключать до ухода последнего. Иначе флаг будет всегда стоять и МК из прерывания не выйдет.
Угумс?

Увеличил стек ажно до FF. Не помогло


Отключаю АЦП и всё снова работает:

Из прерывания выйдет, выполнит одну команду и опять войдёт. Но в общем так - угумс .





Который стек? Или оба?


Потому чта АЦП - это зло, а DAC - добро.

Возможно ошибка в чтении данных от АЦП:


После того как ADC1_RxC_counter станет равным 0 прерывания по spi не запрещаются и если это прерывание как-нибудь возникнет, то оно начнет переписываться память вне массива Buf_ADC.
Нет ли возможности поставить data breakpoint на запись в TransmisionFrame?
Если есть то можно так выявить ошибку.

Я уже писал тут где-то, что у меня цепь из 2 чипов по JTAG и дракон категорически отказывается отлаживать эту цепь, настраиваясь всегда на 1 чип. И как это изменить я так и не понял.
По этому отлаживаюсь методом UART+осциллограф.
По осциллу прерывания АЦП отрабатывают верно. Но косяк явно в нём.
Сейчас просто выключил таймер, который инициирует чтение АЦП, оставив се тела функций и прерываний активными, и всё работает. В смысле, передача корректна.
Стоит запустить процесс - и всё падает.

Увеличил оба стека до FF, ибо не жалко. Не помогает. Но если б стек переполнился, то а) компилер бы об этом сказал, б) всё бы рушилось и с отключённым таймером, ибо компиллер же не знает что без него все прерывания бесполезны и никогда не сработают.

Без jtag-а плохо.
А в симуляторе сбой возникает? Ведь у вас программа работает как spi-master и uart transmitter, значит ошибка возможно может проявится и в симуляторе.


Поставьте стеки CSTACK и RSTACK в 1-2 байта и увидите, что ИАР будет молчать как партизан.


Не обязательно рушилось бы: смотря что переполнилось: может и просто глючить непонятным образом.

В общем, память однозначо перетирают прерывания от АЦП.


Как только слив данных поставил в volatile переменную вместо массивов, сразу всё стало пучкасто.
Провёл серию экспериментов, проинициализировал Buf_ADCx[], на выход идёт всё корректно. То есть цикл прерываний отрабатывается правильно, данные из временных буферов Buf_ADCx[] перекладываются во фрейм и т.д.
То есть рушит всё именно строчка Buf_ADCx[ADCx_temp] = UDRx;. Только непонятно почему - по лапе PORTA я вижу правильное число заходов в прерывание.

Полный бред.
1) ADC3_temp = ADC3_RxC_counter;
2) ADC3_temp--;
3) Buf_ADC3[ADC3_temp] = UDR1;
4) ADC3_RxC_counter = ADC3_temp;
5) goto 1
Разумеется после обнуления ADC3_temp команда из п.2 сделает ADC3_temp==0xFF и тогда п.3 сломает память.

Но для этого нужно чтобы возникло прерывание.Оно возникнет?


А как указать чтобы поля не менялись местами?