• State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 21 subscribers
  • Views 1209 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

C167 - Using of "segmented cpu mode" with SMALL memory model

Luigi Accardo

Using the SMALL memory model of the C167, I have forced a function to be "far". The compiler generates the segmented call to this function (CALLS) but the linker/locater tries to allocate the code into the NCODE class instead of the FCODE class. The total program size overlaps the maximum allowed size of the NCODE class (64k) and the linker/locater generates the following message:

ERROR L116: SIZE OF CGROUP EXCEEDS 64K
GROUP: NCODE (1)


But from the Keil C166 User Guide:

The SMALL model uses the segmented CPU mode.
Variables are located in the near area and function calls generate near calls. This gives the same efficient code as the
TINY model, but code and data are not limited to 64KB.
The user can locate variables and functions with the far,huge, and xhuge memory types. These memory types enable full use of the 166/167 address capabilities.


Could anyone help me to solve the problem?

Thank you very much.

Parents
  • 0

    Hi Luigi,

    I think that using the far keyword with a function in small memory model doesn't force it to go to the FCODE class. It only ensures that a far call (CALLS) will be used to call it. It sort of makes sense, since C166 compiler allocates sections on a file-by-file basis, not on a function-by-function basis.
    So if you want to put your function in the FCODE class, you should define it in a separate source file and force all the functions from that file to go to the FCODE class by using

    #pragma RENAMECLASS (NCODE=FCODE)
    in the beginning of the file.

    - mike

Reply
  • 0

    Hi Luigi,

    I think that using the far keyword with a function in small memory model doesn't force it to go to the FCODE class. It only ensures that a far call (CALLS) will be used to call it. It sort of makes sense, since C166 compiler allocates sections on a file-by-file basis, not on a function-by-function basis.
    So if you want to put your function in the FCODE class, you should define it in a separate source file and force all the functions from that file to go to the FCODE class by using

    #pragma RENAMECLASS (NCODE=FCODE)
    in the beginning of the file.

    - mike

Children
  • 0 in reply to Mik Kleshov

    Hi Mike,
    I first want to thank you for the suggestion you gave me.

    I put the line

     #pragma RENAMECLASS (NCODE=FCODE)

    in the beginning of the file containing the functions I wanted to allocate in the section FCODE. The L166 put the functions in the FCODE class, but it also put both NCODE and FCODE classes in the same GROUP (NCODE). The size of the group still exceeded 64kbytes and the L166 generated the same message:

    ERROR L116: SIZE OF CGROUP EXCEEDS 64K
    GROUP: NCODE (1)

    In order to overcome this problem I tried to define a new group for the sections I wanted to put in the FCODE class, using the CGROUP assembler directive. As my source file was written in ANSI-C, I also used the C-directives

    #pragma SRC
    #pragma ASM / ENDASM

    Due to the use of the #pragma src directive, the C166 compiler didn't generate an obj file but a src file, then I had to use the A166 assembler to obtain the obj file . . .

    Too long and complicated . . .

    Finally, I decided to leave this way and use the MEDIUM model instead of the SMALL one.
    At the moment, I'm verifying how much this choice worsens the timing of the project.

    Thank you for your attention.

    Bye,
    Luigi

  • 0 in reply to Luigi Accardo

    Hi Luigi,

    I think I've found a way around. Still using

    #pragma RENAMECLASS (NCODE=FCODE)
    specify memory range for that class in Target Options / L166 Locate / User Classes:
    FCODE (0x10000-0x30000)
    That should do the trick.
    By the way, you don't have to invoke assembler for SRC files manually, uVision can do it for you: in Options for File '*.c' check options Generate Assembler SRC File and Assemble SRC File.

    Regards,
    - mike