Hello,
I am having trouble with some printf statements not being output to my console in CCS. My CCS project is fairly large, but this failure occurs very early in execution. My beginning of main.c and another function that gets called from main.c are shown below. When I run, "FGB Booting..." prints out just fine in the console. In addition, many other routines that are called following BIOS_start() can print to the console just fine. However, none of the printf calls in FGB_Init() (prior to BIOS_start()) print to the console. Any suggestions?
I have tried digging down into the assembly to see what could be happening. Unfortunately, I have not figured out enough to know how to resolve. I did notice that when printf works correctly, the address to the text data is pushed to a register; and then somewhere in the chain of calls, printf() - _printfi() - fputc(), that address gets pushed to the stack and decremented one character at a time (prior to the _doflush() - HOSTwrite() - writemsg() chain of calls). When printf() malfunctions, I see that the address to the relevant text is stored to a register during the call to printf(). Inside of printf() - prior to the call to _printfi() - the register containing the address of the text data gets overwritten prior to be pushed to the stack (if it ever gets pushed to the stack at all), and I never again see this address appear in the core registers or on the stack during the remainder of the printf() call chain. What could be going wrong?
I have tried manipulating stack sizes - at least I think I have. Here are some values from my Bios config file.
BIOS.heapSize = 0x200000;
heapMemParams.size = 0x200000;
Program.stack = 0x40000;
SysMin.bufSize = 0x2000;
int main() { printf("FGB Booting...\n");
FGB_Init();
void FGB_Init(void)
{
Uint8 temp0; I2C_ReturnType i2c_status; CSL_GpioRegsOvly gpioRegs = (CSL_GpioRegsOvly)CSL_GPIO_0_REGS;
printf("Initing the DM648 DSP\n"); DSP_Init();
printf("Initializing the GP Timers module\n"); GPTimer_Init();
Here is an excerpt of my console output:
FGB Booting...
��q���q���q���q���q���q���q���q���q���q�NetworkTask: Initializing NDK...NetworkTask: Starting network services...NetworkTask: NC_NetStart()cpsw_MDIO_Init
Notice the garbage characters where there should be print statements originating from my FGB_Init() routine.
Other info:
Bios: Version: bios_6_34_02_18
CCS: Version: 5.3.0.00090
Target: TMS320DM648
Hi,
It's probably not related, but I recently had a similar problem when using printf. It turned out that the linker decided to place the heap section .sysmem at adress 0, which is a valid L2 address for c64x DSPs. The result was that malloc returned NULL for the first allocated memory block within printf. The workaround was to change the L2 start adress to 0x4 in the linker command file.
Ralf
Thanks for the tip Ralf. Unfortunately, that is not the problem. I double-checked to make sure. The call to malloc is producing a buffer at 0xe0fe8f00. I can see when my initial printf text ("FGB Booting...\n") gets copied there. What happens to that buffer during my printf calls from fgb_init is pretty random. Still stuck on this.
Brock
Hi Brock,
Are you sure the address of the printf string constant is not written to the stack before the register gets overwritten ?
Here is an assembly excerpt from my example code:
CALLP.S2 printf (PC+14592 = 0x0080e960),B30080b074: BC45 || STW.D2T2 B4,*B15[1] /* This instruction copies the string constant address to the stack */0080b076: 0C6E || NOP 10080b078: 00000000 || NOP
I would expect the string constant address to be written to the stack before the call to printf() function is completed.
Can you try one other thing. Can you replace printf() call with System_printf() call in your FGB_init() code ? Also, what does the FGB_init() function do ?
Best,
Ashish
---------------------------------------------------------------------------------------------------------
Don't forget to verify answers to your forum questions by using the green "Verify Answer" button.
Hello Ashish,
I have good news and bad news. The good news is that I found the problem. The bad news is that I do not know why I was able to cause this.
No, the string constant address was not getting copied to the stack. That was the strange part. It was as if the compiler assumed it had already been copied to the stack. That is why I put this out on the forum. I thought that maybe I was onto a compiler defect.
The solution to this problem is to #include <stdio.h> in the source file using printf(). Somehow, somewhere, compilation was picking up another definition of printf() - at least I am assuming. I never got any warnings or errors for unresolved printf symbol when I did not include stdio.h. I always assumed somewhere in the chain of includes, stdio.h was getting included. Check out the code snippets below. The first snippet is the assembly from the case where stdio.h was not included. The lower snippet is the case where stdio.h was included. They are significanly different - mainly in that the case where stdio.h was included, the string constant address gets pushed to the stack.
71 printf("Initing the DM648 DSP\n");e17140f0: 023B5428 MVK.S1 0x76a8,A4e17140f4: 10092C13 CALLP.S2 printf (PC+18784 = 0xe1718a40),B3e17140f8: 0270BB68 || MVKH.S1 0xe1760000,A4
71 printf("Initing the DM648 DSP\n");e1713970: 023B642A MVK.S2 0x76c8,B4e1713974: 0270BB6A MVKH.S2 0xe1760000,B4e1713978: 100A2013 CALLP.S2 printf (PC+20736 = 0xe1718a60),B3e171397c: 023C22F6 || STW.D2T2 B4,*+SP[1]