The MCLK pin for I2S is being incorrectly mapped to the BCLK pin for some reason.

[cory123]

I'm implementing the SGTL5000 driver found on the github Nordic playground with the NRF52832. My custom board connects the NRF chip to SGTL5000. I've changed the drv_sgtl5000.h to match my boards layout:

/* I2S pin mapping */
#define DRV_SGTL5000_I2S_PIN_MCLK       21  /* 23 for nRF52832 DK, 1,13 for 52840 */
#define DRV_SGTL5000_I2S_PIN_BCLK       19   /* 20 for nRF52832 DK, 1,11 for 52840 */
#define DRV_SGTL5000_I2S_PIN_LRCLK      20  /* 22 for nRF52832 DK, 1,12 for 52840 */
#define DRV_SGTL5000_I2S_PIN_RX         18  /* 25 for nRF52832 DK, 1,15 for 52840 */
#define DRV_SGTL5000_I2S_PIN_TX         17  /* 24 for nRF52832 DK, 1,14 for 52840 */

I used the nReset pin for MCLK pin for no specific reason. When the driver tries to communicate via I2C with the SGTL it gets no ACK of address. After closer inspection, I've found that the MCLK pin is not getting clocked which is necessary for I2C to work. I measured the MCLK pin 21 with my multi-meter, and got 0 Hz. When measuring the frequency of the BCLK pin 19 I see 4 Mhz. It looks like MCLK is outputing on the BCLK pin for some reason. I've traced the pin configurating in the the sgtl driver code. The MCLK pin is definitely set to 21 all the way through to the I2S registers.

This issue may be related to https://devzone.nordicsemi.com/f/nordic-q-a/24609/i2s-with-reset-pin

Any advice on this issue would be greatly appreciated!

[cory123]

I just tried your advice. When I assign MCLK to another pin, MCLK is output as expected.

When I configure P21 as output (see below) and set it high I get 3.3 V as expected, but when I set it low I still get 3.3 V. Is there some internal pull-up that is preventing the output going low?

 nrf_gpio_cfg_output(21);
 nrf_gpio_pin_clear(21);

[Stian Røed Hafskjold]

Can you try running,

nrfjprog --memrd 0x50000700 --n 0x80

and post the result here. It should reveal any incorrect GPIO settings. Thanks.

Are you running this on a DK? If so, the reset pin is routed to the onboard debugger chip. Cut SB27 to cut the trace to the debugger chip, and it should only be routed out to the header.

If you are using a custom board, are you sure that nothing else is connected to the pin externally? Do you have more than one board to test on?

[cory123]

I ran that nrfjprog command after starting I2S and I2C drivers and break pointing. Here's what I got. Can you tell me what the format of this data is?

0x50000700: 00000002 00000002 00000002 00000002   |................|
0x50000710: 00000002 00000002 00000000 00000003   |................|
0x50000720: 00000002 00000002 00000002 00000002   |................|
0x50000730: 00000002 00000002 00000002 00000600   |................|
0x50000740: 00000600 00000003 00000000 00000003   |................|
0x50000750: 00000003 00000003 00000002 00000002   |................|
0x50000760: 00000002 00000002 00000002 00000002   |................|
0x50000770: 00000002 00000002 00000002 00000002   |................|

I am using a custom board. Nothing else is connected to the trace connecting NRF52 to SGTL5000. I tested conductivity between P21 and VDD to make sure there is no short. I found no conductivity. Hmm.

[Stian Røed Hafskjold]

Thanks.

The format of the data is described here: https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/gpio.html?cp=4_2_0_19_2_9#register.PIN_CNF-0

The first 0x00000002 word corresponds to PIN_CNF[0], then it goes all the way up to PIN_CNF[31]. So pin 21 is set to 0x3, which is the normal output setting. No pullups are configured.

What happens if you force the P21 to GND, does the chip reset? Can you try forcing the pin to GND though an ampere meter. If the current flowing is about 200 uA, then the pin is kept high by a pullup, and that would suggest that pin reset is still active for some reason (you would also get a reset). If you see current in the 4-5 mA range, the pin is set to high through the GPIO register, and pin reset is not activated.

Could you also please post a hex file. Then I can see if I can reproduce it.

Do you see this on a DK as well, or just your custom board?