ARM, RISC-V контроллеры

Код файла custom_adc.c, из прерывания записывает в буфер новые данные. С точки зрения работы функции прерывания АЦП - всё нормально. Эта функция обращается к буферу по индексам массива. Проверка индексов выполняется функцией-обёрткой (удалю после отладки). Массив, куда идёт запись, определён как volatile в другом файле и передан в контекст файла, где выполняется запись в прерывании посредством объявления extern volatile в одном из заголовочных файлов. СУКА! Я три дня времени убил (если посчитать потраченные ночные часы и свободное время) на эту проблему! Продолжим. Выглядит это так: Как ни в чём ни бывало, отладчик показывает адрес и структуру массива, показывает данные. Только:

а) данные в хвосте массива замусориваются по ходу работы программы

б) на каком-то этапе, продолжение записи в буфер крашит программу, так как затирает адрес возврата в стеке или приводит к прочим фатальным ошибкам.

И это при корректных значениях индексов. Я включал (ранее, см. ссылку в сообщении выше на предыдущую попытку) пошаговую отладку и видел, что с точки зрения отладчика, данные пишутся корректно в корректные ячейки массива, в корректные адреса относительно границ массива. Только, сука, эти границы массива ложатся на стек! Проблему устрнаил сам, добавив в определение массива атрибут: volatile int16_t Stage1Buff[2][ADCchNum][St1BuffSize] __attribute__ ((section (".bss.filterdata"))) = { { { 0 } } }; //Input buffer for ADC data flow Лишь после этого буфер лёг в секцию .bss и перестал перекрываться со стеком. До использования этого атрибута, трёхмерный массив volatile int16_t вообще не попадал в файл *.map. И, по логике, оказывался в стеке, где и происходило фатальное наложение.