#1644 ds390 xram limit at 0x400000

closed-fixed
linker (61)
5
2013-05-25
2010-05-10
No

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.

Discussion

  • Borut Ražem

    Borut Ražem - 2010-05-10

    Fixed in svn revision #5823.

    Jaroslav, please try it and let me know if it is fixed correctly.

    Borut

     
  • Borut Ražem

    Borut Ražem - 2010-05-10
    • assigned_to: nobody --> borutr
    • milestone: 100454 --> fixed
    • status: open --> pending-fixed
     
  • Jaroslav Ban

    Jaroslav Ban - 2010-05-11
    • status: pending-fixed --> open-fixed
     
  • Jaroslav Ban

    Jaroslav Ban - 2010-05-11

    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

     
  • Borut Ražem

    Borut Ražem - 2010-07-25

    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

     
  • Jaroslav Ban

    Jaroslav Ban - 2010-08-14
     
  • Jaroslav Ban

    Jaroslav Ban - 2010-08-14

    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

     
  • Jaroslav Ban

    Jaroslav Ban - 2011-04-21

    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

     
  • Maarten Brock

    Maarten Brock - 2011-04-21

    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.

     
  • Maarten Brock

    Maarten Brock - 2011-04-21
    • status: open-fixed --> pending-fixed
     
  • Jaroslav Ban

    Jaroslav Ban - 2011-04-21
    • status: pending-fixed --> closed-fixed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks