nrf51822 UART tx interrupt not firing, arbitrarily when soft device is enabled.

[SBatt]

Hi,

I've written an app on the nrf51822 (rev2), with S110 (v7.3.0) and SDK v6.1.0. I've written a custom non-blocking UART driver. I'm running into an issue where the UART TX interrupt arbitrarily decides not to fire. ie,

NRF_UART0->TXD.AsWord32 = byte;

Does not always result in a tx interrupt. 99.9% of the time it will, though all of a sudden it will stop for a period of time. It's seams like something is clearing the tx interrupt enable bit?

This problem ONLY happens when the softdevice is enabled. I CANNOT repeat the problem when the BLE SD isn't running.

To test my application wasn't causing the issue, I went back to the ble_app_hrs example from the SDK and ported my serial driver to the project. So nothing but the hrs app and my serial driver is present. The problem persists, again, only when the SD stack is running.

Any ideas?

Cheers, Sam

[SBatt]

Thanks Ulrich for the response, though I am not using WFI, WFE or sd_app_evt_wait() anywhere. I removed it from the ble_hrs app because I have processes in the main loop.

I did solve the problem, however, on a whim. Anytime I send a packet out my serial driver I have to start tx (NRF_UART0->TASKS_STARTTX = ENABLE) and then when the entire packet is emptied in the interrupts I had to stop (NRF_UART0->TASKS_STOPTX = ENABLE). Prior to this I just enabled TX during initialisation, which as mentioned in my original question, works fine when the soft device isn't enabled.

Any ideas why this fixed my problem?

I couldn't find it mentioned in the reference manual, but I may have missed it. I'm hesitant to call it 100% fixed because I can't explain why it worked. I'm running some tests now and it's been successful so far.

Cheers, Sam

[Ulrich Myhre]

Sorry, I can't really explain that behavior. The UART should not be touched at all by the SoftDevice. Are you checking for UART errors in the IRQ handler as well? Is the chip otherwise operative in the interrupt-less state, or is it sleeping? If it is doing e.g. directed advertisements, it will block all incoming interrupts for 1.28s. This is due to a PAN in the earlier chip revisions that requires the SD to own the CPU whenever the radio is on.