Why specifically Mbed OS 5.7.7? Have you tested Mbed OS 5.11.5?

Hi Zoltan. the Xdot stable build library was built with 5.7.7. There are (only) dev builds with newer mbed-os. "The Dot library version and the version of mbed-os it was compiled against can both be found in the commit message for that revision of the Dot library. Building your application with the same version of mbed-os as what was used to build the Dot library is highly recommended!"

Sorry I didn't notice that you need also libXdot. Could you try https://os.mbed.com/users/hudakz/code/DS1820/? It's using open drain for STM MCUs too. If that works than it must be something else.

Thanks Zoltan. I fully expected to try that and have a problem ... but nope. your library added in to the same codebase with just some name tweaks to avoid 2 DS1820 classes returns a temperature, while the other hits that data read error.

Switching over DS1820 library would be an option, but as the I2C read is also failing. Any chance you can help me diagnose what is different in these libraries that would be affected by the updraded os / target / config?

trying to look for answers. not sure what this is, other than odd. inline gpio_read() in the stm target return ((*obj->reg_in & obj->mask) ? 1 : 0);

onewire.h seems to be the opposite. #define READ() ((*gpio.reg_in & gpio.mask) != 0)

but both one-bit-in functions use answer=read() and there is no difference between the target files for this in newer and older STM targets

PS sorry, not sure how to format code in comments

To read the one-wire line status, Sissors library adapted the same code as used by mbed library to read GPIO status, which is defined in mbed-os/targets/TARGET_STM/gpio_object.h

static inline int gpio_read(gpio_t *obj)
{
    return ((*obj->reg_in & obj->mask) ? 1 : 0); 
}

In my version of OneWire I tried to optimize that piece of code in hope to make it a bit shorter and faster.
Assuming that:

• obj->reg_in is same as gpio.reg
• obj->mask is same as gpio.mask
• and that the ternary operator is actually equivalent to

if ((*obj->reg_in & obj->mask) != 0)
    return 1;
else
    return 0;

we can achieve the same goal if we simply write

return ((*gpio.reg_in & gpio.mask) != 0);

but probably with less binary code and hence faster.

So it must be something else. I'll try to have a closer look and let you know in case I find something.

PS: To format your code surround it with <<code>> and <</code>> tags, each on separate line:

<<code>>
your source code
<</code>>

ahh. thanks x2. of course... sorry. (not the first time I stuffed up a double negative (not false == is true)) I'm really not seeing anything 'obvious'. The only other avenue I'm even thinking possible within these libraries is the slight difference in delay times, so if the target timer code has changed, those delays cause this behaviour. But that seems 1) unlikely 2) not sure how/if it could cause these bits to both be high simultaneously In the back of my mind I'm trying to think of something further away - that may have changed to affect 1 wire and I2C , but 1 wire in only the other library??? I'm seriously stumped

Ok I fixed I2C. STM modified the default correctly from pullup to nopull. pullup had obscured that our hardware guy missed a pullup resistor there. Still stuck on 1 wire

Getting closer I think - I tested your library. if the 0xF0 byte doesn't get written, the error mode is what happens in sissors library. I realise its the other library but its not using the byte_out function, rather calling the equivalent loop on bits. I still can't see why the write may be failing with the updated mbed-os, target etc Edit written the same time as the accepted answer!