1

I encounter a strange thing.

I have a star shaped topology of 1-wire devices. Every branch (there are four of them) of the star has a DS2413 and a DS18B20 at its end. The DS18B20 is supplied with a +5V line and the DS2413 runs in parasitic mode on the data line. The Data line is fed from the center node via a 5 kOhms Resistor. Both the controller and the slaves have ESD-protection devices and small resistors (<5 Ohms) for ESD and surge protection added to the data line.

Everything Detection of bus slaves seem to work fine, i.e. devices are detected and addresses are valid. But what really puzzles me is, that when I call OneWire::reset() from the OneWire libray, it fails. I.e. it returns 0 which means either the bus is broken or there is no slave that can respond.

Update the call to OneWire::reset() occurs in a selfwritten library resembling typical sample code to read temperature data from a DS18B20. If I put my library into a smaller test program, the OneWire::reset() call does not fail. It seems to be related to other parts of my code, which somehow affects the OneWire library.

Update 2 I narrowed down a part of my problem. As written above, OneWire::reset() returns 0 when run from my bigger project opposed to a smaller test program. Unfortunately there are two possibilities where the '0' can stem from in this library. I modified the library and found out, that the method returns after working through the complete code. I.e. the sanity check at the middle does not fail. Apparently no 1-wire slave responds with a presence pulse, which is strange, because in my simplified example it works. Here comes the code sample from the OneWire-library.

uint8_t OneWire::reset(void)
{
IO_REG_TYPE mask = bitmask;
volatile IO_REG_TYPE *reg IO_REG_ASM = baseReg;
uint8_t r;
uint8_t retries = 125;

interrupts();
// wait until the wire is high... just in case
do {
    if (--retries == 0) return 0;
    delayMicroseconds(2);
} while ( !DIRECT_READ(reg, mask));

noInterrupts();
DIRECT_WRITE_LOW(reg, mask);
DIRECT_MODE_OUTPUT(reg, mask);  // drive output low
interrupts();
delayMicroseconds(480);
noInterrupts();
DIRECT_MODE_INPUT(reg, mask);   // allow it to float
delayMicroseconds(70);
r = !DIRECT_READ(reg, mask);
interrupts();
delayMicroseconds(410);
return r;
}

So, what are possible explanations for this behaviour?

  • To make it short: The problem was not the library but defect code elsewhere. I have difficulties imagining how this question could grow beneficial to the community here, even if I tried to explain the whole matter. So I'd like to discuss this a little. – Ariser Jun 13 '17 at 19:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.