RE: I2S change from writing in Register to driver

wpaul — Mon, 02 Dec 2019 22:39:33 GMT

[quote userid="73427" url="~/f/nordic-q-a/55029/i2s-change-from-writing-in-register-to-driver/223149"]Have you tried the i2s example in the SDK?[/quote]

I must point out that the I2S example in the SDK is of limited use for someone designing or troubleshooting a real world application. The problem is that you need an external codec chip in order to actually hear the output of the I2S module, and the Nordic NRF52 dev boards don't include one. Because of this, the SDK example can't do much except loop samples back between the TX and RX paths. This is not how most people are going to to use I2S.

The one major difference between the "direct access to registers" and "driver" approach used here is that the former relies on polling the EVENTS_TXPTRUPD register while the latter relies on the interrupt that's supposedly generated when the EVENTS_TXPTRUPD register changes state.

I say "supposedly" because in my own attempts to use the I2S module, it didn't seem to work that way. My expectation was that an interrupt event would be generated immediately once the I2S controller finished transferring the number of words specified in the RXTXD_MAXCNT register. I assumed that this would allow me to accurately detect when the current batch of samples had finished playing However that's not what appeared to actually happen. The contents of the EVENTS_TXPTRUPD did indeed seem to change at this point, such that polling this register produced the correct result, but the interrupt event seemed to occur at the wrong time. From what I could tell, it was triggering too early, with the result being that the output sounded garbled.

I worked around this by using the PPI module. I tied the EVENTS_TXPTRUPD register to a PPI channel and then tied that channel to a software generated interrupt, and then set things up so that the following would happen:

- samples are queued up to play

- the I2S EVENTS_TXPTRUPD interrupt occurs

- the I2S interrupt handler acks the EVENTS_TXPTRUPD event and then enables the PPI channel

- once the EVENTS_TXPTRUPD register actually changes state, the PPI channel triggers the software interrupt

- the software interrupt is now triggered once the samples are actually done playing

Below is a link to my driver code:

https://github.com/netik/dc27_badge/blob/master/software/firmware/badge/nrf52i2s_lld.c

https://github.com/netik/dc27_badge/blob/master/software/firmware/badge/nrf52i2s_lld.h

I don't know if I was doing something wrong elsewhere that caused this condition to occur, but I experimented for quite some time trying to figure it out and in the end (like the poster above), I wasn't able to find where I was doing anything wrong. The manual seemed to strongly imply that the I2S module would generate an interrupt as soon as the current batch of samples was finished transferring, but that did not seem to be the case, and I nothing I did seemed to change that. My PPI workaround was good enough for my needs so I never followed up on it further. Also, since the Nordic DK boards do not have an audio codec chip on them, I wasn't sure that asking Nordic for help would do any good since there would be no easy way for them to reproduce my environment for testing. Otherwise, I would have asked:

- How can one be sure exactly when the I2S interrupt fires? Is it supposed to trigger right when EVENTS_TXPTRUPD changes state or not? If not, when? If yes, have you guys actually tested it with a codec attached, and do you have an actual known good working example for playing audio samples that behaves correctly?

Note that I used the ChibiOS RTOS in my application and did not use the Nordic SDK, however I don't think this had anything to do with the problem. The codec we used was a CS4344.

-Bill

RE: I2S change from writing in Register to driver

Marjeris Romero — Mon, 02 Dec 2019 17:14:26 GMT

[quote user=""]Its like the handler is too slow.[/quote]

How are you measuring this?

Are you running other things than I2S in your application?

Which SDK version are you using?

What is NRFX_I2S_CONFIG_IRQ_PRIORITY set to in sdk_config.h?

Have you tried the i2s example in the SDK?

Best regards,

Marjeris