Im having similar issues - the wait_us() does not seem to work properly - I can get the 1wire code working just fime for Nucleo, but no for W7500P or NRF dev board. On the other hand I have worked on a projekt using nRF51822 being developed using native libraries in Keil and it DID work for sure. So this looks like an mbed issue from where Im standing.

I have also used logic analyzer to do some analysis here and looks like both nrf5188 dev kit and w7500p dev kit have the same timing issue with onewire. Nucleo works like a charm (with the same code)

I believe this is a change that was added to reduce the power consumption of the NRF51822.

See: https://developer.mbed.org/questions/4693/Lower-power-Mode-Nordic-nRF51822/

From the post:

We made some changes recently to lower baseline power consumption; in particular:

the system now starts with low-frequency clock by default (instead of using the external 16MHz clock). The high frequency clock is kicked into action automatically by the soft-device when needed; but now it doesn't remain active all the time. This by itself lowers the baseline consumption significantly. We make an effort to avoid using wait(), which is currently synchronous and wastes a lot of power. We've also re-implemented the Ticker APIs to use the RTC instead of a high-frequency timer. This makes a tradeoff between precision and power; and we believe power trumps over precision in the context of BLE.

Users are free to enable high-frequency timers explicitly if needed. If an application requires the use of high-frequency clock (for instance to do serial communication at high baud rates), then it must enable the high-frequency clock by writing into the appropriate control registers (please refer to the datasheets of the nRF51822). It would help to turn off the high-freq. clock at the earliest opportunity.