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.
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.