https://devzone.nordicsemi.com/f/nordic-q-a/34830/uart-spi-issue-nrf52840USB Virtual COM Until now, the development has been done by sending the commands via a USB virtual COM. The received buffer of int is processed and sent to the function `ExecuteCommandLine`, from where the appropiate functions are called depending onen-USTelligent Community 13Wed, 30 May 2018 05:53:29 GMThttps://devzone.nordicsemi.com/thread/133926?ContentTypeID=1Wed, 30 May 2018 05:53:29 GMT137ad170-7792-4731-bb38-c0d22fbe4515:a8fbf948-377c-4fe0-ae7c-c7117a3bcfcdadragocelestica<p>Yes, this seems to be it. I was asking the chip to do too many things inside the UART interruption. Now I am just setting a flag that the while(true) in the main picks up with an if statement so it is the main that executes all the stuff, and it is working correctly. Thank you very much for your help.</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/133777?ContentTypeID=1Tue, 29 May 2018 09:30:37 GMT137ad170-7792-4731-bb38-c0d22fbe4515:8fce2511-52c8-4fc5-8618-30397682f871Einar Thorsrud<p>Hi,</p> <p>This seems like an issue of interrupt priorities. You wait for&nbsp;spi1_xfer_done in a interrupt context, and this should be set in another interrupt handler (or function called by it so that it will have the same priority). The function that sets&nbsp;spi1_xfer_done must have higher priority than the function that polls it for this to work. You will experience this deadlock if it has the same or lower priority, as the function that initiated the SPI transaction will continue to run forever, blocking any lower or same priority interrupts from being handled.</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/133621?ContentTypeID=1Mon, 28 May 2018 10:21:30 GMT137ad170-7792-4731-bb38-c0d22fbe4515:2994dc52-1822-40d1-8196-0bd51d66ca37adragocelestica<p>By the way, I am using SDK 15 with SEGGER, programming my board from the evaluation board pca10056</p><div style="clear:both;"></div>