LPC1114 - Keil uVision - ładowanie i uruchamianie z RAM

Cześć.
Mam przykładowy program na układ LPC1114 napisany w środowisku uVision3 Keila.
link do tych przykładów http://www.kamami.pl/dl/zl32arm.zip

Jak zrobić aby program ładowany i uruchamiany był z pamięci RAM zamiast z Flash.
Wiem że w AMRach to możliwe aby programy wykonywały się z RAMu, tylko jak się to ustawia i gdzie?

Ustawia się to w manualu.

4\/3!!

A mogę prosić o więcej szczegółów? Dopiero zaczynam, więc trochę się gubię.

W keilu nie mozna wyspecyfikować wybranych funkcji, aby uruchamiały się z ramu; niestety, chciałoby się słowo kluczowe typu __ramfunc, ale cóż, nie ma...
Istnieje tylko jedna mozliwość zmusić linker do umieszczania funkcji w ramie: na poziomie "modułu" (czyli pliku .c).
Da się to zrobić w dwojaki sposób:
1) Trudne: utworzyć scatter file (de facto skrypt linkera), wyspecyfikować region i sekcje w obszarze adresów ramu procesora, i kazać w konkretnej sekcji umieścić konkretny moduł...
2) Proste: prawym myszem klikasz na plik na liście po lewej stronie->"options for ......"->zakladka properties->memory assignment
Tu mozesz sobie wybrać z comboboxów, gdzie chcesz mieć jakie dane. Jeśli ustawisz Code/Const na IRAM, to wszystkie funkcje i consty obecne w wybranym module trafią do ramu (i do flasha zresztą też), i będą się z ramu wykonywać...

Przy czym wiadomo, że zupełnie nie ma sensu uruchamiać zwykłych funkcji z ramu, gdy flash ma ustawiony waitstate 0 (i rdzen chodzi odpowiednio wolno, bodajże do 24MHz, ale mogę się mylić). RAMfunkcje mają istotny sens, gdy rdzeń chodzi szybko, a flash ma waitstate!=0, gdyż wtedy kod wykonywany z flasha nie wykorzystuje pełnej prędkości rdzenia (bo flash jest powolny). Wtedy funkcje wykonujące się z RAMu wykonują się z pełną prędkością rdzenia.

Dzięki bo tego nie wiedziałem.
Sugerowałem się Ride7 bo tam jest taka opcja w ustawieniach i potem można (ale to w STM32) poprzez ustawienie BOOT (chodzi mi o piny) ustawić start z RAM.

Ale wychodzi na to że Keil nie ma takiej możliwości?

Keila wolę bo ma możliwość podpięcia klona ST-LINKa a Ride7 nie.

coooo? Od kiedy funkcjonalność pina BOOT w mikrokontrolerze zależy od środowiska, w którym ten mikrokontroler oprogramujesz?
A jak ci sie tak spodoba, to wszystkie moduly łącznie z rozbiegówką mozesz przecież zlinkować "do ramu". I wtedy flash będzie używany tylko do inicjalizacji ramu, ale z flasha nigdy zaden kod nie będzie się wykonywać...

Ale ja to zaczerpnąłem z opisu z EdW. Tam w kursie było opisane że w zależności od ustawień dwóch pinów BOOT1 i BOOT2 po stracie są trzy możliwości: alebo bootloader, albo Flash albo z RAM i teraz jak program jest tak napisany że ma się mieścić sę w RAM to całośc ładowana jest do RAM i stąd się zaczyna wykonywać. Z tym że to dotyczyło STM32 a nie LPC1114.

!! Nie wiem jaki tok myślenia zaprowadził cię do wniosku, aby używać dokumentacji do stm32 pracując z LPC1114!...
Sądzę, że najlepiej będzie, jeśli jednak zasugerujesz się manualem do LPC11xx, a nie STM32. Masz wtedy znacznie większe szanse na sukces przy uruchamianiu układu...

Ale ja wcale nie powiedziałem że stosuję STM32 do LPC. Gdzie tak pisze?

Mam zestaw startowy do jednego i drugiego. Wiem że tak nie można, chyba to jasne. Mi chodziło raczej o to jak zrobić aby program nie lądować za każdym razem do Flasha tylko do RAM. Na początku będę ładował do pamięci dośc często i szkoda mi było Flasha bo taki częste programowanie jednak niszczy ją.

Taki był cel pytania.

slawek55 wrote:

szkoda mi było Flasha bo taki częste programowanie jednak niszczy ją.

Daj sobie spokój z oszczędzaniem pamięci - nie znam nikogo komu udałoby się ją zajechać.

4\/3!!

Ok, teraz coś się wyjaśniło... Zdawałoby sie, że musiałbyś sobie sam napisać algorytm wpisywania danych w ram procesora (to się konfiguruje w ustawieniach flash tools), a z tego co widzę, keil ma gotowy algorytm zapisu tylko do flasha.

Poza tym, skoro nie chcesz katować procesora, może pobaw się symulatorem? Ten symulator ogólnie potrafi wszystko, łącznie z symulacją peryferiów zewnętrznych (np. pamięć po spi, machanie pinami, komunikacja uart...)

Wiesz właśnie zauważyłem cos dziwnego i na razie nie mogę sobie z tym poradzić.
W Keil jak kompiluje pliki a potem załaduje poprzez ST-Link (ikonka Load Flash) to program jakby wisi. Dopiero odłączenie od USB powoduje że to zaczyna działać.
Zestaw z Kamami ma na pokładzie klona ST-linka i z niego korzystam, ale w dokumentacji nie jest nic na ten temat napisane?

Wiesz może jak sobie z tym poradzić?

Nigdy nie korzystałem z st-linka, więc niewiele będę mógł stwierdzić. Na 99% jest to kwestia ustawień st-linka lub po prostu problem algorytmu jego obsługi w keilu, gdyż najpewniej występuje sytuacja, gdzie nie jest podnoszony reset po zakończeniu programowania, i procesor nie rusza...
Dla ustawień j-linka mam opcje wyboru sposobu resetu dla różnych typów procków, przed i po połączeniu z mikrokontrolerem. Może dla st-link jest podobnie...

slawek55 wrote:

Wiesz właśnie zauważyłem cos dziwnego i na razie nie mogę sobie z tym poradzić.
W Keil jak kompiluje pliki a potem załaduje poprzez ST-Link (ikonka Load Flash) to program jakby wisi. Dopiero odłączenie od USB powoduje że to zaczyna działać.
Zestaw z Kamami ma na pokładzie klona ST-linka i z niego korzystam, ale w dokumentacji nie jest nic na ten temat napisane?

Wiesz może jak sobie z tym poradzić?

Bo driver od ST-Linka pod Keila jest niedorobiony i trzeba to obejść trochę na około, np tak jak jest opisane tutaj : Link Ewentualnie po każdym wgraniu uruchomić debug i run, ale to jest bardzo niewygodne na dłuższą metę. Sposób z linka jest chyba najwygodniejszy.

Dzięki
Mam nadzieję że nie zrażę sie po kolejnych zacięciach.

Przy okazji mam jeszcze jedno pytanie bo w różnych źródłach różnie piszą.

Jakie instrukcje obsługują uC LPC1114 z rdzeniem Cortex-M0 Thumb, Thumb-2 czy jeszcze inne łączenie? A jakie uC STM32.
Dokumentacja uC mówi jedno a opis rdzeni na stronie ARM mówi drugie.

I przy okazji wszystkiego najlepszego w Nowym Roku i jeszcze raz dzięki za porady.

Sławek

Każdy Cortex-Mx (x=0,1,2,3,4) obsługuje zestaw instrukcji tylko Thumb2.
Nie wiem gdzie wyczytałeś, że jest inaczej. Ogólnie, Thumb i Thumb2 w rozumieniu Cortexów-Mx bywają nazywane po prostu Thumb, ale w rzeczywistości jest to Thumb2.

Pamietać należy, że pomiędzy T2 w CM0 a w CM3 jest rozbieżność, gdyż CM3 po prostu obsługuje więcej rozkazów T2 niż CM0. Podobnie, CM4 obsługuje wiecej rozkazów niż CM3.
Zresztą, jeśli bierzesz się za asm, najpotrzebniejszym dokumentem będzie dla ciebie Thumb2 Quick Reference Card
W dokumentacji rdzenia sprawdzisz, które instrukcje z tego zestawu są obsługiwane...

Jeśli masz wątpliwości co do rdzeni, a w dokumentacjach jest rozbierzność, to wiedz, że rację ma zawsze twórca rdzenia, nie jego implementer...

Cortex-M0 obsługuje tylko część instrukcji Thumb.

link

4\/3!!

Właśnie o to mi chodziło ;] Ale jakby nie patrzeć, nadal są to instrukcje T2...