TDU problem with multiple instances

Jean-Denis Boyer

Hello everyone.

I had problems running multiple instances of the Tone Detection Unit to detect Call Progress Tones (here, a North America dial tone).

I created 16 instances of the TDU, and enabled the CPT detector on only 4 channels, namely the ports 5, 6, 7 and 8. When I injected a dial tone into port 5 from the TDM side, I received a tdu_send_out for this port (as expected) with the right information. The problem was that, most of the time, I also received the same event on port 6 and 7, which were completely silent. When I stop the dial tone, it kept sending events on port 7, on and off. The behavior was completely erratic.

To make sure I wasn't injecting wrong data into the functions tduSendIn and tduReceiveIn, I captured the data and confirmed that the dial tone was only present in tduSendIn of port 5... The others being completely silent, no cross-talk, nothing.

I found a way to go around the problem and it most probably shows a bug in the library.

First of all, I made a simple test: Each time that tduSendIn and tduReceiveIn is called, I cleared the volatile scratch buffer with zeroes. This buffer is the second one, requested by tduGetSizes, which has a size of 1024 bytes, an alignment of 1024, and the volatile bit set. My understanding is that this buffer was not meant to store context data between calls, but only temporary data during calls. But, by clearing it before each call, the TDU STOPS reporting any events!!!

So, facing this problem, I assumed that this buffer could not be volatile, and I allocated a distinct and unique scratch buffer to each TDU instance. But it didn't work.

Then, I looked into the tduContext structure instance, and saw that each time tduNew is called, three members of tduContext received an address which falls into the scratch buffer. The three members are: work_buf, local_buf and magnitudes. But since I now have a different scratch buffer for each TDU instance, I had to "swap" the three members of tduContext, so that they fall into the specific scratch buffer, before each call to tduSendIn and tduReceiveIn. Now it works!!!

So my guess is that the TDU stores data into the scratch buffer between calls, and it shouldn't.

Did anyone face a similar problem?

Regards,

Jean Denis Boyer

over 12 years ago

0 Steven Connell over 12 years ago

TI__Mastermind 45025 points

Hi Jean Denis Boyer,

Which version of BIOS are you using?

Steve

0 Jean-Denis Boyer over 12 years ago in reply to Steven Connell

Prodigy 250 points

Hello Steven,

I'm using CCS v5.3.0 with SYS/BIOS 6.34.02.18, and VoLIB 2.0.0.3 C64x+ ELF, on a TNETV138.

Regards,

Jean-Denis Boyer

0 Jean-Denis Boyer over 12 years ago in reply to Jean-Denis Boyer

Prodigy 250 points

Steven,

Actually, the problem seems only related to the CPT detector. I didn't experience such problems with the DTMF detector, or the CNG detector (for fax).

Regards,

Jean-Denis

0 CharlieF over 12 years ago in reply to Jean-Denis Boyer

TI__Intellectual 1605 points

Hi Jean-Denis,

I am looking into this. I will let you know once I have briefly reviewed the code.

Best Regards, Charlie

0 CharlieF over 12 years ago in reply to CharlieF

TI__Intellectual 1605 points

Hi Jean-Denis,

I see what you've done, though one part doesn't yet make sense. When you allocate 16 "scratch" buffers (one per channel), do you pass the individual buffer pointers in to the tduNew() call? If so, the pointers for work_buf, magnitudes and local-buf should be set for you already. Maybe you're assigning these separately outside the calls to tduGetSizes() and tduNew()?

Can you do a few tasks for me since I don't have a multi-channel test platform readily available?

Forward the pointers that you see for the three "scratch" buffers.
Try assuming this buffer is scratch again, but provide ample space between each (manually). Maybe assign each 1024 bytes and 1024 alignment.

Regards, Charlie

0 CharlieF over 12 years ago in reply to CharlieF

TI__Intellectual 1605 points

Hi Jean-Denis,

One more quick question: what frame size are you using?

Regards, Charlie

0 Jean-Denis Boyer over 12 years ago in reply to CharlieF

Prodigy 250 points

Hi Charlie.

The frame size is 5 ms (40 samples) narrow band.

To answer your previous question, my scratch buffer is usually at 0x11800000 (internal L1 SRAM) for the various modules, but for the TDU, I moved it at 0x11810000 for the first channel, 0x11810400 for the second, 0x11810800 for the third, and so on. So they all have 1024 bytes, with equal spacing.

First, I tried to pass these various addresses to function tduNew, but it didn't work, because each time, it was overriding the tduContext (which is global) with the new address. I was still having the same problem. So, I tried to manually "switch" the addresses in the tduContext before each call to tduSendIn and tduReceiveIn. That way, the CPT detected correctly the dial tone.

Regards,

Jean-Denis

0 Jean-Denis Boyer over 12 years ago in reply to Jean-Denis Boyer

Prodigy 250 points

Also, the buffer addresses I see are the following:

tduContext.work_buf (short *) 0x11810000
tduContext.local_buf (short *) 0x1181006A
tduContext.magnitudes (int *) 0x118101FC

This for first channel, add 0x400 for second, 0x800 for third, and so on.

Jean-Denis

0 CharlieF over 12 years ago in reply to Jean-Denis Boyer

TI__Intellectual 1605 points

Hi Jean-Denis,

Please excuse my delayed response, it's been busy.

Can you provide some more information? I'm going to try to reproduce the failure locally.

I see you're using C64x+ ELF -- what endian are you using?
What power level is the dial tone?
Do you see the issue with two instances -- I want to create the minimal number of instances
What other detectors (if any) are enabled?

Thanks & Regards, Charlie

0 Jean-Denis Boyer over 12 years ago in reply to CharlieF

Prodigy 250 points

Hi Charlie.

Little Endian
-17dBm
I could not reproduce with only 2 instances, but I could with 3. The CPT detector was enabled on all 3 channels. I injected a dial tone in channel 1, and it was reported on both channels 1 and 3.
At that time, no other detector is enabled. Only the CPT.

Regards,

Jean-Denis

0 Jean-Denis Boyer over 12 years ago in reply to Jean-Denis Boyer

Prodigy 250 points

Hi Charlie.

Do you have any update on this issue?

Regards,

Jean-Denis

0 Alexander Kochetkov over 12 years ago

Prodigy 120 points

I'm experiencing another problem caused by the same issue.

I ran into problems with detecting dialtone in an environment with multiple TDU instances installed. Sometimes CPT detector does not indicate the presence of tone.

As the workaround proposed by Jean-Denis Boyer eliminate my problem, I assumed that the problems are related.

I managed to write a test that demonstrates that the results from CPT detector depend on the stale data in the scratch buffer. Please see the file attached.

To reproduce a multi-channel environment in the simulator, I just dumped the scratch buffer content to a file and fed them to the problematic detector.

The input data for the TDU was also saved to other files.

Regards,

Alexander Kochetkov

0647.cpttest.zip

0 Jean-Denis Boyer over 12 years ago in reply to Alexander Kochetkov

Prodigy 250 points

Hello Alexander.

Did you try with the latest release of VoLIB 2.1.0.1 issued last month?

I was informed, via another thread of discussion, that this bug should have been fixed.

The thread I'm referring to is http://e2e.ti.com/support/embedded/bios/f/355/t/258074.aspx

Regards,

Jean-Denis Boyer

0 lding over 12 years ago in reply to Jean-Denis Boyer

TI__Guru* 95265 points

Alexander,

The test project you attached shows C64x+ on VOLIB 2.1.0.1, I will investigate it and let you know.

Regards, Eric

0 Alexander Kochetkov over 12 years ago in reply to Jean-Denis Boyer

Prodigy 120 points

Hello Jean-Denis,

I see the problem with VoLIB 2.1.0.1, C64+. I'm not sure which thread my issue is more appropriate.

I posted the test in this thread to show how it is possible to simulate multiple TDU instances environment with a single TDU instance.

I have shown that the CPT detector reports depend on the data from volatile buffer. In my case the CPT loses tone reports, in your case it makes false reports. And if volatile (scratch) buffer is interpreted as dedicated (not shared) our problems are solved.

Yes, I can confirm, that the problem described in the another thread of discussion have been fixed.

I got inaccurate measurements of tone durations with VoLIB C64x+ 2.0.0.3 and sufficiently accurate tone durations with VoLIB 2.1.0.1 while I was working on busy tone detector. I also had multiple TDU instances environment.

Best regards,

Alexander Kochetkov.

0 lding over 12 years ago in reply to Alexander Kochetkov

TI__Guru* 95265 points

Alexander,

I didn't see the detection issue with my way of test:

1) C64x+, LE, ELF, VOLIB 2.1.0.1

2) Your test vector converted from linear to mu-law PCM

3) Use it as the first vector in the test case (before SIA detection)

sftBasicDetectionFILE(tduInst, tdu_CTL_CPT_ON, "cpttest_tx_mu.pcm");

4) Inside sftBasicDetectionFILE, add the frequency range:

if (control_code == tdu_CTL_CPT_ON)

{

tduSim.

cfgCtl.u.cpt.startFreq = 200;

tduSim.

cfgCtl.u.cpt.endFreq = 500;

}

tduControl (tduInst, control_code, &tduSim.cfgCtl);

5) Enable overwrite scratch buffer

tduSim_t

tduSim =

{

/* Simulation defaults */

TST_MAX_FRAME,

/* max # samples per frame */

40,

/* 40 samples default frame duration */

tdu_DET_ID_R1,

/* use DTMF as the default test */

0x55,

/* Scratch buffer overwrite pattern */

{

/* Boolean options */

TRUE,

/* Do not overwrite scratch by default */

I can see CPT is detected.

For you test method, there are several problems:

1) you used 0 for start and end CPT frequency

2) Linear input instead of mu-law

Attached is my modified code. Can you confirm this work for you?

Regards, Eric

6505.tdusim.c

0 Alexander Kochetkov over 12 years ago in reply to lding

Prodigy 120 points

lding,

Thank you for taking the time to look at the test.

I confirm, that modified test code work with first test vector converted from linear to mu-law PCM.

I have another test vector, what doesn't work with modified test code. See the file attached.

Last tone is detected 6 seconds later, with "Enable overwrite scratch buffer" option enabled.

Enable overwrite scratch buffer = TRUE

Tone: CPT : Event: ON, Time: 140 ms, Power: -16 dBm0, Frame: 5546
Tone: CPT : Event: OFF, Time: 0 ms, Power: -80 dBm0, Frame: 6302

Enable overwrite scratch buffer = FALSE

Tone: CPT : Event: ON, Time: 140 ms, Power: -16 dBm0, Frame: 4339
Tone: CPT : Event: OFF, Time: 0 ms, Power: -80 dBm0, Frame: 6303

2654.cpttest_tx_mu.pcm.zip

0 Alexander Kochetkov over 12 years ago in reply to Alexander Kochetkov

Prodigy 120 points

I want to add that the main purpose of my test case was to demonstrate a real bug in that CPT detector uses stale data in the scratch buffer. There may be workarounds for specific scenarios but I really hope Texas Instruments will fix the real cause of the problem.

0 lding over 12 years ago in reply to Alexander Kochetkov

TI__Guru* 95265 points

Yes, the test vector you provided shows the stale data in scratch buffer affects the CPT detector accuracy. I opened a ticket to track this issue and will update when it will be fixed.

Regards, Eric

Processors

Processors forum

TDU problem with multiple instances