Здравейте на всички, много интересен проблем констатирах наскоро със pic18f452 и компилатор за него CCS, когато мине 73% заетоста на рама по някакъв необясним начин започва да меши променливите, примерно тези които са глобални , до момента във който рама е зает на по-малко от 73% нещата биват, прибавям нещо което по никакъв начин не променя работата на останалият код примерно създавам и инклудвам нов сорс файл и в него дефинирам буфер който дори и не използвам, заетоста на рама минава 73% и се наблюдава омешване на променливите но по-странното е че само определени променливи омешва тези които са дефинирани във основният сорс файл на проекта. Махам/закоментарвам прибавеното и след това нещата се оправят. Нямам дебъгване, намам и WDT, има прекъсвания но са от кодер и по време на омотването не ги активирам. Пробвах със няколко версии на компилатора и резултата е един и същ. Допускам че може и аз греша някъде, кода стана много тлъст но за сметка на това доста непрегледен .
С две думи ако никой не е наблюдавал подобно явление значи аз съм осрал някъде нещата

Как разбра, че омешва променливите, а не е нещо друго?

@Бате, дали омешва и друго не си направих труда да ровя, устройството е със LCD бутони и менюта, имам указатели /глобални променливи/ които сочат текущите прозорци и разните му там фунции на бутоните, като стане кашата всичко се обърква , указателите сочат каквото им падне и съответно се отварят произволни менюта и т.н. Имам дебъгер ICD (C)-Pirev, но имам някакъв проблем по който сега се ровя и не мога да дебъгвам никакви пикове от 18-та серия.

Махни оптимизациите на местата, за които се съмняваш, може да помогне. #opt 0 и #opt 7-8 за останалите места. Имам някакво смътно усешане, че ако ползваш #locate на определени места в кода и паметта почне да намалява... но не е потвърдено още на 100%. И кажи какво е станало

ICD-тата се скапват в режим дебъгване, пък и в програмиране, ако имаш голям кондезатор на MCLR пина, или външно куче. Ориентиоравачно, 47-100k & 10-100nF на MCLR са приемливи стойности за да влезне в режим дебъгване/програмиране.

"Омазване" на променливите може да се случи, ако дефинираш твои с #locate и/или #byte и същевременно оставиш компилатора и той да си заделя памет за автоматични променливи. Погледни в листинг файла, кои променливи се препокриват и направи размествания в #locate & #byte дефинициите, или ги премахни напълно и остави компилатора да си заделя сам паметта.

Интересно ми е, да споделиш какво е станало.

А възможно ли е стека да стига до променливите и от там да става омазването.
На мен ми разказваха за такъв случай.

Пише, че заделените с #locate променливи не би трябвало да ги припокрива. Обаче имам чувството, че не винаги май е така. Има ли шанс да съм прав? И какво в този случай? #reserve ?

Има такава вероятност, правил съм го с #reserve и нямах проблеми, мое мнение е да избягваш такива дефиниции в CCS като цяло, че при всяка следваща версия на компилатора има някакви несъответствия (явно недокоментирани)

Омазването за което споменаваш би могло да се случи, но не на процесор от типа на пика. Там както знаеш стека е хардуерен, а другият който компилатора организира е с предварително запазване на РАМ-а и би изпищял веднага. Това за което говориш на мен лично се е случвало на стари IAR компилатори за MSP430. При новите версии ти изплюва съобщение за достигната процентна граница от стека. При условие, че не променяш адреса на стека, разбира се.

Провери дали не се получава нещо като описаното тука:
http://mcu-bg.com/mcu_site/viewtopic.php?p=48855&highlight=static#48855

Не познавам тоя компилатор, ама звучи точно като недостатъчно стек. Пробвай да премахнеш някой вътрешни променливи и да ги изнешен като глобални, както и да предаваш по-малко аргументи на функциите.
Не знам как някой компилатор би могъл да сметне колко стек ще му трябва по време на компилирането - така може да се завърти изпълнението, че да не знае. Особено ако се използват библиотечни функции - например printf / sprints използват вътрешно динамично заделяне и могат да отлюштят стотина байта RAM.
При атмел / gcc стека е от края на рама надолу докъдето стигне и нищо не може да те спаси от това, да стигне до последните променливи в рама. На пик ще е подобно, просто няма хардуерна защита от разпростиране на стека.

В проблема се оказа че има вина задкормилното у-во, сиреч аз, получава се настаняване на масив от типа:

върху променлива за която е заделена памет от компилатора някъде в съседство на масива , и във хелпа си пише че "sprintf" не проверява за размера на буфера но кой да прочете, но поради някаква причина когато паметта се заеме до определено ниво както в моя случай например това се оказва фатално.