nRF52-DK debugger causing timing issue

[rickychau]

Hi all,

i am trying to get DS18B20 temperature sensor to work on a nRF52832 chip. I have successfully ported this onewire library which is for nRF51 series to work on nRF52832. I can communicate with the DS18B20 without any problem when i have the J-Link debugger on (i am using nRF52-DK as my debugger) i.e. running debug. Even if i have SoftDevice enabled, i am able to read the temperature data and send it out via BLE.

However, when i have the debugger unplugged, power cycle the chip, the BLE part of the code works fine, but the temperature data is no longer valid.

I have found lots of discussion around if SoftDevice is enabled, bit-banging timing might have been screwed up as well as the one wire protocol timing. So i went on and create a simple program just having a timer for driving the bit-banging of the one wire protocol. Again, i can read the temperature data/serial number etc correctly under debug mode. but once i have the debugger off, unplugged it, power cycle the chip, the reading no longer valid.

When i scope the signal, i realize when i am not running debug, the one wire protocol wave form is "stretched out", meaning for each data pulse, say when running in debug, the signal is 10us wide, and running without the debugger, the signal stretched out 11us wide. 

My question is, when the program runs in debug mode, is there any timing setting may have been overrode? Or any other possibility that would cause this to happen?

One thing worth noting is, the one wire library needs a timing in the micro second range, as low as 1 us. i have tested the nRF52832 timer compare can only pick up the best of 5 us interval. This is another question i have as well, what's the timing spec for the timer compare event? (Given the Timer is using 16MHz with 0 prescaler)

Any help would be appreciated. Thanks

Ricky Chau

[Håkon Alseth]

Hi,

 

 

When i scope the signal, i realize when i am not running debug, the one wire protocol wave form is "stretched out", meaning for each data pulse, say when running in debug, the signal is 10us wide, and running without the debugger, the signal stretched out 11us wide. 

My question is, when the program runs in debug mode, is there any timing setting may have been overrode? Or any other possibility that would cause this to happen?

Could you try to run the sequence with the external HFCLK running? If not, you will be sourced by the internal RC, which can have a high tolerance (up to 6%).

 

One thing worth noting is, the one wire library needs a timing in the micro second range, as low as 1 us. i have tested the nRF52832 timer compare can only pick up the best of 5 us interval. This is another question i have as well, what's the timing spec for the timer compare event? (Given the Timer is using 16MHz with 0 prescaler)

It can provide an event every 8 MHz (input frequency / 2), but you'll have to use the timer in combination with GPIOTE + PPI, similar to what is done here:

https://github.com/NordicPlayground/nrf51-8-mhz-gpio-clock/blob/master/main.c

Using the CPU to toggle will slow the process down.

Kind regards,

Håkon

[rickychau]

Håkon Alseth said:

Could you try to run the sequence with the external HFCLK running?

i confirmed the sequence is running with external HFCLK