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.

Error: TSC mode read failed, problem with codec

Other Parts Discussed in Thread: OMAP-L138, TPS65070, SYSBIOS

Hello,

I am experimenting with the omap-l138, and I would like to run an audio application from the screen.

As a first step, I try to launch the biospsp audio example provided with SDK and, in the same time, the matrix-gui-e is on but I get some troubles. Twice are working well separately, however when I run them together I get the error message "tps6507x 1-0048: TSC mode read failed".

It seems that this issue comes when initializing the codec aic3106. But I am not sure what causes the problem, could it be a bad i2c initialization issue? Would it due to a competitive use of i2c bus?

Thanks in advance

 

 

  • Try probing the I2C bus and seeing if there is any traffic when the Matrix gui is running by itself. Then start your audio application and check if the I2C pins are toggling as expeted to configure the codec.

    Jeff

  • Thank you for the reply.

    I probed the I2C bus, and the Matrix GUI keep using this bus once started. When I start the audio example, there is no more activity on the bus and the error message is printed infinitely in the terminal. So the problem come actually from this bus, how can it be fixed?

    Edit: It seems that the SPI bus is used by the matrix GUI too.

  • Bruno Grentzinger said:
    As a first step, I try to launch the biospsp audio example provided with SDK and, in the same time, the matrix-gui-e is on but I get some troubles. Twice are working well separately

     

    - This is not surprising. All the stand alone examples (BSL, CSL) assume that a single CPU accesses a given peripheral.

    - For I2C a given procedure need to be followed. If one CPU access the I2C before the other CPU has finished it's transaction than it might confuse the I2C state machine.

    - Specifically about OMAP-L138 EVM the I2C0 is used to connect to the TPS65070 that has an on-chip touchscreen interface as well to the Audio CODEC. I am not sure how the touch screen is managed but it might be that I2C is used in polled mode to is screen is touched. You would need to check how the touch screen is being implemented.

     

    Bruno Grentzinger said:
    Would it due to a competitive use of i2c bus?

    It is very likely. I would see at least 2 options:
    1) Use a synchronization mecanism in order to share the I2C between the ARM and the DSP.
    a) If no OS is used then you can look at:
    \rCSL_examples\evmOMAPL138\ARM_examples\syscfg\ARM2DSP_integration_armL138 example that gives an example of IPC mecanisn.

    b) With BIOS5 (ie DSP BIOS) on the DSP side an no OS on the ARM you can look at:
    http://processors.wiki.ti.com/index.php/Audio_Soc_example

    c) With BIOS6 (ie SYSBIOS) on the DSP and Linux on the ARM side you can look at the following forum post:
    http://e2e.ti.com/support/embedded/f/355/p/97409/340681.aspx#340681


    Unfortunately we do not have example or reference for your particular case (Linux on ARM and no OS on the DSP).


     2) Have the ARM do the Audio CODEC init via I2C and just have the DSP to deal with the data sent/received to/from Audio CODEC via McASP I2S.
     

    If the issue is in the way touch screen is implemented/handled then you might have to change some codes.

     

    Hope it helps.

    Anthony

  • Thank you for the reply,

    I wrote my own function to init/close codec from ARM, and it actually work.

    However I'd like to make it works from DSP so I will check a) or c) example. Thank you for the links.

     

    Bruno