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.

HPI EDMA interaction issue?

 

System:

  • 8 6713 DSP’s
  • Audio serial -> McBsp->edma to internal memory
  • Program load and communication with host -> HPI to internal memory
  • Inter-DSP communication to internal memory (not used much)
  • Hardware has been in the field for years running code also used on 6711.  Never had this sort of problem before changing to all 6713 CSL internal memory size and cache.

Problem:

  • On startup, host loads, communicates some initial information (configuration and time).  Then asks for status repeatedly.  Audio sets up serial port and DMA. 
  • Once running, seems to work without issue.
  • Much of the time this works (10 out of 11 times)
  • When it fails:
    • Audio comes through
    • DSP SW that handles host communication does not know a message was sent
      • I caught this once in the debugger and the host interrupt occurs then ISR launches a SEM_ post.  The SEM_pend is never recognized.  And the area of internal memory (0x200) is all 0’s. 
    • After failing to communicate with the DSP, the host reloads the SW.  The DSP never recovers until power down.  Something is latched up in hardware and even reset does not clear it.  Even a quick power cycle does not clear.  Turning power off for 10 seconds seems to do the trick.

 

Any help/ suggestions would be appreciated.

  • Is the HPI still working when this failure occurs, or do you see HRDY high all the time?  I've seen strange behavior like this before when there is some rogue software that is reading or writing a reserved memory location.  In particular be careful with variables like this:

    int myvar;

    The above variable will not be initialized with any value.  You might be expecting it to be initialized to zero, but due to various legacy reasons that is not how that variable gets handled.  (When we switch to the ELF format instead of COFF we will be implementing the correct/expected behavior where that defaults to zero.)

    You might also look at using Hardware Watchpoints to monitor ranges of memory.  This article might be helpful too as it also uses watchpoints:

    http://processors.wiki.ti.com/index.php?title=Checking_for_Stack_Overflow_using_Unified_Breakpoint_Manager

     

  • Hi, thanks.  I say an app note that gives instruction for setting a watch point.  Trouble is I have CCS 3.3.82.13.  When I go to tools-> Advanced event triggering there is only event sequencer not event watchpoint.  Can I do this with the event sequencer?  How?

  • Hi John,

    Since you have CCS 3.3.82.13 (i.e. SR12) you will have the improved "Universal Breakpoint Manager" (UBM) integrated.  It is MUCH easier for setting these breakpoints.  The procedure would be the same as in the wiki page I mentioned.  You'll want to go to the properties though to configure for a range instead of a single address.  The main thing I find a bit non-intuitive is the fact that after you make changes there is a little "submit" button up above the properties.  You need to click it for your changes to take effect.

    There's a lot more info about this on the wiki.  You may want to start here:

    http://processors.wiki.ti.com/index.php/Advanced_Event_Triggering

    There are several articles that all relate.  The wiki could stand to be cleaned up a bit so you're not clicking around so much, but there's quite a bit of good info there right now.

    Brad