How to connect external 3.3V I/F I2S signal to nrf5340-audio-dk

Hello,
devzone.nordicsemi.com/.../set-nrf5340-audio-dk-as-i2s-slave-over-external-bus
Based on this post, I changed I2S to SLAVE setting.
The external I2S I/F level is 3.3V.
When OB/EXT is green, it is noisy when I2S of 3.3V I/F is connected to P5, but we have confirmed that the audio signal is sent to the RX side and the sound is heard.


devzone.nordicsemi.com/.../access-to-i2s-interface-on-nrf5340-audio-dk

Based on this post, I tried changing the I2S port.
If OB/EXT lights up orange, does that mean the port has been changed to P10 instead of P5?

But when OB/EXT is orange, there is no sound even if you forcefully connect the 3.3V I/F to P10.

Also, in order to change the 3.3V I/F to 1.8V I/F, I changed the I2S signal level using TI's TXS0108E.
When I connect the nrF5340 to the enabled I2S port (P5 or P10), I checked with an oscilloscope and found that there is quite a lot of noise on the I2S signal.
Since it is a bidirectional buffer, it seems that the noise component is flowing backwards, or the GND level is not stable and crosstalk noise is being buffered.

Is there a way to run nrF5340-audio-DK with 3.3V I/F?
Or is there a good way to make I2S a 1.8V I/F?

Parents
  • Hello,

    When connected to P5, I found that the output of CIRRUS's CODEC collided with the external 3.3V I/F, causing the audio to be heard mixed with noise.
    With the P5 connection, even if the level shift is correct, noise (output from CIRRUS) will be mixed in the I2S DATA line and no sound will be produced.

    Also, I have connected the P10 to the 1.8V I/F I2S with a software setting that turns OB/EXT orange, but there is no sound.
    Could you please give me detailed steps to use external hardware codec?

  • Hello,

    Just to aid my understanding so that I may best advice you, is your overall goal to interface the nRF5340 Audio DK with an external hardware codec that outputs I2S at 3.3V?

    MontBlanc said:
    Could you please give me detailed steps to use external hardware codec?

    Please follow these steps to work with an external hardware codec:



    Best regards,
    Karl

  • Hello,

    MontBlanc said:
    I wrote this because I was not confident in changing the source code and thought there might be something missing.
    Does that mean that there are no mistakes in the changes made to the source code?

    No worries - this is very helpful for me to know! :) 
    I am not quite sure about the last change you mention - changing all returns in hw_codec_init to 0 since you are not calling the function anymore - but other than that it looks alright to me.

    MontBlanc said:
    Modify the TX side and build and Flash the B source code only on the TX side. →Sound comes out on the RX side.
    Modify the TX side, build and Flash the C source code on the TX side. →There is no sound on the RX side because it is unclear whether the source code has been corrected.
    Modify the TX side, build and Flash the source code of A to the TX side. →No sound on the RX side (cause unknown)
    Build and Flash the source code of A for TX and RX at the same time. →Sound comes out on the RX side.

    The default behavior of the nRF5340 LE Audio reference application in the headset configuration is to bond with the connected device, and only look for these devices again when it connects the next time. When you reprogram the gateway it will loose its bond information, and so when it attempts to connect to the headset device it will fail the key exchange which will cause the headset to terminate the connection.

    You should see this sequence in the logs from either of the devices.
    The easiest fix to this is to either make sure that both devices are flashed when you reprogram one of them, or to modify the application to not use bonding and to accept connections from any gateway device.

    Best regards,
    Karl

  • Hello,

    Based on the comments I received, I branched with an if statement, built and flashed at the same time, and was able to send and receive beautiful sound between external I2S.
    thank you very much.
    At that time, I found out that P5 and P10 can be connected either way, and that the DIN-DOUT is reversed for P5 and P10.

    Now, as a next step, I want to send stereo.
    The I2S of nrf5340 on the RX side currently only outputs Lch.
    Could you please tell me where to modify the source code for stereo transmission?
    I'm using v2.4.2.
    I tried to refer to the post below, but the version is too old and the corrections are different.

    devzone.nordicsemi.com/.../387700


    I also tried to include the same fix for external I2S in this version, but unfortunately the I2S DATA on the RX side had periodic pulses and was full of noise.
    Therefore, could you please tell me what has been fixed in the new version?

    Best regards,

  • Hello,

    MontBlanc said:
    Based on the comments I received, I branched with an if statement, built and flashed at the same time, and was able to send and receive beautiful sound between external I2S.
    thank you very much.

    No problem at all - I am glad to hear that the issue was resolved! :) 

    MontBlanc said:
    Now, as a next step, I want to send stereo.
    The I2S of nrf5340 on the RX side currently only outputs Lch.
    Could you please tell me where to modify the source code for stereo transmission?
    I'm using v2.4.2.
    I tried to refer to the post below, but the version is too old and the corrections are different.

    Let me take a look at what changes are necessary here and get back to you. My initial guess would be that this primarily would require some changes to the I2S initialization in the audio_datapath.

    MontBlanc said:
    I also tried to include the same fix for external I2S in this version, but unfortunately the I2S DATA on the RX side had periodic pulses and was full of noise.
    Therefore, could you please tell me what has been fixed in the new version?

    Do I understand you correctly that you upgraded the version to nRF Connect SDK v2.4.2, which broke the external codec/I2S functionality?
    If so, could you clarify which nRF Connect SDK version you were working on prior to the upgrade, and whether or not you upgraded your application, or 'remade' it entirely in the v2.4.2?

    Best regards,
    Karl

  • Hello,

    Modifying the source code to use external I2S in v2.4.2 worked fine.
    I modified the source code to use external I2S in v2.2.0 using the same procedure, but noise is always output to I2S DATA. (At this time, I have not yet modified the source code to make it stereo.)

    I want to send and receive external I2S in stereo with v2.4.2.
    The link you received is the source code of audio_datapath.c, but are there any other parts that need to be modified?

    Best Regards.

  • Hello,

    Thank you for your extreme patience with this.

    MontBlanc said:
    Modifying the source code to use external I2S in v2.4.2 worked fine.
    I modified the source code to use external I2S in v2.2.0 using the same procedure, but noise is always output to I2S DATA. (At this time, I have not yet modified the source code to make it stereo.)

    I want to send and receive external I2S in stereo with v2.4.2.

    I understand this to mean that it is working to sending and receiving external I2S stereo audio in v2.4.2, is this correct?
    If not, could you elaborate and clarify on the issues you are currently facing with this approach using v2.4.2?

    Is there any reason why you would like to use the nRF Connect SDK v2.2.0 instead of v2.4.2? Many new features and improvements have been added in between these releases, and now the v2.5.0 is also out - I would recommend upgrading to, and using, the latest nRF Connect SDK version whenever possible.

    Best regards,
    Karl

Reply
  • Hello,

    Thank you for your extreme patience with this.

    MontBlanc said:
    Modifying the source code to use external I2S in v2.4.2 worked fine.
    I modified the source code to use external I2S in v2.2.0 using the same procedure, but noise is always output to I2S DATA. (At this time, I have not yet modified the source code to make it stereo.)

    I want to send and receive external I2S in stereo with v2.4.2.

    I understand this to mean that it is working to sending and receiving external I2S stereo audio in v2.4.2, is this correct?
    If not, could you elaborate and clarify on the issues you are currently facing with this approach using v2.4.2?

    Is there any reason why you would like to use the nRF Connect SDK v2.2.0 instead of v2.4.2? Many new features and improvements have been added in between these releases, and now the v2.5.0 is also out - I would recommend upgrading to, and using, the latest nRF Connect SDK version whenever possible.

    Best regards,
    Karl

Children
  • Hello,
    The latest version when I started working on it was v2.4.2. Since the current latest version is v2.5.0, I will make the same modifications here and try external I2S connection. Please check the modifications to the stereo conversion source code in v2.5.0.

    Best Regards.

  • Hello, Karl.

    Thank you for answering.

    Confirmed that the sound is played correctly in external I2S SLAVE mode with v2.4.0,
    After that, I implemented all the changes you suggested.

    The result is an interrupted mechanical sound that is linked to the played sound.
    When there is no sound, there is no sound.
    It seems that I2S transmission and reception are not being performed correctly.

    If only prj.conf is restored to the original external I2S settings, the audio will be played in monaural with the correct sound.

    Therefore, we assume that there is a problem somewhere in the processing branched at HEADSET.
    Don't you know what the reason is?

    Best Regards.

  • Hello,

    MontBlanc said:
    Thank you for answering.

    No problem at all, I am happy to help! :)

    MontBlanc said:
    Confirmed that the sound is played correctly in external I2S SLAVE mode with v2.4.0,
    After that, I implemented all the changes you suggested.

    Does this mean that you verified the audio going into the nRF5340 (i.e verified that your external codec provided the correct audio to the nRF), or does it mean that you were able to hear the stereo audio correctly through the LE Audio link when you used the referenced branch as provided, prior to any changes?

    MontBlanc said:
    The result is an interrupted mechanical sound that is linked to the played sound.

    If there are glitches on top of the received audio then there is a chance that something has gone wrong in the handling of the received audio frames.
    Could you elaborate further on the question above, so that I better can understand the issue you're seeing?

    Best regards,
    Karl

  • Hello,
    The environment I tried is as follows.

    Environment of external CODEC without using nrf5340
    External HOST(I2S SLAVE) - I2S(L/R) - External DAC(I2S MASTER) - L/R ch audio is output from L/R ch

    Customized nrf5340 software for external CODEC
    External HOST(I2S SLAVE) - I2S(L/R) - nrf5340-audio-dk TX - nrf5340-audio-dk RX(Left) - I2S(Lch) - External DAC(I2S MASTER) - Lch audio is output from Lch
    |
    - nrf5340-audio-dk RX(Right) - I2S(Rch audio is Lch packet) - External DAC(I2S MASTER) - Rch audio is output from Lch

    Environment where I tried to send/receive L/Rch this time
    External HOST(I2S SLAVE) - I2S(L/R) - nrf5340-audio-dk TX - nrf5340-audio-dk RX - I2S(L/R ch packet is incorrect) - External DAC(I2S MASTER) - L/R ch audio is output from L/R ch, However, the sound is mechanical

    Best Regards.

Related