i.mxrt117x: enable SAI1_RX_DATA1

[svoulaz_ik]

Hello,
I am wondering how to get data from SAI1_RX_DATA1 muxed on GPIO_DISP_B2_00 on i.mxrt117x (1176, specifically), since the pin is stuck driving a "0". I had a similar problem with rt1011 some time ago (see here), but the same fix does not apply to rt117x, since output driver cannot be disabled - drive strength field in SW_PAD_CTL_PAD_GPIO_DISP_B2_00 can be either "normal" or "high", no "disabled" as in rt1011. Also, I couldn't find so far any IOMUX/GPR register bit to configure pin "direction" to deal with this issue - and yes, TCE and RCE (in SAI1 registers TCR3 and RCR3 respectively) are set to 0b0011.

Any advice?

Best regards,
Stefano

Update: feeding SAI_RX_DATA1 with test data, I can confirm that the data is received BUT the line appears to be still driven '0' and the signal level barely reaches 2.5V (depending on the driver, however supposed to be 3.3V). In a configuration with multiple CPUs with SAI working in TDM mode, all the relevant pins will drive '0', so signal integrity would presumably worsen to the a non-working state.

Further update: looks like setting slew rate to "fast" for GPIO_DISP_B2_00 pad helps reducing the clamping - still, the signal is clamped at around 3V.

Additional thought: SAI has only one TWM (Transmit Word Mask). Does it mean that it affects ALL the transmit lines and that there is no possibility to specify per-tx-line transmit work mask?

[kerryzhou]

Hi @svoulaz_ik ,

   So, your GPIO_DISP_B2_00 for the SAI1_RX_DATA1 is working now, right?

   Just the voltage can't be 3.3V? 

   If yes, it should related to your hardware situation, you can check, whether the GPIO_DISP_B2_00 pin also connected to the other circuit, try to remove that and test it again.

   BTW, your other point which send the SAI data to the RT SAI1_RX_DATA1 signal should be strong enough.

GPIO_DISP_B2_00 to the SAI is the SAI1_TX_DATA3 and SAI1_RX_DATA1, and ALT4, no other select input like the RT1011.

  Do you try the SAI1_TX_DATA3 on the GPIO_DISP_B2_00, whether that can output the 3.3V, when you don't connect the external circuit, if yes, just RX can't upto 3.3V, I think it is related to your other component which output the sai signal to the RT SAI RX side.

Wish it helps you!

Best Regards,

Kerry

[svoulaz_ik]

Hi @kerryzhou,

GPIO_DISP_B2_00, used for SAI1_RX_DATA1, has no other connection. The source signal has no other connection and, when not connected, the signal swings to 3.3V as expected. As soon as I connect the source signal to GPIO_DISP_B2_00, the signal swings to less than 3.0V - but only if GPIO_DISP_B2_00 pad settings are "fast slew rate" and "normal drive strength" (otherwise, signal drops to 2.5V and below). To me, it looks like in rt1170 there is no way to disable the driver for GPIO_DISP_B2_00 (when it is used as input for SAI1_RX_DATA1) - as it is with rt1011. This may be an issue from signal integrity and EMI point of view, because of two drivers driving the same line. Also, things get worse when multiple rt1170 share the same line in a TDM configuration.

I still don't know how much this issue will affect our design (we are still in a prototyping stage and we need to connect three rt1170 in TDM configuration), but please check GPIO_DISP_B2_00 driver configuration with your engineers, we need to make sure there is no risk to damage the device. In any case, this is a candidate for a future silicon review.

Best regards,
Steano

[kerryzhou]

Hi @svoulaz_ik ,

    Thanks so much for your detailed information, and also thanks so much let the RT1170 as your project candidate.

    I have a question, do you also have th NXP MIMXRT1170-EVK board on your side or not?

    If yes, do you also test this board with the GPIO_DISP_B2_00 and connect your external SAI signal, whether still have this voltage issues? even DSE=1, high drive strength still have this issues?

   Or just your customer board have this issue?

   Please give me more information, if you have the NXP EVK test result, it will be more better, then I will assign time to test it on my side, and do more checking for you.

Best Regards,

Kerry

[svoulaz_ik]

Hi @kerryzhou,
I am actually running the tests on the MIMXRT1170-EVK board at the moment. I (heavily) modified the board to run our p.o.c., but I can provide you a sample project (attached) for testing. SAI1 is set up for TDM8 mode on two TX/RX lines - that is, TXD[0]/RXD[0] and TXD[1]/RXD[1]. Then the transfer is started and runs indefinitely, outputting short data bursts on TXD[0] and RXD[0]. By shorting TXD[1] (or TXD[0]) line to RXD[1], you can observe the degradation of the signal. For our specific application, SAI1 is set up with TX sync to RX, so you can monitor the following signals on J9:

• J9.1: SAI1_RX_BCLK
• J9.5: SAI1_RX_SYNC
• J9.7: SAI1_RXD[0]
• J9.9: SAI1_TXD[0]

I additionally routed SAI1_RXD[1] and SAI1_TXD[1] as follows, for ease of observation:

• GPIO_DISP_B2_02 as SAI1_TXD[1] (out)
  On EVK: ENET_TXD0 / TRACE_D0 / BT_CFG[8] - no conflict (ENET_TXD0 is an input of U7) Remove R1919, route R1919.2 to R334.2 to have it on J9.13

• GPIO_DISP_B2_00 as SAI1_RXD[1] (in)
  On EVK: BT_CFG[6] - no conflict Remove R1920, route R1920.2 to R340.2 to have it on J9.11

With this setup and using the sample project, when I short TXD[0] or TXD[1] to RXD[1], I can successfully acquire the data in the receive buffer, but I observe a severe degradation of the signal. The following scope shots are taken on TXD[1].

This is the signal on TXD[1] with the pin floating - full swing, no degradation:

This is the signal on TXD[1] when shorted to RXD[1] with default pad settings (as in the project):

Setting "normal drive strength" for GPIO_DISP_B2_00 pad (receiver):

Setting "fast slew rate" for GPIO_DISP_B2_00 pad (on top of "normal drive strength"):

With the latest settings we are almost there, it looks like on rt117x it is not actually possible to completely disable the driver on any I/O pin - including GPIO_DISP_B2_00, when used as SAI1_RXD[1]. Hence, I still have some concerns:

• Signal integrity and EMI effects: we need to connect multiple devices on the same bus, so there will be more than one rt117x receiving on SAI1_RXD[1] (GPIO_DISP_B2_00). This means having several "stuck at zero" drivers in parallel. Not sure, but a buffer might be required to guarantee signal integrity, with further side effects on radiation.
• Potential electrical issues at driver's level. For this, we require a written statement from NXP engineers that guarantees that there is no electrical issue (i.e., silicon damage) when connecting GPIO_DISP_B2_00 as SAI1_RXD[1] to a low impedance signal source (i.e., a transmitter, maybe buffered), when configured for normal drive strength and fast slew rate.

Thank you for your support.
Best regards,
Stefano

[kerryzhou]

Hi @svoulaz_ik ，

   So sorry for my later reply, because of a lot customer's cases in the testing queue.

   Today, I find time to test your project, but I find the GPIO_DISP_B2_02 always no output in your project.

Then I debug it, I find it meets the __assertion_failed issues, like this:

Do you also test the attached project, have this assert issue or not?

BTW, why you need to remove R1919? As it is not related to your used :

GPIO_DISP_B2_02 as SAI1_TXD[1] (out)

and 

GPIO_DISP_B2_00 as SAI1_RXD[1] (in)

do you just want J9_13 as a connection point?

Best Regards,

kerry

[svoulaz_ik]

Hello @kerryzhou,

I ran several test using that same project, using release configuration. The assertion you are observing (in debug configuration, I assume) is possibly due to a bug in the fsl driver for sai edma (as pointed out here and here). Please use release configuration.

As per removal of R1919, I confirm it is not strictly required as long as GPIO_DISP_B2_02 is not connected to J9.13 - which I actually used as a connection point to interface another board (when needed).

Best regards,
Stefano

[kerryzhou · Accepted solution]

Hi @svoulaz_ik ,

   Your linker let me recall some old experience that SAI which use the RX_D[1] meet the voltage can't up to high level.

  Please check this, then set the CHMOD=0 and try it again, whether it has improvement or not:

Any updated information, please kindly let me know.

Best Regards,

Kerry

[svoulaz_ik]

Hello @kerryzhou,

WHOA, that made the trick! Thank you for you support, it would have taken some time to find that out - good to know that specific bit makes the difference.

Best regards,
Stefano

[kerryzhou]

Hi @svoulaz_ik ,

  Thanks so much for your detail information.

   I will try to test it on my side!

  Please let me know your use MIMXRT1170EVK board version, I mean, the SCH--x  rev c?

Best Regards,

kerry

[svoulaz_ik]

Hello @kerryzhou,
the EVK is 700-32171 REV A, SCH-32171 REV C2

Best regards,
Stefano

[kerryzhou]

Hi @svoulaz_ik 

  Thanks so much for detailed information.

   I already got it.

  Please give me more time, I will do the testing on my side at first, than give you feedback later.

  Please keep patient, thanks a lot for your understanding.

  Any updated information from my side, I will let you know, thanks.

Best Regards,

Kerry