Due to the errata of some of the stm32f1xx family, the i2c lines need
to be toggled when setting up the peripheral. This however seems to
hang some i2c slaves which do not ack the first message sent after
initialization. This caused the code to be stucked waiting for the
never coming ACK. The same situation could occur when a byte was not
acked due to whatever reason.
The previous implementation of the i2c driver didn't allow recovery
on these situations. Now the driver does not block forever but rather
returns a <0 code to indicate that the transaction was not succesful.
This fixes reading more than 2 bytes from the slave device.
In the current implementation the last byte was not read from
data register and the termination sequence buggy.
