Optimized UART Driver Crashes on Reads

Cecil

Hi,

I am interfacing my C6748 DSP hardware device with the PC via a FTDI USB to UART chip. I use the TI PSP UART driver to communicate with the FTDI chip which in turn translates the data to USB to interface with the PC.
Here are the tools and software versions I am using:

CCS: 4.2.4.00033

BIOS 5.41.9.34

PSP 01.30.01

Code Generation Tools: 6.1.19

The problem I have is that whenever I connect to a PC that needs to install the driver for the FTDI chip before it can connect to my device the UART driver crashes (i.e. throws a SYS_abort). I have narrowed the problem down to a possible crash in the GIO_iomCallback function in the gio_cbck.c file but I can't debug any further in the bios. My application continuously tries to read the UART interface using GIO_submit calls on a 128 alligned buffer with a specified callback function. Because GIO_submit is asynchronous I post a semaphore whenever I receive the callback from the IOM_READ command so I don't do two or more successive reads but block the task (with a corresponding SEM_pend on the same semaphore) till i have received the callback from the UART driver. I know I can use GIO_read which has its own internal semaphore but I have tried that and run into other problems in my application so I prefer to stick to the GIO_submit function.

I have realized that when I switch the UART driver I'm using to the debug version and not the release version my application doesn't crash anymore. The main difference between the debug and release versions are the removal of debug information from the uart driver and optimization (level 2) for the release build. As soon as I optimize the debug version of the uart driver that crashes too but I found if I place a LOG_printf call just before the call to invoke the application callback my application no longer crashes even with optimization level 2.

i.e LOG_printf before line 3081 in Uart.c Uart_localCompleteCurrentIO function : (*chanHandle->cbFxn) ((Ptr)chanHandle->cbArg, chanHandle->activeIOP);

So can you tell me the difference between the optimized and unoptimized versions that can cause this by taking a look at the asm output file of the uart driver? I think optimizing is probably omiting certain vital lines of code that may cause a crash given certain conditions like I described above. Using the unoptimized version of the driver in my application is not an option for me due to size/efficiency reasons.

Thanks,

Cecil

over 13 years ago

Raghavendra Maddikery over 13 years ago

TI__Expert 5500 points

Hi Cecil,

I am currently looking into this issue, and shall get back to you soon..

By the way, In which mode are you configuring the UART(interrupt/DMA)??

Thanks & regards,

Raghavendra

Cecil over 13 years ago in reply to Raghavendra Maddikery

Intellectual 345 points

Hi Raghavendra,

I am using the uart in interrupt (Uart_OpMode_INTERRUPT) mode.

Thanks.

Raghavendra Maddikery over 13 years ago in reply to Cecil

TI__Expert 5500 points

Hi Cecil,

I have a couple of questions..

At what priority is your task running?. How many tasks are you using in your application? Fixed length(bytes) of read is performed or random length?..

Also, can you please explain what exactly you are doing in the application callback?. Have you tried increasing the stack size and checked?

Let me know..

Best regards,

Raghavendra

Cecil over 13 years ago in reply to Raghavendra Maddikery

Intellectual 345 points

Hi Raghavendra,

The priority of my UART task is 4. I have four other tasks with higher priority than 4 none of which directly use the UART driver. I have 10 tasks in total but a few of them are run once and disabled.

I read a variable length of data. Basically whatever the application wants to read up to a maximum of 128 bytes at a time.

This is what my call to read looks like:

        uart_status = GIO_submit (mUartInHandle, IOM_READ, &mpReadBuffer[0], &size, &mCallBackStruct);

        if( uart_status == IOM_PENDING )
        {
            if(SEM_pend(mReadCbSem, SYS_FOREVER))
            {
                uart_status = mCallbackStatus;
                size = mCallBackBufferSize;
            }
        }

And this is my read callback function:

void CUartDriver::ReadCallback(sint32 status, uchar* bufp, uint32 size)
{
    mCallbackStatus = status;
    mpCallBackBuffer = bufp;
    mCallBackBufferSize = size;
    SEM_post(mReadCbSem);
}

mCallBackStruct is of type GIO_AppCallback and the callback function only updates the returned status of the GIO_submit call, the buffer pointer to the read data and the size of data read, then post the semaphore. Like I mentioned above, after calling SIO_submit I don't even make it into the callback before it crashes. I will test further to determine whether the driver is returning some other status other than IOM_PENDING before it crashes.

I have already verified that the stack size is not being exceeded in the ROV.

thanks

Raghavendra Maddikery over 13 years ago in reply to Cecil

TI__Expert 5500 points

Hi Cecil,

Would it be possible for you to make some modifications in your application and test?. Like –

Disable all the tasks in your application and just keep only the application task, UART task running and check its behavior. I understand it’s a little tedious work, but worth a try. If in case you do not observe any crash, you can proceed adding tasks one by one and check when exactly you come across crash!.

Having such step by step experiments can help us analyze the issue in a better way and debug further..

And,

Even if you are reading variable length data, do you know the data length in prior(before making each submit)?. Or is it random?.

Let us know your observations..

Best regards,

Raghavendra

Processors

Processors forum

Optimized UART Driver Crashes on Reads