I am developing custom board using TMS320C6713. I am also using SEED XDS560V2 emulator for direct connection to the device JTAG pins and ccxml file created on the basis of DSK6713+SEEDXDS560v2 template ccxml. After starting debug the device is connected to CCS, after that program is loaded (which was verified in the mem editor), symbols are also loaded (also verified in the mem editor), it is also possible to load/change the memory content, to see registers and so on.
But there is no jump to 'main function' after running debug (?). After start debug session debugger is at 0x0 address where, as it claims in the debug window, are no symbols. Forcing Target->"Go to Main" causes that CCS is trying to find the main function but it is hanging there. So I tried to manually change PC register to 'main' address and after that the green bar indicating debug position in the source code finally appears. In this way I am able to debug code like:
void main(void) { int a = 1; int b = 10; int c = 0; c = a + 3*b; printf("Hello World!\n"); while(c);}
till the printf function, where afer reaching it connection to the device is lost. This is probably because of some printf allocations omitted by manual "jump" to main function at the begining. I found this problem common in CCS4 and CCS5.
Could anyone help me to find out the solution. Is the special ccxml file needed for direct connection CCS to C6713? I have seen similar issues for C6713 DSK and solution there was to manually load program/symbols. But in my case it does not cause entering main function at all.
Hello,
kgelec After start debug session debugger is at 0x0 address where, as it claims in the debug window, are no symbols
Sounds like you hit the reset vector. Was the PC set to 0x0 after a program load or when you tried to run? Are you using and GEL startup file?
Thanks
ki
-----------------------------------
Don't forget to verify answers to your forum questions by using the green "Verify Answer" button.
Did you read the CCS Forum Guidelines & FAQ? If not, PLEASE read it. If you haven't read it in awhile, please read it again to see if any updates were made.
Having CCSv5 problems? Check out the CCSv5 Troubleshooting Guide
Click here to track an issue. Enter your bug id in the "Find Record ID" box
PC is at 0x0 after debug starts and program is loaded. However I wrote additional assembler file and linker script to boot it correctly from 0x0 address to _int_00 function, which I guess is the real starting point for the program. So the result is that after debug start PC is at 0x0 and jump vector to _c_int00 is at this address. By using assembler step I can pass to _c_int00 function and to _auto_init from there but in some certain point of this function PC goes to 0xfffffffc, after that to 0x0 - so it never gets to main function. I am really confused about it. Also, I am using modified gel file for initialization with my board and it seems to work good.
I am enclosing the whole test project.
I verified the above issue using DSK6713. The source of the problem is in endianess. I could easily check it thanks to the configuration switches on DSK. For my custom board big endian mode was meant to be used. So I tried my simple program in big endian also on 6713DSK and its behavior was exactly the same - it also couldn't get to main function. After change of endian mode to little for the same source code everything started to work perfectly. However during previous build 'Generate big endian code' option was selected and 'rts6700e.lib' was chosen as well.
What is the correct approach to build and debug big endian code? Do C6713 boot procedures work with big endian architectures?
For me is not big deal to use little instead of big endian on my board - actually I have already introduced this change, but I would like to know what I did wrong.
Thanks for the update. I'm surprised CCS did not give you an error about an endian mismatch. It usually does.
kgelecWhat is the correct approach to build and debug big endian code?
This should be fairly abstract to the user. Once the endianness is specified in the build options, CCS will generate big endian code and should pull in the correct run-time support libraries. Then as long as the target endianness matches, there is no change in the debug procedure.
kgelecDo C6713 boot procedures work with big endian architectures?
This question is probably best asked in the C67x device forum.