BTW, an easy workaround for this would just be rejecting any requests
that aren't in the 0x8..0x77 range on the nRF52. That's valid on any
chip, to be honest, though only an issue on the nRF52.
I'll see if I spot anything on the logic analyzer tomorrow, though, but
I think this is internal to the peripheral block itself inside the chip
and so it won't likely appear just looking at the I2C transactions. But
I'll let you know once I have it hooked up again.
On 27/12/16 01:51, will sanfilippo wrote:
What I am going to say is obvious, but has anyone hooked up an i2c analyzer to
see what is actually going on in the two cases? I dont see why the peripheral
would act differently based on the address itself; something must be happening
on the bus causing the peripheral to act differently.
When I was messing around with the nrf i2c peripheral I used the probe API but
only for the address I was expecting.
The way we are programming the nrf peripheral might indeed be an issue here but
without knowing more about how devices act and more about the i2c protocol
itself I dont think I can offer anything intelligent here :-)
I dont have an analyzer with me but if no one can get a hold of one and test it
out, I will try to get something set up later in the week.
