Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

How to resolve Raspberry I2C slave detect/scan issue?

Status
Not open for further replies.

bala0x07

Junior Member level 3
Joined
Oct 19, 2017
Messages
31
Helped
13
Reputation
26
Reaction score
13
Trophy points
8
Location
Chennai
Activity points
292
Hi everyone,

I'm currently working with the I2C interface of the Raspberry pi Model B.
I want to interface a Real time clock DS3231 with the Rpi.
The problem is Rpi's I2C is only scanning a maximum I2C address of 0x77 whereas the RTC chip address is at 0xD0.
I thought that the Pi is considering only 7-bit slave address and doing the shifting works by itself and will expect 0x68 instead of 0xD0 (0xD0 >> 1 = 0x68), but it didnt work.
Ok lets assume only 7-bits, anyhow the maximum address should be 0x7F and not 0x77, right ?

Ok lets forget the scan, I just tried to ping the chip with its address, but it reporting an error only when I input a slave address greater than 0x77

The same problem happens on ESP8266 with Micropython firmware in it.

I have previously interfaced the same DS3231 with PIC & AVR and didnt find any issues.

So what is the issue on these things, why 0x77 is the maximum I2C slave address these devices are expecting ?

I also did surfing round the internet, but no clues.
I could only find how to set DS3231 as Rpi's main clock rather than synchronizing from the web.
But that doesn't serve my purpose. I need full control over the chip.


So what can I do ? Any ideas ?
Had anyone solved these mysteries before ?
 

I2C uses 7 bits or 10 bits for the address, however 7 bits is the more common way. The upper 7 bits are for the address and the lsb is for signaling read or write.

According to the data sheet the address is 0x68. So you should not be fine with the current setup. If I remember correctly some of the addresses are reserved, but I do not remember with ones.

Whether or not you fill in the r/w bit in the address depends on the driver code. Some do this for you depending on the operations while others ask you to fill it in.

Example of how to set it is:
For write:
0x68 << 1
For read:
0x68 << 1 | 0x1

Hope this helped.
 

I would guess (that's all it is) that the Pi actually addresses 0x00 to 0x7F but the addresses between 0x77 and 0x7F are used internally or reserved for Raspberry's own external peripherals. It seems strange though that they would implement a 7-bit I2C bus when 8-bits are standard.

The I2C address is made of three parts though, the LSB is the Read/Write bit (I2C uses different addresses when writing and reading the same port), the next bits are the bus address (selected in the command) and the MS bits are decided by pins on the device itself (so more than one of the same device can share the bus). I think I would refer to the Pi user forum for advice on this as it is so specific to one system. It may be a misunderstanding of the way I2C addresses are described, perhaps your reference is to the higher bits and you have to add the LSB to form a full address. If that is the case, the addressing range would be 0x00 to 0xF7 which seems more likely.

The DS3231 is unusual in that it has no external address pins, presumably because adding more than one RTC to a system is rather pointless. If my assumption about the stated address range is correct, you should still be able to access the DS3231 at addresses 0xD0 and 0xD1.

Brian.
 

The data is 8 bits but the address is 7 or 10 bits. The DS3231 uses 7 bit addressing.The read/write plus the 7 bit address is also 8 bits. So the address range would be 0x0 to 0x7F.

There is an address range check here:
https://github.com/raspberrypi/linux/blob/rpi-4.9.y/drivers/i2c/i2c-core.c#L1101

There is another address range check here:
https://github.com/raspberrypi/linux/blob/rpi-4.9.y/drivers/i2c/i2c-core.c#L1124

Another option if you want the system to use the RTC is to use the DS3232 kernel module. (From a small amount of research it looks it should work.) You can set this up in the overlay. It has been a while since I did this, but I used a Microchip RTC. Overall once the overlay is done it is pretty much plug and play. There may been a change required to disable NTP. This would allow you to use system calls to get the time from userspace applications. I do not recall if the PI has a RTC built in or if would emulate from timers. I know it is not battery backed.
 

Pi's have no RTC as such, they normally set the time using NTP but that assumes a network connection is available. I would guess the time is simply a one second tick, derived by hardware division of the clock that increments a counter. The standard Linux time/date routines can convert the count back to real time mathematically.

Adding routines to the core should work as long as the hardware permits it. I'm not sure if the processor hangs any internal peripherals on the same I2C bus as brought out to the pins, if it doesn't, you will have to be careful that the correct bus is selected.

To be honest, I have several Pi's here but only used a security webcams, I've written high level code (Python) for them but not for interacting with new devices. The addressing sounds strange though, are you saying 0x00 to 0x77 is the high end of the 8-bits and an additional LSB is used for read/write (implying the true range is 0x00 to 0xF7) or the 7 bits includes the R/W bit and the MS bit isn't used?

Brian.
 

There is a bus that is used for something reserved in hardware on the PI. However I am not sure which bus it was exactly. I know there is at least one free I2C bus that could be used. The kernel modules are generally implemented to take advantage of DMA and other features behind the scenes to prevent stuff like stalling the CPU because of something like clock stretching. What I am not sure of is how much is guaranteed in the way of bus arbitration of say an EEPROM with a RTC on the same bus. Perhaps the RTC is only read once and not each time the time is needed. However I never looked that far into it as I believe I gave nearly the entire I2C bus to the RTC. The overlay is responsible for selecting things like the I2C bus number. Although you may be able to hard code the config into the kernel, but that gets a little messy.

i2c-bus.org shows a diagram. I have been trying to communicate that bit 8 is r/w bit. In I2C it is almost a separate part of the the protocol like the start bit or an ack bit. So generally it is not included into the address computation. A little different from what is depicted is that the address msb is sent out last.
https://www.i2c-bus.org/addressing/

Are you trolling? This is the exact same way it is in micro controllers.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top