strange behaviour of spi handler

RE: strange behaviour of spi handler

Jorge — Mon, 26 Sep 2016 10:52:20 GMT

It was a timing issue. The toggle of the WAKEUP_PIN was to update the sampling rate on the DSP, but it was wrongly configured there. And so only with the "delay" of the prints the sampling rate on both sides would match.

Now with that fixed I can delete the prints and the sound has good quality! Thank you all for the help

RE: strange behaviour of spi handler

butch — Mon, 19 Sep 2016 10:42:55 GMT

I am suggesting that the printf could be writing beyond its buffer (buffer overrun.) If you think it is timing related, substitute a delay for the printf. Also, your while loop could be a buffer overrun. Inside the loop you increment spi_counter without checking that it is less than the end of the buffer?

RE: strange behaviour of spi handler

Susheel Nuguru — Mon, 19 Sep 2016 08:35:48 GMT

I agree there seems to be some timing related issue here- Try to change the priority of the spi_event_handler APP_IRQ_PRIORITY_HIGH and see if it improves.

This is defined in nrf_drv_spi_config_t and used in nrf_drv_spi_init

RE: strange behaviour of spi handler

Jorge — Mon, 19 Sep 2016 07:31:11 GMT

Hi butch,

the printf() are there because they were on the example and it seems that this only works when they are there. I'm not even printing this to anyplace. Regarding the memset and memcpy, I need this because in the end of my project I'm going to take out the memcpy, he is only here for debug purposes.

RE: strange behaviour of spi handler

butch — Sat, 17 Sep 2016 10:59:40 GMT

I agree it probably is timing related, but I don't have any experience. I do have other ideas: you are treating the buf as a null-terminated string in the call to printf(), is it really null-terminated? Also, you don't need the memset(0) since right after that you memcpy over the zeros?