• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 51 subscribers
  • Views 267 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2640R2F: Simple Peripheral + sdraw - Semaphore problem

Shailesh Joshi
Intellectual 380 points
Part Number: CC2640R2F

I am trying to integrate the SDRAW example in the simple peripheral and running into some problems. I can initialize the sd card correctly. The card size etc is also recognized correctly meaning SPI communication is working okay. When writing a blob of data to the card (2048 bytes), I am running into a very specific problem. The system seems to freeze when writing the third sector. After setting a few breakpoints and navigating a maze of code, I am able to reduce the problem as summarized below.

The call trace before the freeze is as shown below

The SPICC26XXDMA_transfer function seems to be waiting for a semaphore as seen in the code below:

This particular line is executed at least 4 times before this without a problem. On the 5th time though, which corresponds with writing the 3rd data block, the system freezes. If I step through the assembly, I see that Semaphore.c is referenced. I also observed the memory region that is passed to the pend function and saw absolutely no changes there meaning the semaphore parameters hadn't changed.

What can cause this behavior? Is RTOS running out of memory? The sdraw and simple peripheral examples work alone without a hitch. I have used the sdraw example to write a few hundred MB of data and it always worked. Why am I witnessing this behavior after combining the two examples? Could someone suggest a solution for this?

  • 0
    Intellectual 380 points

    I have been chipping away a bit more at the problem. I have probably read every thread  even remotely related to this problem and have not found anything that could bring me closer to solving this problem.

    I have now counted the clock cycles need to execute the code. This has shown something interesting which micght help someone narrow down. In the transmitDataBlock functon in SDSPI.c, there are three calls to spiTransfer. I see that the execution of the first call always takes 90k+ cycles while the other two reuire less than 1k. Is it possible that the Semaphore is wrongly being used by some other code which is causing this delay?

  • 0 in reply to Shailesh Joshi
    TI__Mastermind 37780 points

    Hi Shailesh,

    Thank you for the detailed description. Can you specify which SDK you're using while I assign this to a subject matter expert?

    Best,

    Nate

  • 0 in reply to Nathan Block
    Intellectual 380 points

    I have been chipping at it myself for the past couple of days and seem to have found a workaround. I won't mark it as a solution just yet as I would be glad if someone would be able to explain if I have managed to actually solve the problem or just delayed the inevitable.

    After reading every possible post on this forum even remotely related to this issue, I came to the conclusion that something in the interrupt vector table was messing with the execution of the semaphores (HWI's were being triggered at one point). I tracked every exception using the ROV and figured out that there was a UART interrupt active. Since I am not using a UART console to output anythng, I deactivated it and everything seems to be working suddenly as I expected.

    I have not played with any other settings as I just dont have the time for it right now. As a follow up query though, it seems that I am reaching some heap limit for the RTOS as if the available SRAM drops below 3k, semaphore allocations fail. Can anyone suggest where to view and change these settings for the simple peripheral example?

  • 0 in reply to Nathan Block
    Intellectual 380 points

    Hi Nathan,

    my worst fears seem to have come true. On adding additional clocks and a semaphore, the problem seems to have returned. I am surprised that it is the same call to semaphore pend from the SPI DMA function that fails every single time.

    I am also surprised that this problem has been out there on the forums for nearly 5 years and that there is no concrete fix or any official suggestion / workaround of any kind available. I am already three weeks past my deadline thanks to this little gem. I would be grateful if the expert you mentioned could get in touch with me.

  • 0 in reply to Shailesh Joshi
    Intellectual 380 points

    The latest trace looks like this:

    I can zero it down to accessing some random address which is triggering a Hwi exception. I cannot figure out why this is happening though. I have compiled with every optimization level possible and still cannot see any improvement.

  • 0 in reply to Shailesh Joshi
    Intellectual 380 points

    I think I have solved the problem. I am extremely embarassed that I could not see the obvious. I had violated the golden rule that all RTOS sample code has to be executed in the context of a task. I was trying to read the sd card to get configuration parameters for tasks before enabling the BIOS. This reading outside a task made everything crash as there was no task for the semaphore to block when the pend was called! I now have a task which reads the SD card and I stop and configure my other clocks and tasks based on the values I read and it all works the way I expected it to.