• Locked Locked
  • Replies 14 replies
  • Subscribers 54 subscribers
  • Views 2434 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS570 problem with compiler / passing variables to the function.

Marcin Kawalec
Prodigy 130 points
Hello,
When programming TMS570 I have met with the problem of incorrect transmission of function arguments (12 of function arguments). It seems to me that the problem is with compiler / share to areas smaller than 32bit memory location such as 8 or 16 bit. Problem solved change of all variables passed to the function on 32-bit (uint32_t or int32_t). But this is not the solution of the problem ... this was forced solution. If someone know what is the reason of problem just tell.
Regards Marcin  
  • Prodigy 130 points
    This is the function:
    void funct_1(unsigned char * map, uint16_t x0, uint16_t y0, uint16_t x1, uint16_t y1, int16_t min, int16_t max, int16_t current, uint8_t BorderColor, uint8_t fillColor, uint8_t orientation, const unsigned short * font,uint8_t font_width, uint8_t font_height);

    and fuction call:
    funct_1(LCD,0,0,100,100,-150,150,0,8,M_PI, M_PI / 2.0,0,Terminal5x12,5,12);
    after change all of parameters to uint32_t type, it works. But it is't proper solution .
  • in reply to Marcin Kawalec
    TI__Mastermind 22375 points

    Marcin,

    I've forwarded your question to the compiler team.

  • in reply to Jean-Marc Mifsud
    TI__Guru**** 253380 points

    We need a test case which allows us to reproduce the problem.  Please preprocess the problem source and attach that to your next post.  Also show the compiler version and all the compiler build options.

    Thanks and regards,

    -George

  • TI__Guru* 84285 points
    Make sure you have a complete prototype of funct_1 visible before you make the function call.
  • Prodigy 130 points

    Hi everyone,


    I checked that variable is allocated in memory space but problem is with interpret it during reading. Short int is allocated on 32bit word like uint32. So this is the problem, variable type is interpreted incorrectly. I attached screenshot. On top is variables view. On right is function, and on left function call.


  • in reply to Marcin Kawalec
    TI__Guru* 84285 points
    Have you verified that you have a complete prototype of funct_1 visible before you make the function call?
  • in reply to Archaeologist
    Prodigy 130 points

    Yes, I have a complete definition of function in header file included in sys_main.c

  • in reply to Marcin Kawalec
    Prodigy 130 points

    Helo,

    For a clearer explanation attached next screen. Look for function call and variables after execution.


    Reading variable "unsigned char F" returns 0x00 -> but in memory stack(0x08000FF4) is 0x00000006.


    When in expressions I put: (char)*(0x08000FF4) it return properly value:0x06. ..... I don't know what is wrong ... I seem to me like a problem with endianess or another problem with the interpretation of the data from the stack. By red circle I selected variable "F" and its stack position.

    Anoher news: this problem occures for more than 4 variables passed in the function.

  • in reply to Marcin Kawalec
    Prodigy 130 points

    New fact: below is listening from diassebmly. Through registers [r0 - r3] variables are correctly put on stack. Next variables, all over the fourth are through by r12.

    Regardless of the type of the variable, r12 it  always a 32-bit word. [ r12, (sp #4) ] ...

  • in reply to Marcin Kawalec
    TI__Guru**** 253380 points

    To be able to do anything about this problem, we have to reproduce it ourselves.  We still lack a test case which allows us to do that.  Please preprocess the problem source code and attach that to your next post.  Also show the compiler options used, and the compiler version.

    Thanks and regards,

    -George

  • in reply to George Mock
    Prodigy 130 points

    Hi, below compiler settings and sys_main.ppsys_main.rar

  • in reply to Marcin Kawalec
    TI__Guru**** 253380 points

    While I am not certain, I suspect this is not a compiler problem, but a problem in how CCS displays arguments that are passed on the stack and are smaller than int.  What makes you think this is a problem with the compiler? 

    You showed some of the compiler settings, but not all of them.  When you build the project, the compiler executable armcl is invoked on each source file.  This appears in the Console window.  Please copy-n-paste the armcl command string for one source file (not everything) into a temporary text file.  Attach that text file to your next post.

    Thanks and regards,

    -George

  • in reply to George Mock
    Prodigy 130 points

    Hi,

    armcl is included. Now I know that this isn't problem with compiler but with development environment (CCS). Variables are stored on stack as bigendian, but CCS reads them as littleendian. This issue occures when more than 4 vaiabled passed on stack (via r12) and smaller than int. Maybe it is possible to change interpretation method in CCS to be32 ?

    Fullscreen armcl.txt Download 
    "C:/ti/ccsv6/tools/compiler/ti-cgt-arm_5.2.2/bin/armcl" -mv7R4 --code_state=32 --float_support=VFPv3D16 --abi=eabi -Ooff --include_path="C:/Users/Marcin/git/SPKRM1/include"

  • in reply to Marcin Kawalec
    TI__Guru**** 253380 points

    It turns out the entry SDSCM00049741 is already filed against the compiler for your problem.  However, this discussion sheds more light on things.  I added some detail to that entry and elevated the status.  Feel free to follow it with the SDOWP link below in my signature.

    At this point, I am not sure of the exact nature of the problem.  I think the problem is that the Dwarf debug information used to represent the arguments fails to model the fact that, even though the types of the problem arguments are short or char, they are stored in 4-byte wide locations on the stack. 

    Thanks and regards

    -George