RE: I2S clocks and softdevice

matty — Mon, 14 Sep 2020 01:51:36 GMT

After I call nrfx_i2s_stop, an assertion is thrown in the I2S data handler. For some reason the data handler seems to be called by the I2S peripheral even after nrfx_i2s_stop is called. The assertion is NRF_ERROR 8 - Invalid State on a nrfx_i2s_next_buffers_set call. The invalid state is defined as either the buffers have already been supplied or the peripheral is currently being stopped. The way I fixed this was to wrap the code in the i2s_data_handler in an if (status & NRFX_t2S_STATUS_NEXT_BUFFERS_NEEDED) condition.

My understanding is that the data handler's 2nd in parameter, status, will be either 0 or NRFX_I2S_STATUS_NEXT_BUFFERS_NEEDED. Although I have read about a second value called NRFX_I2S_STATUS_TRANSFER_STOPPED in Drivers->nrfx v2.3. That value isn't available in my environment.

So it works now and my problem had nothing to do with clocks or the softdevice. However, I have yet to figure out how the code worked in a none BLE application. Back to work.

RE: I2S clocks and softdevice

matty — Sun, 13 Sep 2020 17:48:09 GMT

I can't decide if the call to nrfx_i2s_stop() is causing the firmware reset or if its the return back to main after my I2S function finishes. I'd think it was my program structure that is at fault but why can't I have all of the I2S code in a separate module and leave main out of it. The worse thing I'm doing is having main wait for the function to return and that period is a little more than 500 mS.

I have slightly changed the above code to alternate calls to nrfx_i2s_stop() I don't call nrfx_i2s_stop before returning to main but I call it at the beginning of the second time main wants to use the microphone. The following screen shot illustrates the results.

Point 1) Otii powers up and firmware starts.

Point 2) main's timer triggers a call to "i2s_mic_generate_an_spl". main waits for it to return.

Point 3) "i2s_mic_generate_an_spl" starts the PWM "clocks". It starts a 500 mS app_timer to give the microphone a half second to stabilize.

Point 4) nrfx_i2s_start is called. "i2s_mic_generate_an_spl" waits until the I2S data handler has toggled a flag signalling that data collection is complete. On this first call, "i2s_mic_generate_an_spl" then stops the PWM "clocks" but does not call nrfx_i2s_stop. "i2s_mic_generate_an_spl" returns to main.

Point 5) Back in main. Note the elevated power level. Don't know what causes that. There must be a clock associated with the nrfx_i2s_start call still running.

Point 6) main makes it's timer induced advertisement.

Point 7) main's timer triggers the second call to "i2s_mic_generate_an_spl" and waits for it to return.

Point 8) In this second call, the first thing "i2s_mic_generate_an_spl" does is call nrfx_i2s_stop. It would then start the PWM "clocks", wait on it's timer, call nrfx_i2s_start, wait for the I2S data handler to toggle the flag etc.. Obviously, there is no PWM, no I2S, etc...

Point 9) Firm ware reset and repeat of sequence.

I'm doing something that isn't allowed. I just can't figure out what it is. I'm hoping its something obvious to more experienced folk and greatly appreciate their observations and thoughts.