This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

GDB-Monitor questions


Hi,

today I ported eCos on my LPC2119 board. Redboot and some test application works fine.
Because redboot uses almost the whole RAM i can't use it for source-level debugging. Now I build a gdb stub that uses about 6k RAM and 24k Flash - much mor usable than redboot. (But 6k RAM usage is still much since the device has only 16kB.)
However - since most application won't fit in the remaining RAM I'd like to debug the "user"-application from flash.
I had two ideas how to realize that. The first idea was to build the libtarget.a with source-level debug support. With such a 'libtarget.a' I could just write my application, link it together and debug it via the serial channel since the gdb-stub is included in the libtarget.a.


I tried that - but unfortunately this did not work - I don't know whether I made a mistake or this is impossible in principal The images I created this way just printed a '+' and did not communicate further. (Althougt the "standalone" gdb_module image worked absolute ok.) Has anyone an idea why this did not worked?

The second idea was to build the gdb stub the conventinonal way and download the gdb_module image to the target.
The user-application should get a different linker script to use only the ram and flash sectors that are unused. One advantage of that way would be a faster download since I wouldn't had to download the gdb-stub every time. Did anyone ever realized such a scenario?


Thank you,
 Martin L.

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]