Search for the keyword "at" that is used to absolutely locate variables.
Btw. the old linker did not have a means to indicate memory overlap. > Hello. > > This may sound ridiculous but I'm not the original programmer and I have > absolutely no idea if the program does use located bits. Can you give an > example of how such code would look like? > > Basically I'm trying to mimic the original firmware using the newer > compiler > in hope that it will produce an output that works as well as the old > firmware does. Maybe pack-iram has nothing to do with it, but it's an > obvious thing I noted that is different. > > Greetings, > > Christian "BC" Svensson > Codelead Systems - http://www.codelead.se > > > On Sat, Jul 18, 2009 at 10:57 PM, Maarten Brock > <sourceforge.br...@dse.nl>wrote: > >> Hi, >> >> Are you using absolutely located bits? And are they declared in multiple >> source files (possibly through a .h file)? >> >> And why don't you like what --pack-iram gives? >> >> Maarten >> >> >> > Hello. >> > >> > I'm trying to port an application to SDCC 2.9.0 from SDCC 2.3.8. >> > Compiling using the old Makefile that is included works after adding a >> > couple of #defines to correct some renamed registers. >> > The firmware causes the unit to crash upon start in what looks like >> memory >> > corruption (e.g. characters like "[" are changed to "À"). >> > >> > I have an old memory map that looks like this: >> > Direct Internal RAM: >> > Name Start End Size Max >> > ---------------- -------- -------- -------- -------- >> > REG_BANK_0 0x00 0x07 8 8 >> > REG_BANK_1 0x08 0 8 >> > REG_BANK_2 0x10 0 8 >> > REG_BANK_3 0x18 0 8 >> > BSEG_BYTES 0x20 0x20 1 16 >> > DATA 0x21 0x62 66 128 >> > ---------------- -------- -------- -------- -------- >> > TOTAL: 0x00 0x62 75 128 >> > >> > Stack starts at: 0x63 (sp set to 0x62) with 157 bytes available >> > >> > Other memory: >> > Name Start End Size Max >> > ---------------- -------- -------- -------- -------- >> > INDIRECT RAM 0x80 0 128 >> > EXTERNAL RAM 0x0000 0x07bb 1980 65536 >> > ROM/EPROM/FLASH 0x0000 0xef90 61329 65536 >> > >> > This made me conclude I need the --no-pack-iram option since my map >> > generated by SDCC 2.9.0 is nowhere close to that. >> > I'm hoping to be able to use the packing functionality later but for >> now >> > I've chosen to disable it. >> > Adding the --no-pack-iram option makes the map look more reasonable - >> it's >> > correct in everything but the BSEG_BYTES segment is 2 bytes instead of >> 1. >> > This causes this error to arise: >> > >> > ?ASlink-Error-Internal memory overlap starting at 0x21. >> > >> > Is there a known change needed for this kind of error? >> > Any help would be appreciated. >> > >> > Greetings, >> > >> > Christian "BC" Svensson >> > Codelead Systems - http://www.codelead.se >> > ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
