Здравей Zdrav, благодаря за внимателните съвети, задължен съм ти наистина . Само искам да се консултирам още нещо с теб. Препрочитам въпросната глава за IAP функциите от менюалът, и не откривам дали има някакво ограничение в байтовете които се флашват. Понеже работя за първи път с CORTEX M3, а на GB60 (Motorla -ски) на който съм работил във връзка с въпросният флаш - там имаше ограничение във флашването от 512 байта. Т.е ако искаш па запишеш 1К, въпросната функция трябва да се викне два пъти. Още един път благодаря!

стр. 633

Т.е. имаш четири възможни стойности за размера на блока, който флашваш.

Здравей, може ли да се консултирам още нещо с теб: установих че нещата както си ги организирах в кодът работят. Проблемът обаче е, че флашването работи от адрес 0х9000, под този адрес мога само да изтрия паметта без да бога да запиша нищо в нея. Съмняват ме две неща: първо този проблем да не свързан със самите настройки на компилаторът KeiluVision4 (Options for target...), и второ понеже след интеръпт векторите, паметта се записва от наш тул с който вкарваме примерно какви фонтове ад печати нашето устройство, възможно ли е той по някакъв начин да налага ограничение в записът на адресите под 0х9000?

Оправи ли дължината на данните?

Със сигурност, мястото където ще записваш шрифтовете, трябва да е заделено за тях при компилацията на основния проект. В документацията на KEIL е описано как става.

За сега съм го направил да флашва 4096 байта. Ако обаче записвам файл който е по-малък, няма да мога да брейкна безкрайният лууп. Затова съм то направил да работи за самият тест, тест свързан със самото флашване.
Иначе какво правим за да заредим всичко в контролерът: първо през Keil-а зареждаме монитор (буутлоудер), след което наливаме с тула за който ти говоря една част от фърмуерът заедно с фонтовете за принтиране, и накрая пак чрез Keilа наливаме останалата част от фърмуерът. Не ми питай защото така го правим, просто така са ми го показали и следвам този алгоритъм. Имам чувството обаче че приз тези три етапа, става някаква организация на паметта, но кое къде решава къде да пише и защо, немога да се ориентирам. Нещата ги споделям тук понеже няма друг софтуерист около мен за да се консултирам, и се опитвам сам да се боря.
Искам да попитам и още нещо, като имаш предвид документацията на Keil-а, от самият Help на тулът може ли да се достигне до въпросното място? В смисъл тази документация отделен pdf ли е, като каталогът на контролерът или ?

Здравей, понеже се опитвам да намеря някакво инфо в документацията на Keil. На картинката която прикачам, заграденото е в същност паметта която се флашва след компилацията (за което говорим)? Понеже зададеното адресно пространство се връзва с явлението което ти описах в последният пост. Е разбира се тука началният адрес не е 0x9000, а 0хА000. Сега ще опитам малко да изменя нещата и да пробвам нещо дали ще стане...... да дръпна този адрес малко по-назад, за да вида след компилацията дали този път ще ми позволи да запиша нещо.....

------------ Edit ---------------------------
Без успех,:) - дори и 0xA000 да сменя на 0х5000, пак немога да го флашна, само трия . Продължавам да търся решение .......

Нещата почнаха да стават все по-объркани и недоизяснени, усещаш ли?
Първо да разбирам че извикването на IAP функциите го дебъгна?
Второ не става ясно какво и къде се обърква при цялата постановка? Да речем че буутлоадъра ти тръгва. Но не може да програмира първите сектори така ли?
Я пак провери с дебъгера, когато буутлоадъра извиква IAP функцията Copy RAM to FLASH, каква е дължината на данните, която подаваш в cmd[3].

После ще коментираме и картинката дето си я постнал.

Здравей, разбирам за какво говориш. Ще опиша последователно възловите места във функцията getFile_entry и резултатът от дебъгването за cmd[3]. Буферът където пълня данните съм го декларирал и инициализирал така:

механизъмът за брейкването има следният вид:

не проверявам цялата размерност на RSReceveBuf, понеже променливата която икрементирам за брой получени символи по RS, се увеличава до към 1800 (не съм установил докъде точно между 1700 и 1800 символа - понеже тук имам и друг проблем при който не знам как мога следя за край на полученият файл по RS. Пробвах с EOF, но във фърмуерът нямам дефинирана такава променлива).
Резултатът за cmd[3] от дебъгването, при извикване на lpc17xx_flash_program_words е:

Извинявай, искам само да те попитам понеже не разбирам една част от твоят коментар - "Първо да разбирам че извикването на IAP функциите го дебъгна?" - как да го разбирам? Когато викна IAP функцията за Copy RAM to FLASH, тя флашва съдържанието от буферът по-горе на адрес >=0x9000, но не може да флашва на адрес <=0х9000. Понеже трите ми фонта за принтиране се намират съответно на адреси - 0х5400, 0х5В10, 0х6220. Това се опитвам да направя е да изтрия съдържанието на адрес 0х6220 и на негово място да сложа съдържанието съдържанието на RSReceveBuf, който пък ми съдържа фонт със символи които аз съм си направил. Това което получавам е че само трия съдържанието от въпросният адрес, и като извикам lpc17xx_flash_program_words, не се записва нищо.

Понеже темата е започната като "Проблем с флашването на LPC1754", първо да довършим това.



Това означава, че подаваш към IAP функцията 8192(0x2000) като размер на блока за флашване. Което надхвърля ограничението от 4096 байта.

Разбирам за какво става дума. Това което не мога да разбера, е защо на определено място от паметта работи (0х9000) а на друго (0х5000) не - понеже размерът на данните не го пипам а пипам само параметърът *addr на fshProgram_flash_region функцията. Сега ще си поиграя с размерът на данните за да докарам тази стойността на cmd[3] да е някоя от зададените в каталогът......

Ами трябва да погледнеш вътре във функцията:
Bool fshProgram_flash_region(uint8_t *addr, uint8_t *p, uint16_t n);

Там за секторите с адреси под 0x9000 се удвоява дължината на блока който ще се флашва.
Както по-рано ти писах, този код има нужда от повече от елементарно преправяне. Той не е писан за твоите нужди.

Ти използваш изречението - "не е писан за твоите нужди", а началникът ми използва - "вътре е мазано на поразия" .
Да аз точно към тази функция се насочих, сега cmd[3]=0x1000 което всъщност е 4096, само че не постигнах резултат. За удвояването това което казваш обаче ме навява на нещо, което ще опитам. Според теб имаш ли идея защо е направено това удвояване, с каква цел? Не те питам за точен отговор, просто информативно дали имаш някакво предположение.

Идея си нямам.

Здравей, реших да пиша понеже получих още един резултат от дебъгването: тулът за който споменах че флашваме фонтовете за принтиране на устройството, може и да не "заключва" адресите върху които пише. Резултатът който получавам е, след като съм флашнал фонтовете (с въпросният тул), тествам да видя дали мога да ги закарам и трите фонта - изкарвам ги. Те съответно ми се намират на адреси - 0х5400, 0х5В10, 0х6220. Това което пробвах е примерно на адрес 0х6220, да го изтрия и на негово място да запиша, моят тестов фонт, като на lpc17xx_flash_program_words((x * 0x1000)+0х220, xbuf, len >> 2); задавам отместване от 0х220, за да започна да записвам от 0х6220. Това обаче не сработва. Ако махна това отместване, данните се записват от 0х6000 -> OK. Въпросът ми е тия IAP процедури по флашването, могат ли примерно да почват от не кръгъл адрес (примерно 0х6220) и къде точно трябва да се гледа за това?

Не не могат. Организацията на FLASH-а е такава. Но можеш да отместиш данните в RAM-a. Естествено надявам се че ще се сетиш с какво да запълниш пространството между началото на сектора и началото на шрифта.
Другия вариант е да си заплюеш определени сектори само за тези данни(шрифтове). Всеки шрифт да започва от началото на нов сектор. Така презаписването им няма да влиза в конфликт с останалите код и данни.