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.

unsigned long long passing with ARM 5.1.1

Other Parts Discussed in Thread: OMAPL138

Having the typedef of:

typedef unsigned long long U64;

Then having a function defined like:

int some_function(U64 A, char *B, U64 C) { blah; blah; blah;}

A and B get passed properly but C does not.

If I chance the function to:

int some_function(U64 A, U64 C, char *B) { blah; blah; blah; }

Now everything gets passed properly.

Seems like a bug?

I couldnt find any recent discussions about this to see if it was logged or not.

CCS 5.5.0.00077

Here is the compiler line just incase it is something wtih that:

(This is the function that the library is in (It ends up in a library):)

"C:/TI_54/ccsv5/tools/compiler/arm_5.1.1/bin/armcl" -mv5e --code_state=32 --abi=eabi -me --include_path="C:/TI_54/ccsv5/tools/compiler/arm_5.1.1/include" --include_path="C:/CCS/ATP_28V/VSLED_Source_ATP/Data_Bus/h" --include_path="C:/CCS/ATP_28V/VSLED_Source_ATP/OS_Utils/h" --include_path="C:/CCS/ATP_28V/VSLED_Source_ATP/Misc/h" --include_path="C:/CCS/ATP_28V/VSLED_Source_ATP/Memory_Management/h" -g --define=xdc__strict --define=CHIP_OMAPL138 --define=VSLED_DEBUG --diag_warning=225 --display_error_number --preproc_with_compile --preproc_dependency="src/MM_SD_Flash.pp" --obj_directory="src" --cmd_file="./configPkg/compiler.opt" "../src/MM_SD_Flash.c"

Here is the compile line for the function making the call (This is in the final executable):

"C:/TI_54/ccsv5/tools/compiler/arm_5.1.1/bin/armcl" -mv5e --code_state=32 --abi=eabi -me --include_path="C:/TI_54/ccsv5/tools/compiler/arm_5.1.1/include" --include_path="C:/CCS/ATP_28V/VSLED_Source_ATP/DSP2ARM_ARM/h" --include_path="C:/CCS/ATP_28V/VSLED_Source_ATP/MCASP_DSP/h" --include_path="C:/CCS/ATP_28V/VSLED_Source_ATP/MCBSP_DSP/h" --include_path="C:/CCS/ATP_28V/VSLED_Source_ATP/SPI_DSP/h" --include_path="C:/CCS/ATP_28V/VSLED_Source_ATP/OS_Utils/h" --include_path="C:/CCS/ATP_28V/VSLED_Source_ATP/Misc/h" --include_path="C:/CCS/ATP_28V/VSLED_Source_ATP/Data_Bus/h" --include_path="C:/CCS/ATP_28V/VSLED_Source_ATP/Goodrich/h" --include_path="C:/CCS/ATP_28V/VSLED_Source_ATP/ARM_Main/ATP/h" --include_path="C:/CCS/ATP_28V/VSLED_Source_ATP/Memory_Management/h" --include_path="C:/TI_54/ndk_2_22_03_20/packages/ti/ndk/inc" --include_path="C:/TI_54/ndk_2_22_03_20/packages/ti/ndk/inc/tools" --include_path="C:/CCS/ATP_28V/VSLED_Source_ATP/OS_Utils_DSP/h" -g --relaxed_ansi --define=xdc__strict --define=VSLED_DEBUG --define=IPC_TURNED_ON --undefine=FRANKENSTIEN --diag_warning=225 --display_error_number --preproc_with_compile --preproc_dependency="ATP/c/NVRAM_Test.pp" --obj_directory="ATP/c" --cmd_file="./configPkg/compiler.opt" "../ATP/c/NVRAM_Test.c"

gmake[1]: Nothing to be done for `all'.

gmake[1]: Nothing to be done for `all'.

'Finished building: ../ATP/c/NVRAM_Test.c'

  • A function with the prototype int some_function(U64 A, char *B, U64 C) will pass parameters in the following way:

    A: R0,R1
    B: R2
    C: On stack

    I have tested this with the 5.1.1 release and it looks correct. Are you seeing the values passed in a different way?

  • Im not good enough at reading the ARM assemble code to tell how it is passing on the stack.

    A and B are in the registers as you said.

    I do know that the code was not behaving properly and that the debugger was showing C as some completely different then what was passed in.  Simple flipping B and C order made the function work correctly.

    Thanks,

     

  • Mike,

    Can you put together a test case that demonstrates the problem? Without a test case I cannot provide any more information.