Author Topic: Compiling uTakser 1.3 MC9S12NE64 in IAR  (Read 18568 times)

Offline tmanev

  • Newbie
  • *
  • Posts: 1
    • View Profile
Compiling uTakser 1.3 MC9S12NE64 in IAR
« on: April 09, 2009, 12:09:53 PM »
When I try to compile uTasker in IAR 3.11A for the first time everything compiles but there are some linker errors.
I get the linker error.
Fatal Error[e72]: Segment DBG_CODE must be defined in a segment definition option (-Z, -b or -P)
If I difine the DBG_CODE segment in the linker file  with -Z(CODE)DBG_CODE

I get the next linker error:
Error[e16]: Segment FILE_ROUTINE (size: 0x91 align: 0) is too long for segment definition. At least 0x11 more bytes needed. The problem occurred while 
processing the segment placement command "-Z(CODE)FILE_ROUTINE=FILE_ROUTINESTART-FILE_ROUTINEEND", where at the moment of 
placement the available memory ranges were "CODE:4000-407f"
   Reserved ranges relevant to this placement:
   4000-407f            FILE_ROUTINE

Any ideo on linking the project in iar.

BR,
Todor Manev
« Last Edit: April 09, 2009, 12:11:33 PM by tmanev »

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3239
    • View Profile
    • uTasker
Re: Compiling uTakser 1.3 MC9S12NE64 in IAR
« Reply #1 on: April 09, 2009, 12:50:38 PM »
Hi Todor

IAR 3.11A seems to be quite an old version. When the NE64 project was originally developed in 2004/2005 IAR 4.11 was used. It is well known that there are also often incompatibilities between IAR versions which sometimes need a smaller (or larger) adjustment somewhere (see ARM V4 compared to V5 - you need several days of effort to get a working V4 project running again with V5...!).

But in your case doesn't seem to be the main problem.

I don't know what the DBG_CODE is but you seem to have been able to solve it by adding the segment.

The FILE_ROUTINE is however something that I can explain. The uTasker project works with linear program memory and uses one bank for the file system. Since file system accesses require a bank to be switched, against a program bank, it is important that the file system access routines don't happen to be located in the bank that is switched out. Therefore the routines are forced to a certain location at the start of the internal FLASH so that this can never happen (this being a fixed bank that can't be switched out).

It looks as though the size of this region is too small for the code produced by your compiler version. I expect that, since it is an older compiler, it is also producing slightly larger code. The linker complains that it needs another 0x11 bytes of space. This can probably be compensated for by adjusting the setting in the linker script file uTasker_mc9s12ne64.xcl

// we force file control routine to start of code
Original:
-DFILE_ROUTINESTART=04000
-DFILE_ROUTINEEND=0407f


Adjusted to allocate another 0x11 bytes space:
-DFILE_ROUTINESTART=04000
-DFILE_ROUTINEEND=04090


Good luck

Regards

Mark

PS. Note that the NE64 is not recommended for new projects. Do also take a look at moving to the Coldfire M522XX since this is the best Freescale one to start with (there is also a device which is 98% pin compatible with an NE64!). A demo board costs $50 including debugger and 128k limited special edition of Codewarrior and enables much more powerful projects to be achieved with much less effort. Also the devices are no more expensive that an NE64, so there is no reason for anyone (educational users or professionals) to start new work or projects with the NE64.


Offline thamanjd

  • Jr. Member
  • **
  • Posts: 57
    • View Profile
Re: Compiling uTakser 1.3 MC9S12NE64 in IAR
« Reply #2 on: April 10, 2009, 08:03:28 AM »
I also recall this being an issue when i was evaluating IAR for use with the ne64 utasker project. And the solution was as Mark has described.

The DBG_CODE maybe has something to do with which mode you are compiling in. I think IAR has a Debug mode and a Release mode. I don't thing i ever used the Debug mode and the project was always set to Release. I dont recall running into the DBG_CODE error.

JD