Z nudów odkopałem płytki deweloperskie do procków na rdzeniu ARM7. Mam dwie. Jedna na LPC2129 od NXP, druga na AT91SAM7XC256 od Atmela. Napisałem kod startowy i… pojawił się problem. Nie byłem w stanie debugować kodu. Walczyłem z tym przez kilka ładnych godzin. Jednak bez skutku. Zastanawiałem się co zepsułem, ale po zarwanej nocy okazało się, że nie zepsułem nic. Problemem jest „nowoczesne” środowisko…

Moje obecne środowisko stoi na maszynie wirutalnej Ubuntu 14.04 (VMPlayer). System hosta to Windows. Eclipse LUNA, wtyczka GNU ARM Eclipse i toolchain to Codesourcery (najświeższe). Do debugowania używam Openocd 0.7.0 i interfejsu KT-Link (który zawsze się sprawdzał). Dla rdzeni Cortex M-3 wszystko śmiga. Dla ARM7 zaczynają się dziać dziwne rzeczy. Jak już udało mi się doprowadzić do zatrzymania rdzenia i wrzucenia programu, to próba debugowania kończy się wyjątkiem Data Abort na procesorze i komunikatem z openocd:

memory read caused data abort (address: 0x10000004)

Z punktu widzenia procesora ma to sens, gdyż ten adres znajduje się w obszarze niezdefiniowanym. Pytanie kto i po co chce do tej pamięci sięgać. Los chciał, że w czeluściach Windowsa znalazłem stare środowisko do programowania. Konfiguracja identyczna, tylko wersje poszczególnych komponentów starsze. Tam ten sam kod mrugający diodą śmiga i debuguje się – pod witualką nie.

Sens zajmowania się tymi prockami stoi pod znakiem zapytania. LPC2129 będzie produkowany do 2016 roku. LPC2229 do 2023 roku. Świat już zapomniał o architekturze… Króluje Cortex wszelkiej maści… Z takich staroci to mam jeszcze AT91RM9200. ARM9 od Atmela. Ale to jest już o tyle ciekawe, że na tym stoi Linux.