Cannot build I2S echo application for NRF5340

[TomHe]

Hi, I am a beginner into the embedded audio space, and happened upon this board to use for our university project. Our team's current plan would be to produce audio directly on the board and play it through the headphone jack, but have not found much success with the NRF5340 Audio application, as it has a lot of integration with Bluetooth (which we don't need for now). Right now we just need a simple application that plays a tune on the board.

In my search I have found the I2S echo application, which seems like a simple start for our use case. However, when trying to build the application we encountered the following error:

-- Found BOARD.dts: C:/ncs/v2.6.2/zephyr/boards/arm/nrf5340_audio_dk_nrf5340/nrf5340_audio_dk_nrf5340_cpuapp.dts
-- Found devicetree overlay: boards/nrf5340dk_nrf5340_cpuapp.overlay
devicetree error: pinctrl-names property in /soc/peripheral@50000000/i2s@28000 in C:/ncs/v2.6.2/zephyr/misc/empty_file.c has 1 strings, expected 2 strings

This is our build configuration (all other options left as default):

SDK version:

Any help would be appreciated! Thanks!

[Alexander Svensen]

Hi ace.johnny  and TomHe , I'm one of the developers of the audio application and I'm sorry to see that this is causing issues for you. This is a very big application that encompasses a lot of moving parts and some of these were written a long time ago. 

To get a working I2S sample I would recommend taking our audio_i2s.c and header file together with the callback function here: i2s_block_complete_cb At the top of the I2S file you can see the ratios we use to get the different sample rates. The actual MCK frequency when using our driver is 6.144MHz, so that is why the ratio is half of what you would have used if the MCK was 12.288MHz.

Looking at you code Johnny I spotted a bug in our code where we have mixed up 39845.888 (0x9BA6) with 39854 (0x9BAE) causing us to set the wrong value for the HFClock so thank you for that and sorry if that caused any confusion. It shouldn't cause much of an issue as this results in the LRClock running  1 Hz faster than expected to begin with but that would be corrected by drift compensation later on. I have opened a PR for fixing it though.

In this function you can remove everything except the `audio_i2s_set_next_buf(tx_buf, rx_buf);` this is where the buffers for the next frame is set. How you provide those buffers are up to you and depends on where you are sourcing your data from. To get something up and running quickly you could use the `alt_buffer_get()` function to provide empty buffers to start with.

To explain quickly how the I2S driver works:

• It can be initialized at boot up using the `audio_i2s_init()` function
• Once ready to start sending audio, call `audio_i2s_start()` providing the first tx-buffer to transmit and a rx-buffer to contain data fetched, these two are the same size.
• Once the data has been sent to the I2S-module it will call the callback, that can be registered using `audio_i2s_blk_comp_cb_register()`, to ask for a new tx and rx-buffer and this goes in a loop until `audio_i2s_stop()` is called. The interval of how often the callback is called depends on the size of the buffers provided.

Hope this helped a bit.

EDIT: This response is written just with the I2S in mind, not changing any settings on the CS47L63. THat can be done by adding a line in the spi-writing, setting CS47L63_SAMPLE_RATE1 to 0x12