• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 397 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.

DSP/BIOS Pipes on C6713B - weird problem

Steve Conner
Prodigy 210 points

Hi all

I have a weird problem here, where the Pipe (PIP) API sometimes returns a bad writer address causing me to overwrite my own code space with data.

It is hard to verify/debug as it leads to the mother of all crashes, to the point where the JTAG debugger can't even connect without a reset of the DSP, and that of course mangles the evidence.

And, it only happens in release builds when the code is optimized, and only about half of the DSP boards in our first batch manifest the issue.

I'm just wondering if anyone has seen anything like this before when using pipes. Are there any known issues? As far as I know, I'm running BIOS 5.31.02.

Finally I see the PIP API is deprecated: is this for a good reason?

Steve Conner

  • 0
    TI__Mastermind 26780 points

    Steve,

    I just searched the bug database and there isn’t anything outstanding for PIP. 

    From your description of the failures it sounds like a very close timing/race condition.  So close that it can work on some hardware but have intermittent issues on other. 

    Is it possible to instrument the code a bit to detect a bad address (one that is not in a known set of good buffer addresses), and halt the program at that point before the corruption and crash? 

    Also, what level of optimization are you using?

    PIP was deprecated because it had overlapping functionality with other modules, and there was a move to simplify interfaces, and reduce redundancy and complexity.  It wasn’t deprecated because of bugs.

    Scott

  • 0 in reply to ScottG
    Prodigy 210 points

    Hi Scott, thanks for the reply.

    I found the bug, and as usual it was something completely different to what I thought. The logic in my startup sequence was wrong: I was trying to stop data acquisition before it had been started. This amounted to calling EDMA_disable, MCBSP_close and so on before the corresponding enable/open functions had been called and handles obtained.

    I guess the behaviour of one of the functions in that case is "undefined" as in smashing the stack or telling the DMA controller to overwrite random bits of memory, and the pipe data structure got corrupted that way.

    I fixed that and the "bad" samples I got from the factory are now 100% working. So, sorry for casting aspersions on DSP/BIOS! :-)

    Steve

  • 0 in reply to Steve Conner
    TI__Mastermind 26780 points

    Steve,

    OK, great, thanks for reporting back, glad to hear the problem is resolved!

    No problem about any aspersions, it was a valid question.  PIP was always my favorite module, and I was sad to see it go. :OP

    Scott