We have a problem that we are struggling to solve. We have written an application for the Nordic Semiconductor nRF52832 which uses a proprietory radio protocol. This protocol is based on the concept of a time frame, during which a message is passed from a protocol master, received by the protocol slave, which then transmits a response which is in turn received by the originating master, during a fixed time frame. To achieve this, we program the hardware timers to run a software interrupt routine which sets the radio channel and triggers message transmission, and we use a combination of radio shortcuts and software interrupt handlers to process the radio message reception and schedule the reply. In order to gain a real-time understanding of the radio behaviour, we use dedicated GPIO channels which are driven either by PPI from radio events, or via software run from timer and radio interrupt handlers.
The core of the protocol which allows frame synchronization and message exchange has been implemented and shown to work (although there are a couple of corner case issues to resolve) reliably, while a debugger is attached to our IDE (we are using IAR Embedded Workbench for ARM). The problem we are experiencing is that when we detach the debugger logically (it is still physically connected to the target, but the IDE is not communicating with it), we can see that the GPIO channels allowing us to observe the radio operation significantly change their timing, and thus the protocol no longer operates.
So, with exactly the same hardware and software, the system timers, or PPI operation, or something, behaves very differently when a debugger is operational and when it is not, even though no trace is being collected from the target and no variables are being introspected while the target is running. Indeed, it is the case where the debugger is *dis*connected that seems to cause the problem. We are unaware of any mechanism by which this could happen, and of course are hampered in our investigations by the fact the it is only when we are unable to observe the system that it doesn't work correctly. A real Heisen-bug! Is there some interaction between the ARM trace macro cell and the Nordic bus infrastructure that we are not aware of, especially if debugging is not enabled?
