52832 works different outside of JLink Debugger

[rolandash]

Hi,

This is a really weird problem. 

======================

Setup of 52832 hardware:

- Custom board, using 32MHz XTAL and LF RC.

- SDK15.2, S132 610

- Segger RTT client with JLink debugger.

=======================

This 52832 hardware mainly acts as peripheral and been worked quite well, can connect and communication correctly with iPhone/iPad. 

Recently I try to use a 52840 instead of iPhone/iPad as central to connect with this 52832. The connection parameters are as in below's log.

info> app: [Central Scanning] updating neighbour list: 1 neighbour nodes ...
<info> app: [Central Scanning] connect to peer 0 ......
<info> app: CENTRAL: Connected, handle: 0.
<info> app: CENTRAL: init db discovery: 0.
<debug> ble_db_disc: Starting discovery of service with UUID 0x1 on connection handle 0x0.
<info> app: CENTRAL: start discovery: 0.
<debug> nrf_ble_gatt: Requesting to update ATT MTU to 224 bytes on connection 0x0.
<debug> nrf_ble_gatt: sd_ble_gattc_exchange_mtu_request() on connection 0x0 returned busy, will retry.
<debug> nrf_ble_gatt: Updating data length to 224 on connection 0x0.
<debug> nrf_ble_gatt: Peer on connection 0x0 requested an ATT MTU of 127 bytes.
<debug> nrf_ble_gatt: Updating ATT MTU to 127 bytes (desired: 224) on connection 0x0.
<debug> ble_db_disc: Found service UUID 0x1.
<debug> nrf_ble_gatt: Data length updated to 127 on connection 0x0.
<debug> nrf_ble_gatt: max_rx_octets: 127
<debug> nrf_ble_gatt: max_tx_octets: 127
<debug> nrf_ble_gatt: max_rx_time: 1989
<debug> nrf_ble_gatt: max_tx_time: 1989

In this setup 52832 will send HVX notification to 840, and I am expecting to see maximum 127 bytes of messages received on 840 side.

However, I found that part of the notifications that 52832 send to 52840 are wrong(sometimes even leads to connection timeout), and this problem only occur when 52832 is not connected with JLink Debugger, When I try to investigated it with JLink debugger attached, the problem does not show up.

This seems like some potential memory conflicts with RTT backend to me, probably because I missed something somewhere, or maybe some issue with RTT itself. But the point is I have no means to debug this problem in this case, any suggestion about this situation?

Thank you.

[Kenneth]

Hello,

What have you set NRF_SDH_CLOCK_LF_ACCURACY to on the peripheral/central? Can you try to set it to '1'.

Does you system_nrf52.c file contain errata_108()?

Best regards,
Kenneth

[rolandash]

Kenneth

Both 832 and 840 has the same LF configure as below:

// <0=> NRF_CLOCK_LF_SRC_RC 
// <1=> NRF_CLOCK_LF_SRC_XTAL 
// <2=> NRF_CLOCK_LF_SRC_SYNTH 

#ifndef NRF_SDH_CLOCK_LF_SRC
#define NRF_SDH_CLOCK_LF_SRC 0
#endif

// <o> NRF_SDH_CLOCK_LF_RC_CTIV - SoftDevice calibration timer interval. 
#ifndef NRF_SDH_CLOCK_LF_RC_CTIV
#define NRF_SDH_CLOCK_LF_RC_CTIV 16
#endif

// <o> NRF_SDH_CLOCK_LF_RC_TEMP_CTIV - SoftDevice calibration timer interval under constant temperature. 
// <i> How often (in number of calibration intervals) the RC oscillator shall be calibrated
// <i>  if the temperature has not changed.

#ifndef NRF_SDH_CLOCK_LF_RC_TEMP_CTIV
#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2
#endif

// <o> NRF_SDH_CLOCK_LF_ACCURACY  - External clock accuracy used in the LL to compute timing.
 
// <0=> NRF_CLOCK_LF_ACCURACY_250_PPM 
// <1=> NRF_CLOCK_LF_ACCURACY_500_PPM 
// <2=> NRF_CLOCK_LF_ACCURACY_150_PPM 
// <3=> NRF_CLOCK_LF_ACCURACY_100_PPM 
// <4=> NRF_CLOCK_LF_ACCURACY_75_PPM 
// <5=> NRF_CLOCK_LF_ACCURACY_50_PPM 
// <6=> NRF_CLOCK_LF_ACCURACY_30_PPM 
// <7=> NRF_CLOCK_LF_ACCURACY_20_PPM 
// <8=> NRF_CLOCK_LF_ACCURACY_10_PPM 
// <9=> NRF_CLOCK_LF_ACCURACY_5_PPM 
// <10=> NRF_CLOCK_LF_ACCURACY_2_PPM 
// <11=> NRF_CLOCK_LF_ACCURACY_1_PPM 

#ifndef NRF_SDH_CLOCK_LF_XTAL_ACCURACY
#define NRF_SDH_CLOCK_LF_XTAL_ACCURACY 1
#endif

and yes, errata_108() is included in my system_nrf52.c file:

static bool errata_108(void);

[rolandash]

I suspected clock accuracy issue at first when encounter this problem. But when I check deep into it more, I realized that the physical layer of communication actually works properly on both side. So far I can isolate the cause of this issue within the side of 52832.

I specially checked the memory that sd_ble_gatts_hvx() function referred to, and it seems when JLink debugger is removed, 

sd_ble_gatts_hvx used a very different memory other than I fed it, that explained why 840 received unexpected data as the sender just fetch data from wrong location. But I can not track it down why this could happen because once JLink debugger attached, this problem does not occur.

[Kenneth]

Is it possible you have somehow set that the characteristic should use BLE_GATTS_VLOC_USER instead of BLE_GATTS_VLOC_STACK? (For instance check if ble_add_char_params_t set .is_value_user).

[rolandash]

Kenneth

I did set the characteristic to be BLE_GATTS_VLOC_STACK. In this case I assume the SD should copy the data to sent into internal buffer, so it should be safe to release my user buffer after NRF_SUCCESS returned.