Reading different values of Radio register if application is running normally vs debugging

[Ales]

Hi!

I am running Zephyr direction finding sample for AoA transmitter (nRF Connect SDK). At the end of main function I read DFECTRL1 register just to make sure that it is configured correctly:

printk("NUMBEROF8us: %ld\n", (NRF_RADIO -> DFECTRL1)&RADIO_DFECTRL1_NUMBEROF8US_Msk);

I flashed the board with sample application and printk reported that register value was set correctly. But then I wanted to do some debugging so I single stepped through main function and printk reported register value which was unexpected (default value of register). I am using Eclipse IDE so I then checked radio registers value while debugging and all registers had default values through whole application.

Can anyone explain me why do registers get different values if application is running normally versus single stepping through it? I read that Softdevice is blocking r/w operations on register but since I am using nRF Connect SDK I am not using Softdevice so I don't know where the problem is.

Next image show serial when I was first debugging and then ran application normally.

Thanks for helping.

[Simon]

Hello,

Sorry for the delay on this. There's been national holidays in Norway the last days, so I haven't been able to look into this,

I'll take a look at this the next days.

Best regards,

Simon

[Ales]

Hi, no worries, take your time.

[Simon]

I was able to reproduce your issue, and I only saw the issue (RADIO_DFECTRL1_NUMBEROF8US_Msk being equal to 2) when I put a break point after bt_le_ext_adv_start(), so it doesn't not seem like it's possible to halt the cpu while advertising. It should not be any specific timing requirements while advertising, but I'm not sure, maybe the radio event scheduler does have some timing requirements.

When using the SoftDevice, the radio is often power cycled, to make sure it gets default values before it gets configured. That may be worth looking into.

Maybe it's related to Eclipse? You may test a different debugger, like Ozone. 

Here is also a tip from a colleague: https://devzone.nordicsemi.com/support-private/support/264088#permalink=633142 

Here is a whitepaper on direction finding that may be useful: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fnwp_036%2FWP%2Fnwp_036%2Fintro.html&cp=16_1 

Best regards,

Simon

[Ales]

First thank you so much for taking your time to examine the issue. Power cycling or some timing requirements makes sense. Can you please provide alternate first link because I get Access Denied.

Best regards,

Ales

[Simon]

Here is the reply that I was trying to link to: "I don't have any good suggestion no, for debugging not directly related to BLE you could avoid starting advertisement /connection, thereby you should be able to stepping code for issues that are not directly related to BLE."