Имам следния проблем - ядрото е кортекс-а9. Проектът е бутлоадър който в началото тича от флаш (външен флаш в XIP режим) - в този режим прави копиране на секции във рам-а и стига до точка в която иска да повика първата функция която е в рам.
В тази точка софтуера се чупи - ако го направя по стъпки минава и всичко работи. Ако пусна кода да тича и сложа брейкпоинт в рам функцията не стигам - процесора тича без да спре и ако го халт-на виждам че съм някъде из флаша на неочаквани адреси (няма флаш там, но понеже чете FF в XIP режима от външния SPI флаш го интерпретира като някакъв AND и си крета спокойно нагоре по адресите).
Викането от флаш към рам гледам че го прави през _veneer функции, които са за да заобиколят лимита от 16М. Изглежда коректно - то и на стъпка минава нормално от там. Прегледах че рам-а е коректно копиран от предходните функции. Експепшъните са прихванати и ако стане беля ходи на някакъв хендлър та очаквам че не е минало през такъв в проблемната ситуация.
Другото странно е че това го прави само с определен модел SPI flash памет на spansion. С няколко други типа (атмел, ст) не е имало такъв проблем. Та се чудя дали може да е предизвикано от това? Макар че не мога да индентифицирам проблем - тръгва началото на кода, копирането към рам се случва коректно и т.н.
На по-старите АРМ адра (АРМ9) съм ползвал "-mlong-calls" за дългите викания между регионите. Тука дали не е алтернатива?

Можеш ли да пуснеш флаша на по-ниска скорост, за да тестваш дали от там не идва омазването.

Пусках го, на нереално ниски (десетки KHz). Може да погледна със скопа дали е влязло в сила. То не че другата е голяма - 16МХз, а платката с други флашове си държи 50МХз без проблеми.
Ще боря още, странно е - точно викането към рам-а се чупи. Обратното иди-доди - да кажеш че от рам към флаш не иска да прочете флаша разбирам, ама тук рама си е там. Даже пробвах че от дебъгера имам достъп до зоната (в РАМ-а) и се пише и чете.

Нещо на темата конвейри, забрана, флуш или както там се казва?
Извинете, ако съм написал нещо глупаво - искам да побутна темата

Хмз ... интересен проблем. Аз бих разклатил един пин тук там из кода колкото да гледам със скоп или лог.анализатор докъде се изпълнява и коя инструкция чупи нещата. После чесане по главата, псуване и ако имаш късмет още повече псуване като го хванеш

Намерих го - някой преконфигурира един пин на средата на процеса и счупва четенето от SPI флаша. Защо обаче на дебъг минава - не знам. Доколкото гледах кода си е там и не се зарежда от дебъгера. То няма и как в тая зона де (дето е мап-нат SPI флаша за XIP - не е рам). Това обяснява защо с някой SPI флашове има проблем а с други не - явно реагират на тия нива различно - може би някой ги гледат само на power on, може би други се преборват силово.
Може би кеширането на SPI XIP контролера е измествало визията за проблема, но пък доста си играх да променям кода. Само че промените май бяха само в RAM функции и сигурно все едно и също е оставало като "епилог" след превключването на пина до момента на викане на рам функция (която и да е тя - то нали виждах че първата рам функция която повикам се дънеше).
Интересното (за мен) бяха тия "_veneer" функции за далечно викане. Преди съм ползвал "-mlong-calls" за подобни викания, защо тук (на v7-a) е по друг начин ще трябва да проверя.

Модерни veneer-ически болести.