The BMP180 is an I2C air pressure and temperature sensor.
Sounds simple right? A quick search of issues with this little sensor and there appears to be one very common problem that pops up all over the internet.
The device reads 0xFF. Best of all, despite the thousands of examples of this problem, nobody has an explanation or answer to it.
People seem to solve the problem and don't explain what the issue was or how they fixed it.

There are plenty of people suggesting fixes for it and even when the person does fix it with that advice, they still don't mention which solution worked.

Ok, the specifics of my problem.
I'm bit banging the I2C bus. Yes I know there are UARTs to do it. No, for this case I am not going to use them because it is not solving the problem.
Yes there are libraries for I2C and BMP etc. While they are simple to use, they are poorly documented. They're a black box solution and the point of the exercise is to understand the problem, not just make it go away or plug in a code library. I mention these because they are often the solutions people give when they don't understand the problem, don't know or want to fix it.

Now, we can assume that the bit banging code is working fine. I can talk to other I2C devices with it using the same hardware. This doesn't exclude an MCU hardware issue like pull up resistors, but we can assume that I can see what the bus is doing with some* precision.

This is the sensor datasheet for your those interested in reading it.

There isn't any need to concern yourself with the complex stuff. Just the I2C communication because that is the issue.

The I2C device address is EE/EF read/write. This is the first byte of the I2C communication.
The first 7 bits are the address and the LSB is the R/!W. So you will often see the device address expressed as 0x77. (which is what I use too).

So... we write 0xEE (77) to the device and it responds with an ACK-nowledge (it pulls the SDA line low).
I can demonstrate this by polling all addresses 0x00 to 0x7F and only 0x77 responds with an ACK.

So, we know the MCU is talking to the BMP180.

The next step is to write a byte value to the BMP180.
Lets use the value 0xD0. To which the BMP180 responds with another ACK. (It got the byte).

Now for the fun part.
We send a second I2C start bit and then send the device address (77) and a read bit so the byte sent is (EF).
The BMP180 responds with an ACK and now it should be ready to dump the value of [D0] to the bus. The result should be the chip ID of 0x55.

But instead we get a response of 0xFF.

It doesn't matter what combination I try, the result is always 0xFFh reading from the device.

If I change the read address from 0xD0 to 0xAA or anything to 0xBF which is all calibration data, I should find some kind of response.
But everything reads 0xFF. The BMP180 appears not to be sending any data to the bus.
It's not pulling the SDA line low where I expect to find a bit 0.
I change the device. Same result. Change the Vcc from 3.3V to 5V. Same result.
Change the pull up resistors, same result.

There must be a sequence of bytes to get the device to communicate.
But nobody says or knows what this sequence is?

S EE EO P (soft rest) S EE D0 S EF .. the result should be 55 but it is FF.
S EE AA S EF .. should be anything but 00 or FF. It's FF

Follow the flow chart and write....
S EE F4 2E P (wait 10mS) S EE F6 S EF .. result is still FF