Чудесным образом портится память. Стал выяснять что же не так и не пойму.
Возник вопрос каксающийся 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 - этим вы дадите больше свободы оптимизатору, код станет короче и/или быстрее.

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

Уже произошло

strlen возвращает длинну строки не считая завершающего нуля, strcpy копирует включая завершающий нуль, затирая при этом байт за пределами выделенной через malloc памяти

на самом деле это так, для примера, там ещё есть такое:

Ну вот. Не знаю что сделал, но глюк стал стабилен. Всегда один и тот же адрес памяти на всегда одно и то же значение. Теперь можно как-нить вычленить кто это делает?

Это похоже на сбои железа (в обоих случаях поврежден 1 бит).
Если используется вняшняя память - увеличте задержки шины.

ну да... странно конечно, почему тогда всегда одно и то же место в всегда одно и то же значение?
сейчас так:
Было: AT +IFC=2,2 +IPR=115200
Стало: AT +IFC=2,2 «IPR=115200
0x2B изменилось на 0xAB, по сути старший бит стал 1. И уже раз 8 из 8ми было именно так.

ЗЫ. какие должны быть задержки для 70n памяти и 8MHz проца?

Перепробовал все задержки шины, эффект остался.
Пока пробовал урезал функционал, пока не перестанет проявляться баг.
Нашёл эдакую середину. Как все могли заметить, то работаю я с GSM модемом. Так вот, если убрать совсем дозвон куда либо, а оставить только инициализацию модема и прочий функционал программы, то всё работает. Достаточно заставить модем звонить куда-либо, то после 2ого (!!!) звонка, строка инициализации карёжится.
За первый раз как-будто не добирается указатель до неё

Что-то не так с разводкой или с МС памяти.
Основываясь на Вашем последнем посте определенно точно можно сказать, что с адресными линиями все Ок (с защелкой в т.ч. все Ок - защелка работает).

Проблема с данными, кстати, если читать одну и ту же строку несколько раз подряд проблема исчезает? или после изменения ячейки, постоянно читается неверное значение?

Теоретически для тактирования 8Mhz и 70ns памяти, задержки могуть быть нулевые, но тут может влиять разводка (паразитные емкости растягивают фронты). Поэтому для теста установить макс задержку и посмотреть осциллографом форму сигналов на линиях данных. Еще, если сигнальные линии подключены к шине через резисторы - последние убрать, вместо них поставить перемычки или нулевки.


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


Пардон пропустил мимо ушей что модем GSM, тогда он фонит еще серьезнее. Однозначно ШД забивается помехами - попробуйте разместить модем как можно дальше от устройства. Поставить экраны (напр для теста обмотать девайс паралоном, а сверху фольгой). Если подтвердится, боюсь придется переделывать разводку полностью. Также проверьте не затягивается ли фронт сигнала "R" (хотя если бы дело было в нем, тогда характер искажений был бы другим).

Ничего подобного. Я писал тест памяти, который пишет в память 0xFF 0xAA 0x00 0x55 и потом это от туда читает 10 раз. Так же ещё ряд тестов, и всё ровно. Только что пробовал это на разных задержках.
Память чтоит максимально близко к процу, никаких резисторов на шинах нет.

Тяжко, но попробую. Кстати такое не наблюдалось ранее, прошивку пишу не первый день

Любопытно. Эта длинная тирада означает ответ "нет, не исчезает" или "да, читается неверное значение"? Вопрос был
Только в русском языке фраза может содержать одновременно и положительный и отрицательный ответ

Ну в общем ситуация такая. Была просадка напряжения Когда модем начинал что-то натужно передавать он цуть цуть просаживал напряжение (несмотря на кучу кондёров танталовых и прочего). Этой просадки хватало чтобы память дурила. И так интересно, выбивала всего то по 1 биту