Asking to correct a bug in the McASPEcho_dspL138 project (quickStartOMAPL1x_rCSL)

Hi GenPol,

Thanks for your post.

Kindly clarify the below details:

1. In which TI board, you actually observe this  bug (OMAPL138 EVM /Experimenter Kit (Zoom), give us the details? (Logic PD or Spectrum digital board)

2. Are you using any custom board using TI device (OMAPL13x)

3. Could you please give us the bug description & elloborate your bug details on the test conditions? On what conditons, did you test the rCSL examples? Please refer the below wiki and provide the details on the test conditions? (CCS version, CGT version, OMAPL1x silicon revision, EVM board model no. etc)

http://processors.wiki.ti.com/index.php/QuickStartOMAPL1x_rCSL?sp_rid_pod1=MjE0MjEyMDc0MDMS1&sp_mid_pod1=3462765#Troubleshooting.2FFeedback

4. Which version of QuickStartOMAPL1x rCSL package are you using? (ver. 2.0 or ver 1.0 legacy)?

5. Is this issue reproducible? Is it happening consistently?

6. Which version of BIOS PSP release are you using?

6. Do you see any inband noise in the output signal as similar to the below E2E thread? Just to confirm?

http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/187030.aspx

Suggestion:

1. Please try resetting the device once by performing system reset or powercycle and later, kindly check whether the issue happens repeatedly?

2. Please also see the list which is referred in the below wiki for the suggested minumum requirements for running OMAPL1x rCSL examples.

http://processors.wiki.ti.com/index.php/QuickStartOMAPL1x_rCSL?sp_rid_pod1=MjE0MjEyMDc0MDMS1&sp_mid_pod1=3462765#Troubleshooting.2FFeedback

Thanks & regards,

Sivaraj K

Hi Sivaraj K,

thanks for feedback. I need some time to collect the needed info, so I’ll be ready to answer next workweek.

Kindly
GenPol

Hi Sivaraj K,

To your questions:

1. Logic PD Zoom OMAP-L138 EVM

2. No

3. CCS v5.4.00091, CGT v6.1.9 & 7.4.4, chip silicon revision 2.0, EVM board REV B

4. Ver. 2.0

5. Consistently

6. BIOS PSP 01.30.01

7. Yes

To your suggestions:

1. The board was ever powercycled before program load, but the issue still happens repeatedly.

2. Minimum requirements are filled.

Judging by your questions, I believe you have participated on the QuickStartOMAPL1x rCSL development.

I’ve also attached for you three screenshots (see 284560_Issue.pdf) to demonstrate the bug. You can see the left and right input signals (sine burst) on the first image, the second image presents the output of the same signals delayed and inverted by the codec, and the third one demonstrates the issue.

As you can see on the third image, the signal amplitude is reduced indeed, but every positive half wave jumps down. Taking in account the signal inversion by the codec, I explain this phenomenon as a lost of negative polarity bit, namely the MSB.

I can advise you at least on a one incorrect McASP setting, namely the same polarity of CLKX and CLKR signals in the mcasp.c. It can be used having different CLKX and CLKR signals, but in our case it will provoke the race condition and contradicts with the SPRUFM1 (see Table 25 and Table 37).

Kindly
GenPol

Hi Sivaraj K,

FYA: I’ve added the eye-diagrams of the codec DIN and DOUT data lines from the original project.
Kindly asking, why the data are sampled on different ages?

Still waiting for your comments.

GenPol

Hi GenPol,

Let me discuss this with our team and will let you know the update as soon as possible.

Thanks & regards,

Sivaraj K

Hi GenPol

The quickstartrcsl was developed as an as-is example suite to help jump start variety of users on OMAPL13x/C674x device family. These examples are intended to serve as rCSL based examples for users who did not want to develop with BIOS or Linux (OS based) drivers offered by TI.

Unfortunately there is no planned updates for this software package. I see that in your post you mention that you had a similar feedback on the BIOS drivers and it was fixed. Does that not help address your issue?

In general quickStartrCSL was highly relevant when we did not have Starterware for these devices. Once we offered Starterware for the devices, really that is production worthy, relatively more actively maintained software release for customers looking for non-OS software packages on these devices.

I see you are active on another Starterware McASP thread, can you please post the most relevant information on that thread on whether in using Starterware you are facing similar issues?

Regards

Mukul

Mukul,

Sivaraj K had asked for some time to provide an update ASAP, but you try to disavow his statement. Are you authorized from him for this action or you are simply a defender of corporative interests?

GenPol

Hi GenPol

General Polar said:

Are you authorized from him for this action or you are simply a defender of corporative interests?

A bit of both I guess. I manage part of the teams that support this device family and also have additional history on quickStartRCSL and its intent that was before Sivaraj's time at TI.
I apolgize if the line of questioning from Sivaraj, mislead you to the fact that we would be able to fix reported issues on the quickStartRCSL package. As a corrective action, I will put some additional disclaimers on the wiki download page, to inform that this package is "as-is".

Regards

Mukul

Hi Mukul,

thanks for the more informative answer. Going back to the theme, I have found bugs (not one) and fixed the issue. Taking into account, how much time was invested into ineffective discussions, I would prefer to contact not an e2e Guru etc. but any digital audio engineer, having elementary knowledge of the I2S protocol.

But I’m really wondering about your distanced attitude, based on your “as-is” interpretation. If the project was developed for the “jump start” purposes, what can be learned from a false interpretation of the I2S protocol (see mcasp.c, lines 154-156)? Being in your position, I would be proud to fix the issue ASAP and to not force my customers to struggle with the code, developed from me.

What I would also friendly proposed for your next “as-is” projects is to open a free bug list, after having the first bug report, thereby giving the customers and community members a chance to participate and contribute on the project. Since the best strategy to learn something is a work on errors. You can do it also for this project, together with the Wiki disclaimer.

Regards
GenPol

Hi GenPol

Thanks for the feedback. In coming months, we will be able to share more details on upcoming software projects that are likely to have the ability for community participation and will be on the git etc (DSP side offerings).

If you have any outstanding questions on the I2S topic, please start another thread and I will route it to the right experts. Don't give up on the e2e gurus just yet, they are an elite bunch with a diverse experience and experts in their fields and several other domains.

Regards

Mukul