audio data v.s. hpi communication.

John,

Just so I know the background of this problem, is it related to the same system as this previous thread: http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/115/p/57752/205516.aspx ?

-Tommy

Hi Tommy

Still looking for answers 6 months later.  I thought everything was settled.  We tested, went into production and found a problem where we think HPI communication is causing some amount of jitter on the audio.  As if edma transfer is delayed while transferring a host communication.  Here are a couple of thoughts:

• The HPI host side has an error where it may not wait for HRDY.  Do you know what the result is from this?
• HPI is stuck set at high priority.  Unless I’m missing the point this sucks and is stupid.
• Can I “turn off” HPI access from the DSP side?  If so at what point in the DMA cycle do I turn it off????
• Any thoughts (maybe example code) as to how I can achieve reliable audio transfer in and out of the DSP and provide communication via host comm. too?

John,

Is there an FAE helping you out?  It sounds like you have a situation that needs to be resolved quickly through direct support.

-Tommy

No, do you know of one?

Your local sales office should be able to put you in touch with someone: http://focus.ti.com/general/docs/salesrep/salesrep.tsp

John,

What details can you give us about the HPI transactions and about the audio data errors?

HPI: When the failure happens, is the HPI being used for reads or writes, or either or both? Are the HPI transactions 1 or 2 words, or a burst of auto-incrementing accesses (how many)?

McBSP: Do the failures only occur on the output from the DSP? Since samples are continuously being transmitted and received (in most design implementations), one sample being delayed usually means one sample being missed and the previous one being duplicated. Or is the whole sequence then delayed by one sample period? Is the failure always on the edge of a ping/pong buffer? Can you replace your outgoing data with an incrementing pattern so you can tell exactly what has gone wrong at the output and where in the buffer it is located?

How likely is it that your processing time puts you just on the edge of being able to get the data processed, so that the HPI might be slowing down the DSP processing and it misses a deadline for getting data sent out?

Regards,
RandyP

Sure, thanks for responding.

I appreciate any help I can get.  Here’s information about the system:

• The board has 8 6713’s running at 300MHz
• Each DSP is loaded and communicated with via HPI.
• Communication is minimal.  Just 12 or so words every couple seconds (not auto increment).  (and can be slower if needed).
• Each DSP handles one AES stream in and out over McBSP via EDMA.
• Audio buffers are 512 samples (32 bit words) of audio  sampled at 48KHz
• Audio is double buffered in and out.
• 512 audio samples at this rate represent 10.667mS in time.  My program execution time is about 7.5mS

On HPI and dma,  both use internal memory.  Host communication is at 0x200 and

Audio is perfect when HPI communication is disabled.  Even with communication enabled, everything is fine for a while.  Maybe once a day bad things happen.  As far as “bad things” there are two possibilities I have experimented with:

• Audio configured as high priority-  When a things go wrong, audio is altered, an actual sample is changed but audio returns to normal.  Not sure where communication goes wrong except to say the DSP int line is not sensed by the DSP. 
• Audio is configured as low priority-  When things go wrong, rather than a sample being altered all samples are correct but there is “jitter” in the audio. A sample is delayed.  Honestly I didn’t see  this personally but Norpak (now owned by Ross,  the folks who manufacture our encoder) have seen this.  

 I can't be sure if errors occur on the input or output.

As far as configuring EDMA and Serial port:

            config.opt = EDMA_OPT_RMK(

        EDMA_OPT_PRI_HIGH,                                         // EDMA_OPT_PRI_HIGH,

        EDMA_OPT_ESIZE_32BIT,

        EDMA_OPT_2DS_NO,

        EDMA_OPT_SUM_NONE,

        EDMA_OPT_2DD_NO,

        EDMA_OPT_DUM_INC,

        EDMA_OPT_TCINT_YES,

        EDMA_OPT_TCC_OF(RXPONGTCC),

        EDMA_OPT_LINK_YES,

        EDMA_OPT_FS_NO);

            config.src = (Uint32)_MCBSP_DRR0_ADDR;      

            config.cnt = (Uint32)DMA_BUFSIZE;                  

            config.dst = (Uint32)pongRX;                  

            config.idx = (Uint32)0;                           

            config.rld = (Uint32)ping_rcv_link & 0xffff;

            EDMA_config(hEdma_rcv[1], &config);

    /* Configure the Serial Port */

    spcreg = MCBSP_SPCR_RMK(

            MCBSP_SPCR_FREE_DEFAULT,

            MCBSP_SPCR_SOFT_DEFAULT,

            MCBSP_SPCR_FRST_NO,

            MCBSP_SPCR_GRST_NO,

            MCBSP_SPCR_XINTM_XRDY,

            MCBSP_SPCR_XSYNCERR_NO,

            MCBSP_SPCR_XRST_NO,

            MCBSP_SPCR_DLB_OFF,

            MCBSP_SPCR_RJUST_RZF,

            MCBSP_SPCR_CLKSTP_DISABLE,

            MCBSP_SPCR_DXENA_OFF,

            MCBSP_SPCR_RINTM_RRDY,

            MCBSP_SPCR_RSYNCERR_NO,

            MCBSP_SPCR_RRST_NO     

            );

    rcr = MCBSP_RCR_RMK(

            MCBSP_RCR_RPHASE_SINGLE,

            MCBSP_RCR_RFRLEN2_OF(0),

            MCBSP_RCR_RWDLEN2_32BIT,  

            MCBSP_RCR_RCOMPAND_8BITLSB,

            MCBSP_RCR_RFIG_YES,

            MCBSP_RCR_RDATDLY_0BIT,

            MCBSP_RCR_RFRLEN1_OF(0),

            MCBSP_RCR_RWDLEN1_32BIT,

            MCBSP_RCR_RWDREVRS_ENABLE);

    xcr = MCBSP_XCR_RMK(

            MCBSP_XCR_XPHASE_SINGLE,

            MCBSP_XCR_XFRLEN2_OF(0),

            MCBSP_XCR_XWDLEN2_32BIT,  

            MCBSP_XCR_XCOMPAND_8BITLSB,

            MCBSP_XCR_XFIG_YES,

            MCBSP_XCR_XDATDLY_0BIT,

            MCBSP_XCR_XFRLEN1_OF(0),

            MCBSP_XCR_XWDLEN1_32BIT,

            /*MCBSP_XCR_XWDREVRS_DISABLE*/MCBSP_XCR_XWDREVRS_ENABLE);

srgr =    MCBSP_SRGR_RMK(

            MCBSP_SRGR_GSYNC_SYNC,

            MCBSP_SRGR_CLKSP_RISING,

            MCBSP_SRGR_CLKSM_CLKS,

            MCBSP_SRGR_FSGM_FSG,

            MCBSP_SRGR_FPER_OF(1),

            MCBSP_SRGR_FWID_OF(0),

            MCBSP_SRGR_CLKGDV_OF(0));

            pcr = MCBSP_FMKS(PCR,FSXM,INTERNAL) | MCBSP_FMKS(PCR,CLKXM,OUTPUT)|

                          MCBSP_FMKS(PCR,CLKXP,FALLING) | MCBSP_FMKS(PCR,CLKRP,RISING);

    MCBSP_configArgs(hMcbsp,

            spcreg,

            rcr,

            xcr,

            srgr,

        MCBSP_MCR_DEFAULT,

        MCBSP_RCER_DEFAULT,

        MCBSP_XCER_DEFAULT,

        pcr);

 I tried putting in screen shots from code composer but it didn't work.  Can I email you? 

 Anything else you need please ask!!!

John

I have not read it all (about to take off on a plane).

Which direction is the 12 or so words of communication on the HPI?

"the DSP int line": this could be several things, from the EDMA, the McBSP, or the HPI. Which is it?

John Peiffer said:

I can't be sure if errors occur on the input or output.

That seems odd. Can you explain why that is? What kind of processing are you doing?

Can you reduce the processing time by just forwarding input to output, or something like that? There could be big delays from interrupts or various things that could take up your extra couple of milliseconds per audio buffer.

I'll read more, but if you have a chance to help me understand better, it would help. Busy weekend coming up.

Hi Randy,

Hope you survived your weekend.  Here are some answers. Would you like for me to send source???

Host writes and reads small amounts of data via HPI bus.

DSP int refers to DSP interrupt.  Here’s how the host works:

Host looks at HRDY to see if DSP is available for HPI communication.

Host writes message (12 or so words) starting at address 0x200.

Host signals message is waiting by host to DSP interrupt 9

DSP is interrupted and calls dispatcher. 

Dispatcher launches semaphore.

Host comm. task is pending (lower priority than audio task). 

Interrupt is cleared by HPI_setDspint(1);

Message is processed replaced with a reply at same address 0x200

DSP sets HINT by HPI_setHint(1);          

Host reads and cancels HINT (BTW: DSP does TSK_yield till HINT is cleared.

I’ve had a unit running for 5 days without error.  This one has NO host communication.  All others have failed. 

Failures occur on the order of  about12 hours (but times are random).

I will experiment with reducing processing loads and let you know.

Is there an example of how HPI communication and audio can co-exist???

Thanks for your help,

John

Update:

·          Through experimentation were able to determine host (HPI) traffic interferers with audio data through DMA.

·          Reducing DSP load does not help.

·          Problem occurs some number of hours after startup. 

o         Assume there is an asynchronous relationship between DMA cycle and host access.

What I would like is a way to gate host communication.  The host currently looks at HRDY.  Is there a way I can control this signal to effectively synchronize it with the DMA cycle?  Is there a more appropriate signal to use (Hint maybe?).

 John

John,

Since we are trying to debug together remotely over a very slow medium, it would help a lot if you are able to be more verbose. What was the experimentation that determined that HPI interferes with audio DMA? What did you do to reduce DSP load and how did you determine it did not help?

What else is going on in your DSP? Other DMA channels are likely being used from time-to-time, right? What priority levels do those use?

John Peiffer said:

What I would like is a way to gate host communication.  The host currently looks at HRDY.  Is there a way I can control this signal to effectively synchronize it with the DMA cycle?  Is there a more appropriate signal to use (Hint maybe?).

I cannot think of anything that would do what you really want to do. The biggest reason is that you have no way of knowing when the McBSP's DMA is going to happen. The most likely problem would be something stalling the DMA right around the FS, but this window could be from slightly before to slightly after FS.

You could try sending the FS to the host as an interrupt of GPIO or timer trigger, then use it to pace the HPI comms so only 1 word goes across HPI per FS. As long as HPI writes are to different non-incrementing addresses each time, they should not build up into a burst. I am not sure I understand your HPI details yet to be able to know what will happen. More detail or examples for the HPI comm could help.

An artificial delay from FS could also help with the pacing, such as waiting until the half-way point 16 bit times after FS.

To really predict a cause or solution, the nature of the audio failure is needed. Is it on the receive side or the xmit side, or both? Is it corrupted data or missing+duplicated data? These answers can help direct more targeted debug.

Is the failure related in time to the host's HRDY problem? A logic analyzer might be able to catch this.

One debug test could be to use the same data buffer all the time rather than ping/ponging. At least for the output, you could have a fixed data pattern going out and somehow trigger on the output pattern being different and noting the difference.

Another debug test would be to put one or both of the McBSP buffers in external non-cached memory. You could use a QDMA to move the data from there to an internal buffer for processing, but the processing is not really interesting to the problem if the DSP load does not have an effect.

To build on what I said about "the most likely problem", I am talking about the DMA failing to meet the real-time requirement of the McBSP when it comes time to move data in and out. But you have the most efficient setup since you are using 32-bit words for both transmit and receive. This means you have close to 20us at 48KHz. That is not an infinite amount of time, but it is a lot of time.

So one question becomes "what all could interfere with meeting the real-time requirement from RRDY to DMA writing before the next data needs to be shifted in?" or the same for transmit. This may be the only question, at least it is the main one that I suspect, for what that is worth.

Can you increase the audio sample rate faster than 48KHz? Or slow it down?

If DSP load really has no effect, then you might be able to just wrap receive data to transmit data and use some means to compare the two streams to catch the failure.

Your experimentation with HPI may have been forcing more activity and seeing it happen more often. That would be good to use, if it is so.

Scatter-shooting debug ideas is not very comfortable for me. I work best with data and details. But another idea is to use cache coherency commands to make sure all the data is cleaned out of L1D that will be accessed in the L2 buffers. This is related to my suggestion to use non-cached external memory for the buffers. But for the L2 buffers, you can try writeback-invalidates for transmit buffers and invalidates for receive buffers. You could also try having the CPU read 2 other buffers that overlap the L1D pages for the McBSP buffers, forcing the data to be cleaned out more slowly (might be less bad affect on the DMA activity.

That is all I have right now.

Regards,
RandyP

Randy,

Agree this is a poor way to communicate.  Again, I’d be happy to send code.  To answer your questions:  

What was the experimentation that determined that HPI interferes with audio DMA?

• With the system running normally we see an error (I’ll try to describe this below) about once a night.  I disabled the task that talks to the DSP board and there have been no further errors since (running for 4 days now).  Also the host and DMA timing are asynchronous.  Historically the 6711 gave similar problems but were manageable by inserting code to mask interrupts while processing audio data.  For some reason the 6713 does not respond the same way.  We are trying to catch an error along with HPI transfer in an attempt to prove some interaction. 

What did you do to reduce DSP load and how did you determine it did not help?

• We insert a number of different watermarks.  I tried each independently.  This maintained the same memory/ program footprint but with less processing load.

What priority levels do those use?

• Interesting question.  I’ve experimented with this a lot.  We initially had this problem when audio DMA was set to high priority.  In that case the error was different.  The DSP would NOT see the host’s interrupt (DSPINT).  The system would assume the DSP card had failed and would reload.  I read SPRA996 page 15 about priority inversion.  I set the audio DMA to low priority and all my problems seemed to go away.  

The error- The DSP card is part of a larger system. Audio can be connected by AES audio.  Here we have simple AES receivers/ transmitters connected to the DSP’s serial ports.  We cannot detect an error with AES audio.  We also support SDI embedded audio.  Here a subsystem that separates audio from an embedded SDI video signal.  Audio is fed to a DSP via serial port.  Output from the DSP’s serial port is connected to a re-embedder.  This is where the audio is re-inserted into a video stream.  Two audio pair are inserted as a group.  The important thing here is the audio pair is in correct time. One WRT to another.  This is where we suspect a stall of some sort.  The company we partner with is doing diagnostics to detect the error.  As we dig up more clues I’ll try to keep you up to date.    

Here is one example:  This is output from the serial port.  Notice how the line marked damaged Y looks like may have been shifted right.  (correct pattern should have been 0100……

    A                      A

    0                      2

ZYSC0......................3VUCP

01000110000010010011111111110000 - valid Y

00001000110111101100000000000001 - valid X

00100111001000100101110000000001 - damaged Y

00001011101011001100000000000001 - valid X

01001110010000001011111111110001 - valid Y

00001011010011101100000000000001 - valid X

Again, my assumption is the audio DMA data, HPI access and L2 controller are causing stall in the transfer request queues.  Sort of a perfect storm scenario. 

On your comment:

But another idea is to use cache coherency commands to make sure all the data is cleaned out of L1D that will be accessed in the L2 buffers. How? This is related to my suggestion to use non-cached external memory for the buffers  (which buffers?  DMA buffers? . But for the L2 buffers, you can try writeback-invalidates for transmit buffers and invalidates for receive buffers. You could also try having the CPU read 2 other buffers that overlap the L1D pages for the McBSP buffers, forcing the data to be cleaned out more slowly (might be less bad affect on the DMA activity.

Can you give some concrete examples.  I’ll try anything.  And thanks for your help!!!

We can start right now with agreeing that I am very ignorant. Your difficult job is to make me knowledgeable. Once you get me there, either you will have come to a solution to your problem or I will be able to help you find it. We can hope, at least.

John Peiffer said:

Two audio pair are inserted as a group.  The important thing here is the audio pair is in correct time. One WRT to another.

All three of these sentences leave me unsure of exactly what you are saying. 1) Does "two audio pair" mean two McBSP streams or four, or what exactly? 2) It was "two" audio pair and now "the" audio pair. 3) WRT = Write or With Respect To or some audio acronym like the other capitalized terms? 4) What exactly does correct time mean?

John Peiffer said:

Here is one example:  This is output from the serial port.  Notice how the line marked damaged Y looks like may have been shifted right.  (correct pattern should have been 0100……

 

    A                      A

    0                      2

ZYSC0......................3VUCP

01000110000010010011111111110000 - valid Y

00001000110111101100000000000001 - valid X

00100111001000100101110000000001 - damaged Y

00001011101011001100000000000001 - valid X

01001110010000001011111111110001 - valid Y

00001011010011101100000000000001 - valid X

It looks like this should be a very helpful table. The headings do not convey any meaning to me, though (A0, A2, AYSC0, 3VUCP). The yellow-highlighted 0 seems to be an extra 0 and you are saying the rest of the data is shifted right, but I am quite confused by what this is trying to show. Do you mean that the McBSP data appears to be off by one bit rather than by one 32-bit word, and that all the data from then on is shifted by one bit too late?

I am not sure if X and Y are two halves of an audio pair or each is an audio pair. I am not sure what the correct timing is supposed to be.

When you say this is output from the serial port, do you mean output from the McBSP or from the SDI after being further manipulated?

John Peiffer said:

But another idea is to use cache coherency commands to make sure all the data is cleaned out of L1D that will be accessed in the L2 buffers. How?

The CSL has a CACHE module of commands for maintaining cache coherency. The CACHE_wbInvL1d(void *blockPtr,Uint32 byteCnt,CACHE_Wait wait) function could be used to make sure your output buffers that the DMA is copying to the McBSP are not retained in the L1D cache. This could improve the performance of the DMA operation.

John Peiffer said:

This is related to my suggestion to use non-cached external memory for the buffers  (which buffers?  DMA buffers?

Once you have completed the DSP processing on the audio data, that data is sitting in a buffer that will then be copied via DMA to the McBSP. That is the buffer I am talking about. If you allocate a buffer in external memory, and have the MAR bit for that region of external memory turned off (0), then that area will not be cached. At the end of the DSP processing, you could then do an extra DMA block copy that copies the data from the internal L2 memory to this non-cached buffer and let the DMA to the McBSP use that external buffer. This adds some overhead to the DSP processing, but if that solves or improves the problem and it does not run you past the available time budget, then great.

Hi Randy,

You are a Genius!  I put in the CACHE_wbInvL1d(void *blockPtr,Uint32 byteCnt,CACHE_Wait wait) and things are much more stable.  Not perfect but better.

I have audio set to low priority in the DMA (an idea I got from SPRA996 6.3 page 17).  When I switch it to high priority though, I get periodic audio errors (quiet spots in audio).  Any thoughts?  The only thing I have that “intentionally” queue’s up transfer requests is ping pong input and output of audio and HPI communication (which I eliminated for the purpose of this test).

What tools are at my disposal that recommend to diagnose the effects of cache and other events generating transfer requests on the Transfer controller (maybe mistakenly assuming this is the source of my problem)?  Any other helpful hints are invited too!

John      

John Peiffer said:

I put in the CACHE_wbInvL1d(void *blockPtr,Uint32 byteCnt,CACHE_Wait wait) and things are much more stable.  Not perfect but better.

The reason for suggesting this was the minute possibility that a cache operation was causing a stall for the McBSP data at just the wrong time when an HPI write also comes in and perhaps it triggers a cache operation, too. Even the DSP could be doing something that triggers a cache operation, and some of these would queue up in the Urgent Queue to be serviced before the Low priority Queue for the McBSP transfer. If that McBSP then also triggered an L1D cache snoop delay from L2, then that would just be one more delay that could get in the way.

You seem to have a lot of time between one 48KHz/32-bits transfer to the next. But there may be a bit time or two taken up by the McBSP between when it copies from the DRR to the RBR and the corresponding trigger REVT event to the EDMA channel. There will be a few clock cycles to get from that REVT to where the Transfer Request gets forwarded to the Transfer Controller. And pre-existing TRs in the higher priority queues will get done before the ones in the lower priority queues. So L2 cache line fills and flushes can take priority for a little bit of time; how much of your program and data are in external memory? And HPI transfers will also take priority for a little bit of time with a small limited number of HPI transfers being queued up.

If all of this hits right after the last word has been transferred from ping or pong, then the EDMA also has to do a link operation, which could slow down that McBSP REVT from getting across, and if both transmit and receive channels are linking at the same time, that would be still a little more delay thrown in there.

The forced writeback-invalidate is not functionally required, because this gets handled automatically by the hardware so that you will always get the right data. But the forced operation makes sure that some small amount of delay is not introduced later when dirty cache lines have to be accessed. A very subtle situation, and not really possible (or at least not easy) to detect from the outside.

John Peiffer said:

I have audio set to low priority in the DMA (an idea I got from SPRA996 6.3 page 17).

It is always good to spread the queue-usage across the several queues, so since the L2 controller uses Q0 and HPI uses Q1, it makes sense for EDMA to use Q2. SPRAA00 looks like it could be interesting, too. I saw it mentioned in SPRA996, but I have not read it recently.

Do you use QDMA in your audio processing, or anywhere in your code?
Do you use any other EDMA channels at all in the application?

John Peiffer said:

What tools are at my disposal . . .

Unfortunately, the simulator is the place to do detailed cache analysis. And it is pretty hard to get randomly sequenced things to happen at just the wrong time without knowing exactly what those randomly sequenced things are. The simulator can give you excellent insight into cache stalls, but combining that with external events is tough to do.

We did learn a lot from the C6x1x EDMA when we upgraded it to EDMA2 in the C64xx family, and even more from that when we moved to EDMA3 in the C64x+ family. That does not help you here, but it might at least make you a little more at ease about your next project on a newer DSP.

I do not know if I have added any helpful hints here, but I have tried to explain what I know, in the hope that it will help you reach a "perfect" solution.

Regards,
Randy

Just one more question.  I’m sure you’re tired of this thread. 

We have experienced an issue where our host hangs.  We recently traced it to HRDY of the HPI bus.  Do you know of anything that could hang HRDY active?  Audio continues to be processed by the DSP but HRDY seems latched forever.

John,

On Nov 11 you said that "The HPI host side has an error where it may not wait for HRDY." I cannot think of why this would lead to a permanent lock-out, but we would have to look at the signal waveforms you generate to try to follow what is happening.

But it is not easy and usually not possible to come up with a set of error scenarios that might lead to a particular hardware failure. The only practical approach that I can imagine is to put a logic analyzer on the HPI bus and trigger it on HRDY being high for a certain amount of time. Is that a possibility to try?

Do you know what the conditions are that lead to HRDY being ignored by the host?

Looking at the signal waveforms in the HPI User's Guide, there are cases where HRDY "may" go high after HCS goes active and until the other signals do the right things, like HAS and HSTROBE, and maybe HCNTL[1:0] and HRW and HHWIL. If these signals do not behave as expected, the HPI could get into a state where it is waiting for some combination of signals that never happens after that.

Regards,
RandyP

Hi Randy,

I reduced the size of L2 cache and used the internal memory for audio arrays that were located in external memory.

In desperation, I also inserted the following at the completion of audio processing. This was in an effort to reduce cache writebacks and HPI memory transfers from interfering with audio transfer.

•                         CACHE_clean(CACHE_L2ALL,(void *)0x0,0x0);
•                         CACHE_clean(CACHE_L1DALL,(void *)0x0,0x0);

So with moving external memory internal and the cache clean I now average one audio sample error in 2.75 days.  Haven’t had an HPI bus lockout either.  (we were experiencing HRDY going, and staying high forever). 

Wish I had better visibility into the inner workings of the EDMA, at the transfer request level.  I’d also like to know more about what could hang the HRDY.

The good news, this defiantly had a positive effect. The bad news, working with it is like voodoo. 

Thanks for all your help.  Any new ideas, I’m all ears.

John

How does the rate of one error per 2.75 days work for you? Do you know anything more about the nature of that audio sample error? Zero, FF, repeated value, random noise?

EDMA3 adds a lot of visibility and debug features, because we found that this was lacking in the previous releases. A lot of good that does for you, though.

To figure out more, we really need more information about the nature of the failure. Toggling a GPIO at the beginning of each new ping/pong transition would help, assuming you can trigger something on the actual failure (is that possible?). The emulation logic can be setup to cause a breakpoint when one of the EMU0/1 pins is pulled, so it is possible to go from an external comparison to an internal breakpoint to find out (possibly) where the DSP was when the failure occurred. One problem is that the EDMA may keep running forever anyway, and another is that it takes several cycles before the DSP actually halts.

I am not sure what else to suggest, though.

Does the improvement move the priority of this problem down your list a little?

Regards,
RandyP

I'm working on getting more data.

I did an experiment last night.  I set the input and output DMA to high priority.  During the test we exprienced  HRDY hung in the asserted state.  This is something that does not happen on low priority. 

Is there a way I can reset this from the DSP side? 

Any inside information how it might get stuck?

Randy,

Does TI have, or maybe you can recommend, an expert to help us?  What we need is someone here ASAP to look at our system and recommend a solution.

Thanks,

John

John,

The best way to go is to contact your local TI sales office or local TI distribution company to get their advice on a consulting house. There are several TI-expert design support companies that are listed on our website. You can look at some of them here, or go to www.ti.com and click on Developer & Design House Network in the center of the page, then Elite Design Houses to get there.

Regards,
RandyP

Hi Randy,

Remember I mentioned HRDY sticks high from time to time?  From the Errata below, do you know (or can you find out) if this can occur from what is termed “Unexpected HPI Behavior”?  What about interaction with DMA transferrs?

HPI: Illegal Memory Access Can Result in Unexpected HPI Behavior

On C6713B silicon revision 2.0 and C6713 silicon revision 1.1, the DSP has a reserved memory range that is

mapped to the internal FIFO of the HPI for EDMA engine usage. This reserved memory range is located at

0x60000000 − 0x7FFFFFFF in the memory map. If CPU code (or a host access) happens to read/write from/to this

memory range, the internal HPI state machine can be corrupted, causing one or more of the following occurrences:

• Host reads/writes through the HPI fail. HPI reads return incorrect data, and/or HPI writes result in incorrect

data being written.

• Host reads/writes through the HPI take an unexpectedly long time. The HRDY signal stays high (not ready)

for an extended period of time.

• HPI locks up. HRDY stays high indefinitely.

The most common cause of this illegal access is uninitialized or stray pointers. To verify that the DSP program

does not perform this illegal memory access, the user can use the Advanced Event Triggering tools featured in

Code Composer Studio Integrated Development Environment (IDE) version 2.1 or later, with the latest emulation

driver. Below are the step-by-step instructions on how to trap a CPU access to the memory range 0x60000000 −

0x7FFFFFFF:

Do you have any reason to believe that your DSP code has an uninitialized or stray pointer, or that your host could do any read/write accesses to this reserved memory range? That would be a pretty severe bug in your program that would probably show up in some other way, also. The same would be true for errant DMA accesses - a block of data would be missing or corrupted in that case if a transfer had one of its pointers in this reserved area, so you would get a lot more than a single bad audio sample.

You can follow the steps described in the errata to try to detect errant accesses.

Hey Randy,

Quick question, what effect does LOG_printf have in release mode?  Any?

John 

John,

LOG_printf will operate the same in Debug and Release. LOG_printf uses a very small amount of memory and MIPS resources to save a small amount of information into a log buffer. If you do not have JTAG hooked up, the data will still be saved so that the performance is identical in either case. If you do have JTAG connected, you will still be able to get the log displays in the same way in both Debug and Release.

Regards,
RandyP

Getting really close.  Found a routine that stalls then overwrites the buffer that is presently in the DMA.

Is there a feature in code composer to break on execution of a function that takes longer than a specified time?

Thanks, John

John,

CCS and some DSPs support hardware breakpoints with a variety of trigger mechanisms. The C6713 is new enough to possibly have hardware breakpoints but old enough that it will not have very complex triggers. And I am not aware of even the newest ones having what you are asking for. But you could look in CCS under some of the menus to find if there are any hardware breakpoints available or any Advanced Debug tools.

A common debug technique is to set a GPIO at the beginning of a function and clear it at the end. Many of the DSPs will support a breakpoint when EMU0 or EMU1 is pulled low, so you could externally measure the pulse width and trigger a breakpoint via EMU0/1 (if supported).