Menu
▾
▴
[sdcc-devel] [ sdcc-Bugs-2999446 ] ds390 xram limit at 0x400000
|
From: SourceForge.net <no...@so...> - 2011-04-21 08:28:32
|
Bugs item #2999446, was opened at 2010-05-10 17:59 Message generated for change (Comment added) made by maartenbrock You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=2999446&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: linker Group: fixed >Status: Pending Resolution: Fixed Priority: 5 Private: No Submitted By: Jaroslav Ban (jaroban) Assigned to: Borut Ražem (borutr) Summary: ds390 xram limit at 0x400000 Initial Comment: the linker doesn't link files with ram above 0x400000 correctly. the ds390 allows the 4 kB internal RAM to be mapped to 0x400000-0x401000. i've tried changing lkarea.c [504] to: unsigned long xdatamap[131216]; (increasing the size). this fixes the problem (131216 * 32 = 0x401200 - for CAN memory space just in case) a related problem is that no warning is given that the internal limit is exceeded (in case some adventurer tried xram at 0xf00000) - find_empty_space is unaware of the hardcoded size limit. ---------------------------------------------------------------------- >Comment By: Maarten Brock (maartenbrock) Date: 2011-04-21 10:28 Message: It seems to me that this is now fixed so I've set it Pending. You can set the Status to Closed if you agree and without replies it will auto-close in a few weeks. ---------------------------------------------------------------------- Comment By: Jaroslav Ban (jaroban) Date: 2011-04-21 02:11 Message: Borut, finally found my mistake: the linker input file expects: -option flags output file input file 1 input file 2 .... i was missing the output file, just had input files, so the linker was clobbering main.rel and reading only input file 2... very silly mistake... Jaro ---------------------------------------------------------------------- Comment By: Jaroslav Ban (jaroban) Date: 2010-08-14 14:45 Message: Borut, sorry this took so long. Attached is my project. build_project builds it with all files included into main.c; build_project_link links several .rel files. The first one works... the second one restarts the code generation at address 0 for the second file (in this case system/routines.c) and overwrites the code from main.c. This could be due to something i'm doing wrong... but i had something similar happen when i allocated xram at a high address (0x400???) and the linker sent it to the code segment at 0 - again overwriting main.c. Also, if you look at my build script, i'm having to work around some issues - the main one is that the mcu resets to 16-bit mode but the compiler generates the first jump-to-main already in 24-bit mode. This is not a fatal error as it can be worked around, but neither does it work out-of-the-box. I also use a modified dis51 to verify the hex file generation - if someone is interested in that. Just added 24-bit jump and call instructions. Jaro ---------------------------------------------------------------------- Comment By: Borut Ražem (borutr) Date: 2010-07-25 08:59 Message: Jaro, this seems strange to me, since we are constantly linking several rel files in the regression testing process. Can you please provide some additional info, at least the command line you are using for compiling / linking. Borut ---------------------------------------------------------------------- Comment By: Jaroslav Ban (jaroban) Date: 2010-05-11 17:38 Message: Borut, I've tested #5823 and the linking issue is fixed... but the whole build has another problem - when linking multiple files together, the linker only outputs one of the .rel files to the hex file. it doesn't seem to depend on the order in which they are passed to the linker. i realize this is not enough info, will get more when i get back to this. i also have some suggestions about ds390 startup code if anyone is interested... Jaro ---------------------------------------------------------------------- Comment By: Borut Ražem (borutr) Date: 2010-05-10 22:53 Message: Fixed in svn revision #5823. Jaroslav, please try it and let me know if it is fixed correctly. Borut ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=2999446&group_id=599 |