Resolving deadlock when acquiring CSL semaphore

Damian,

Which version of SYS/BIOS and CSL are you using?

Alan

I'm not sure this question can be resolved on this forum as it appears to be a CSL related issue. CSL topics should be posted to appropriate DSP forum (e.g., TMS320C6000 High Performance DSPs).

Which component is issuing the calls to the Osal APIs?

Alan

I am using SYS/BIOS version 6.33.2.31 and CSL version is whatever ships with MCSDK PDK TMS320C6678 1.0.0.18

I originally posted it in the C6000 Multi Core DSP forum for the exact reason you mentioned, however it was moved here by staff.

The calls to the Osal are issued by the platform library (specifically the deadlock occurs when I call platform_get_info())

Hi,

Could you tell me the blink LED example project name and its path? I am interested in running it. Thanks.

It is from a tutorial that can be found in the SYS/BIOS user guide:

http://processors.wiki.ti.com/index.php/BIOS_MCSDK_2.0_User_Guide#Example_2_-_Building_and_running_your_first_tasking_application_using_MCSDK_and_BIOS

This, however, works. I run into trouble when I expand the example to a certain degree. I will try to build a minimal example that illustrates the behavior.

I am having the same issue with the 6657EVM board hanging in CSL_semAcquireDirect.  This question is marked as answered, but I do not see an answer.  Perhaps it was moved to a different forum?

It indeed has not been answered. And I have been too busy to investigate this further.

Hi,

I have exactly the same question as initially in this post:

I have an EMV 6678L. My question is twofold. Firstly, I have seen in some examples (esp. the blinking LED example) that four functions are included in the program, they are Osal_platformMalloc(), Osal_platformFree(), Osal_platformSpiCsEnter() and Osal_platformSpiCsEnter(), what is their purpose exactly and why are they needed?

Secondly, I have a very simple program doing some I/O, there is a static clock defined in the .cfg file. During the main routine before I call BIOS_start() I set the direction and values of some GPIO pins and call platform_get_info(). On some occasions (but not each time) this causes the program to be stuck in CSL_semAcquireDirect(). What could be the reason for this and how can I circumvent it?

I have this deadlock when I use the Example 2 of the BIOS MCSKD 2.0 User's Guide (Link, Example 2 - Building and running your first tasking application using MCSDK and BIOS).

I am using the following configuration:

• Board: TMS320C6678
• CCS: 5.3.0.00090
• Sys/Bios: 6.34.2.18
• MCDSK PDK: 1.1.2.5

Can anyone help?

Regards,

Timon

Hi Timon,

In the future, please open a new thread instead of responding to an old one.  It's better to do this especially for threads that are already mark as "Verfied answer" because those ones are sometimes overlooked (as we think it's closed essentially).  When you post a new thread, you can always reference the old one that has your similar issue.

Timon Achtnich said:

I have an EMV 6678L. My question is twofold. Firstly, I have seen in some examples (esp. the blinking LED example) that four functions are included in the program, they are Osal_platformMalloc(), Osal_platformFree(), Osal_platformSpiCsEnter() and Osal_platformSpiCsEnter(), what is their purpose exactly and why are they needed?

While I'm not too familiar w/ these functions, I'm pretty sure that they are wrapper functions to OS specific API calls.  They allow you to write OS-independent portable code.  You could probably circumvent them by calling the OS specific APIs in their place.

Regarding your MCSDK example question, I'll let the MCSDK team chime in as I'm not familiar with that example.

Steve