PTB18 strange behaviour

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

PTB18 strange behaviour

1,397 Views
Kubiznak
Contributor II

Hi,

when debugging SAI audio on Vybrid (PVF61GS151CMK50 1N02G), we encountered problem with PTB18 behaviour. When IOMUXC_PTB18 MUX set to 0x02 (master clock), it does not output clock.

In GPIO mode (MUX 0x00) does not work properly in CMOS mode (ODE 0), works only as open-drain (ODE 1).

Tested on two MCUs with the same result.

Is this a known issue? Is there any workaround to make audio working on TWR?

0 Kudos
4 Replies

1,153 Views
anthony_huereca
NXP Employee
NXP Employee

Hi,

  This is not a known issue. The EXT_AUDIO_MCLK is an input, not an output. You can see the clock tree in Section 9.10.10 of the latest RM "ESAI clocking"


  I also tried out PTB18 as GPIO on the Vybrid tower board (primary elevator A35) and could use it successfully in CMOS mode. I used the following code:

  IOMUXC->SINGLE.PTB18 = IOMUXC_PTB18_DSE(0x1)| IOMUXC_PTB18_OBE_MASK; //enable GPIO output for PTB18

  GPIO1->PTOR|=PIN(8);

-Anthony

1,153 Views
billpringlemeir
Contributor V

I just want to point out/clarify, EXT_AUDIO_MCLK is an input to the SAI/ESAI modules, but it can be an output for the Vybrid chip; at least that is my belief.  You can program the CCM to set the value of the EXT_AUDIO_MCLK and use the same clock to route to the codec master clock.  So the CCM generates (outputs) EXT_AUDIO_MCLK  and both the SAI/ESAI and the codec can use EXT_AUDIO_MCLK
as an input.

0 Kudos

1,153 Views
Kubiznak
Contributor II

Hi Anthony,

thank you for your reply. Regarding GPIO you are right, it was our stupid mistake (incorrect understanding of DSE register). It works correctly.

Anyway we still have the problem with audio. On Kinetis K70, EXT_AUDIO_MCLK was configurable to be either input or output, which made perfectly sense. We expected that to be the same on Vybrid and designed a module SQM4-VF6 (http://www.sqm4.com/sqm4-vf6-vybrid-module) where we used PTB11 as SCI0_RX, which excludes its use as a clock source (as it is used on TWR).

Besides the fact we would not like to redesign the module, I primarily do not believe this is the only way to use SAI. Can you please suggest another way of clocking SAI without the need of externally connecting two pins of the processor? We use SGTL5000.


In MQX, I'm not sure SAI is properly configured for TWR as well, as no function from sai_int_ksai.c nor _bsp_sai_io_init() from init_gpio.c is called during MQX initialization (used twrvf65gs10_a5 BSP of MQX 4.0.1). In Linux, ALSA prints during boot there are no audio devices found.

0 Kudos

1,153 Views
anthony_huereca
NXP Employee
NXP Employee

Hi,

  MQX doesn't support SAI yet in 4.0.1, it'll be added in the next release, and that is why it's not called during MQX initialization. In Linux, it is likely detecting the TWR-AUDIO card and if it does not see it, then prints out the not found message. I'm not certain on that last point though.

  As for your questions about how to use the SAI, that is being looked at. Can you provide how you're currently connecting the SAI pins currently to the SGTL5000?

0 Kudos