Чудесным образом портится память. Стал выяснять что же не так и не пойму.
Возник вопрос каксающийся volatile.
Есть ли разница в следующем и какая?и вариантКакова будет разница? есть ли тут смысл?

Разница есть, только смысла в ней нету
А память портится скорее всего потому, что вы где-то пренебрегаете проверкой на выход значений указателей за границы выделенных им буферов.

В первом случае у вас может (неизвестным для компилятора образом) измениться то, на что указывает указатель в структуре. во втором случае - сам указатель.

P.S. Вообще интересная постановка вопроса: "А что же я понаписал?" Может стоить формулировать его несколько иначе: "Мне надо чтобы было так-то. Как это сделать?"

При memory corruption bug'ах не до постановки "Мне надо чтобы...", потому что неизвестно что надо на самом деле..
Автор может сказать лишь - "Мне надо чтобы не глючило".


Смысла в volatile'ях тут нет, как перед полями структуры так и перед объявлением самой структуры.

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

Чем больше статистических данных получите, тем проще будет локализовать блок вызывающий повреждения.

данные могут портиться при нарушении выравнивания слов. У меня однажды указатели на int каким-то чудесным образом указывали между этих самых интов, и модификация одной переменной портила вторую (да и первую тоже).
В структурах надо аккуратнее с выравниванием и указателями

Почему? Точнее почему нет смыла перед объявлением самой структуры?

Потому что компилятор обычно не опускает обращения к полям структур и так. Да и не видя кода где такая структура используется volatile - теряют весь смысл.
У вас указатели в ней могут произвольно меняться скажем "железом" или еще каким-то странным образом?


Не могут - ШД 8-ми битная.
Это не ARM.

В основном структура передаётся в функции как указатель на неё.И ещё делаю memcpy().

:\ А как "железо" может сменить указатель? Нет.

+1

А sizeof() используете? Внимательно проверьте где и как.

К примеру есть переменная uint8_t *InitString;
В практически самом начале программы, на неё аллочится память примерно так:
И всё ровно, пока не произойдёт нечто. К примеру содержимое строки было "AT+IFC=2,2\r\n" и первое и второе и даже третее обращение к ней именно это и получало, но после чего-то содержимое строки может стать "подбитым" к примеру таким "AT+I@C*2,2\r\n". И это только частный пример. Бывает что просто переменная uint8_t внутри структуры сменила своё значение.

Я сейчас занимаюсь выводом в дебаг инфы при обращении к указателям, дабы исключить обращения "не туда". Но на глаз по коду тут всё ровно.

размер кучи достаточен? Куча часом не до стека идет? Может стек переполняется?

Только не кидайте гнилыми помидорами, а где это глянуть?
Использую WinAVR.

Я не пользовался WinAVR, но называется это обычно heap size для кучи и stack size для стека ))

volatile действительно не имеет смысла.
Просмотрите внимательно ещё раз весь код.
Может быть как-то прогнать пошагово и попытаться определить где именно косяк?

для инициализации внешней памяти использую рекомендацию из WinAVR:
-Wl,--defsym=__heap_start=0x801100,--defsym=__heap_end=0x807FFF
т.е. 32к во внешней. Всё остальное не изменно.

А не может сбоить сама внешняя память? Попробуйте какой-нибудь тест написать (записать псевдослучайную последовательность и считывать ее в цикле, считая сбои), может программа и не виновата.
Может. Самый простой пример - указатель стека. Более сложный - регистры адреса источника и приемника при ПДП (DMA). Софтовые варианты - указатель изменяется в прерывании. Или еще один случай - многопоточное приложение, доступ к указателю в разных потоках.

volatile перед стуктурой распространяет volatile на все члены структуры.
Если ни один из этих вариантов не подходит под ваш случай, то вам не нужно делать указатели volatile - этим вы дадите больше свободы оптимизатору, код станет короче и/или быстрее.