Обнаружил странную проблемку. В прожке есть глобальный массив char[2000]. При вызове функций записи в файл командами FatFS, все переменные в функциях своими адресами влазать в массив. Менял размер массива - никакого толку не даёт. Все локальные переменные в функциях именно FatFS своими адресами пересакают конец массива, отсюда значения в массиве заолняются мусором. Прога в uVision, проц LPC2478. Может кто такое наблюдал? Как вариант думал всё стереть и начать заново, но если есть проблема,как бы не вылезла в другом месте. Число портящихся байт ~300.
Спасибо.

Недостаточно выделено места под стек. Попробуй выделить под стек еще 512 байт и посмотреть.

Это точно стек переполняется.

Попробуйте оптимизировать использование стека с помощью динамического выделения памяти под локальные переменные из кучи (malloc) или уменьшив глубину вложенности функций. Ну или увеличте стек
Обращайте внимание сколько отжирают от стека библиотечные функции.

Кароче проблема решается объявлением переменной файла как глобальной. Подобно FatFS либа EFSL также не пашет с локальными файловыми переменными.
Может что-то делаю не так, но если создавать в своей функции записи локальную переменную типа FIL, то при вызове любых функций FatFS происходит пересечение адресов. Странно но факт.

Вот так всегда: в первую очередь "либа кривая". Почему-то у остальных "пашет", у вас нет, и виновата, конечно же, либа.100%. Если вы объявляете переменную глобально, память под нее выделяется на этапе линковки. Если локально - она размещается на стеке. Если стека не хватает - естественно, будут затираться какие-то другие данные, на которые наползет стек. Переменная типа FIL кроме 40 байтов данных содержит еще и буфер на 512 байт. Итого 542 байта. А сколько стека у вас выделено всего?

Ничего странного! Говорят же вам, все локальные переменные помещаются в стек, а он не резиновый.
Изучите подробно, как устроены функции в Си, как осуществляется вызов функции, где выделяется память под переменные, что такое стек и куча. Иначе в будущем будет еще больше проблем возникать.

Ну еще не ясно, товарищ откравает файл - пишет/читает - закрывает в одной своей функции или в разных?

Да всё в одной функции. Открыл, сотню байт кинул и закрыл.

Хороший вопрос по поводу стэка и его размера, особенно где его глянуть в данном случае. Что мешает использовать под него всё ОЗУ? Ясно ,конечно, если вы динамически выделяете место под свои переменные,имея заранее какой-то массив. А если такого нет?

Для Кейла не знаю, но искать надо где-то в районе опций линкера и/или его скрипта.Тот факт, что у ARM 6 стеков, по одному для каждого из режимов: FIQ, IRQ, Supervisor, User/System, Abort, Undefined

А где можно глянуть такие сведения?
Фишка заключается в том, что вызов функций именно с большим объёмом(>500Б) локальных переменных вызывает проблемы. Ладно бы ОЗУ не хватало для всех, так места 98кБ хватит и на прогу и на её переменные два раза.
Настройки все смотрел, очевидного окошка в кейле не наблюдаю для ввода размера стэка.

О чем? О количестве стеков и режимах работы? В User manual на LPC кратенько, если недостаточно - Google-> "ARM7TDMI manual". О настройке стеков в кейле? В документации на кейл. Или медитируя над параметрами, с которыми запускается линкер и его скриптом (кажется, у кейла он называется scratch-файл).

А разве не в startup'e задается размер стеков?

))) ннда приплыл. Больше глупых постов делать не буду. Всем спасибо.

Нет. В параметрах, передаваемых линкеру.
В startup'e инициализация стеков и режимов.

линкер вообще-то здесь не при делах.
Размеры стеков в Keil "по-умолчанию" задаются в стартапе.
Никто также не мешает определить массивы стеков в .c файле.


scatter файл, в нем задаются секции памяти.
тем не менее никто не мешает разместить стек просто как массив в ROOT-RW, всмысле не создавать отдельных секций под стек линкером (что в Keil и делается).