Getting data from a rtc device through I2C

You won't need the bus driver. Please check the gpio and rtc devicetree nodes, which I used in my NEEK extension design.

gpio_0: gpio@0x1500 {

compatible = "opencores,bit-gpio-2.0","opencores,bit-gpio-rtlsvn2";

reg = < 0x1500 0x10>;

bidir-width = <8>;

input-width = <4>;

# gpio-cells = <2>;

gpio-controller;

}; //end gpio (gpio_0)

i2crtc {

# address-cells = <1>;

# size-cells = <0>;

compatible = "i2c-gpio";

gpios = <&gpio_0 7 0

&gpio_0 6 0>;

scl-is-output-only;

rtc@68 {

compatible = "ds1307";

reg = <0x68>;

};

};

Hello hippo,

Thank for replying to my post. I tried your solution but when my board is booting, the i2c-gpio driver reports an error about the i2crtc node as we can see below:

 altera_gpio: /sopc@0/gpio@0x6002630: registered, irq -6
 altera_gpio: /sopc@0/gpio@0x6002640: registered, irq -6
 altera_gpio: /sopc@0/gpio@0x6002650: registered, irq -6
 altera_gpio: /sopc@0/gpio@0x6002660: registered, irq -6
 altera_gpio: /sopc@0/gpio@0x6002670: registered, irq -6
 /sopc@0/i2crtc: invalid GPIO pins, sda=-22/scl=-22
 JFFS2 version 2.2. © 2001-2006 Red Hat, Inc.
 msgmni has been set to 25
 io scheduler noop registered (default)
 ttyAL0 at MMIO 0x6002540 (irq = 2) is a Altera UART
 console  enabled

I looked on the source code and I found that error -22 match the EINVAL errno value (invalid argument) in the i2c-gpio driver's probe function. Extract below:

/* Check if devicetree nodes exist and build platform data */
static int i2c_gpio_of_probe(struct platform_device *pdev,
			     struct i2c_gpio_platform_data *pdata)
{
	struct device_node *np = pdev->dev.of_node;
	const __be32 *prop;
	int sda_pin, scl_pin;
	int len;
	if (!np || of_gpio_count(np) < 2)
		return -ENXIO;
	sda_pin = of_get_gpio_flags(np, 0, NULL);
	scl_pin = of_get_gpio_flags(np, 1, NULL);
	if (sda_pin < 0 || scl_pin < 0) {
		pr_err("%s: invalid GPIO pins, sda=%d/scl=%d\n",
		       np->full_name, sda_pin, scl_pin);
		return -ENXIO;
	}
        
}

So I think, something goes wrong in my device tree. Here is what I did:

-> in my device tree, I replaced the I2C_RTC node (described as a sub node of the sopc)

       sopc@0 {
		ranges;
	# address-cells = < 1 >;
	# size-cells = < 1 >;
		device_type = "soc";
		compatible = "ALTR,avalon", "simple-bus";
		bus-frequency = < 50000000 >;
		
		
		I2C_RTC: gpio@0x6002660 {
			compatible = "i2c-gpio";
			reg = < 0x06002660 0x00000010 >;
			width = < 2 >;	/* width type NUMBER */
			resetvalue = < 0 >;	/* resetValue type NUMBER */
		}; //end gpio@0x6002660 (I2C_RTC)
                
		
	}; //end sopc@0

by: (see bold text)

        sopc@0 {
		ranges;
	# address-cells = < 1 >;
	# size-cells = < 1 >;
		device_type = "soc";
		compatible = "ALTR,avalon", "simple-bus";
		bus-frequency = < 50000000 >;
		
                
                gpio_0: gpio@0x6002660 {
			compatible = "ALTR,pio-10.0","ALTR,pio-1.0";
			reg = < 0x6002660 0x00000010 >;
			//bidir-width = <8>;
			//input-width = <4>;
			width = < 2 >;
			resetvalue = < 0 >;
		# gpio-cells = <2>;
			gpio-controller;
		}; //end gpio (gpio_0)
		i2crtc {
		# address-cells = <1>;
		# size-cells = <0>;
			compatible = "i2c-gpio";
			gpios = < &gpio_0 100 0 /* SDA signal */
					  &gpio_0 99 0 >; /* SCL signal */
			scl-is-output-only;
			rtc@68 {
				compatible = "m41t83";  /* as my rtc chip is an ST m41t83 */
				reg = <0x68>;
			};
		}; //end i2crtc
         }; //end sopc@0

Where am I going wrong?

Actually, when parsing the device tree, the i2c-gpio driver could not retrieve the 'gpios' field use to describe the SDA and SCL pins. So I decided to come back to a module which create an i2c bus and then, populate this bus.

# include <linux/module.h>
# include <linux/init.h>
# include <linux/i2c-gpio.h>
# include <linux/i2c.h>
# include <linux/platform_device.h>
# include <linux/kernel.h>
# define GPIO_RTC_SDA		100
# define GPIO_RTC_SCL		99
MODULE_DESCRIPTION("i2c via gpio module");
MODULE_LICENSE("GPL");
static struct i2c_gpio_platform_data rtc_device_data = {
	.sda_pin = GPIO_RTC_SDA,
	.scl_pin = GPIO_RTC_SCL,
	.udelay  = 2.5,				//f=400kHz
	.scl_is_open_drain = 1,
	.sda_is_open_drain = 1
};
static struct platform_device i2c_gpio_bus_rtc = {
	.name 	= "i2c-gpio",
	.id		= 0,
	.dev	= {
		.platform_data = &rtc_device_data,
	}
};
static struct i2c_board_info i2c_gpio_bus_devices = {
	{
		I2C_BOARD_INFO("m41t83", 0x68),
		.platform_data = &rtc_device_data,
	},
};
static int __init i2c_gpio_bus_init(void)
{
	int ret;
	struct i2c_adapter *bus;
	struct i2c_client *rtc;
    ret = platform_device_register(&i2c_gpio_bus_rtc);
	if (ret)
		printk(KERN_ERR "i2c_bus_driver: Error when registering: %d\n", 
		ret);
	/* Populate bus */
	bus = i2c_get_adapter(0);
	rtc = i2c_new_device(bus, i2c_gpio_bus_devices);
	if (rtc == NULL)
		printk(KERN_ERR "i2c_bus_driver: no device added to %s bus\n",
		bus->name);
	
	return ret;
}
static void __exit i2c_gpio_bus_exit(void)
{
	platform_device_unregister(&i2c_gpio_bus_rtc);
}
module_init(i2c_gpio_bus_init);
module_exit(i2c_gpio_bus_exit);

However, I still do not found my device at the address 0x68 with the i2cdetect utility :-(

Could someone help me?

Hi everyone,

As I cannot found my rtc device on the i2c bus, I am using an oscilloscope to see what's happening on the bus. Here are the measures performed on the SDA and SCL pins:

https://www.alteraforum.com/forum/attachment.php?attachmentid=7752

We can see that we get a NAK from the device. But something catch my attention: the time the clock is high between the first SCL's rising edge and the following falling edge. Is it normal?

Remember that my rtc device address is 0x68

Hi,

Maybe you need the function 'i2c_put_adapter' like

static int __init i2c_gpio_bus_init(void)
{
    int ret;
    struct i2c_adapter *bus;
    struct i2c_client *rtc;
    ret = platform_device_register(&i2c_gpio_bus_rtc);
    if (ret)
        printk(KERN_ERR "i2c_bus_driver: Error when registering: %d\n", 
        ret);
    /* Populate bus */
    bus = i2c_get_adapter(0);
    rtc = i2c_new_device(bus, i2c_gpio_bus_devices);
    i2c_put_adapter(bus);    // <--- here
    if (rtc == NULL)
        printk(KERN_ERR "i2c_bus_driver: no device added to %s bus\n",
        bus->name);
    
    return ret;
}

Kazu

Hi Kazu,

Thank you for your reply. I added the i2c_put_adapter(bus) in my module, however I do not have the expected result. Actually, I get some strange result, as you can see on the image below:

https://www.alteraforum.com/forum/attachment.php?attachmentid=7759

On the 9th SCL's rising edge I get a half voltage level which is interpreted as a NAK by the i2cdetect utility. This curious case disappears if I configure the SCL as "output only". This brings me to think about my pins configuration: as the SCL and SDA lines are open drained, I configured them as such.

Am I right, or I need to set them as output only as Hippo told me?

In both cases I get a NAK...

jrm

Hi,

--- Quote Start ---

On the 9th SCL's rising edge I get a half voltage level which is interpreted as a NAK by the i2cdetect utility. This curious case disappears if I configure the SCL as "output only". This brings me to think about my pins configuration: as the SCL and SDA lines are open drained, I configured them as such.

--- Quote End ---

Did you make the SCL and SDA 'hardware pins' open-drain ? It seems that a bus fighting occurs. The SDA line is used bidirectionally, your FPGA pin must be tri-state when the slave returns the ACK (= 0) signal. The open-drain pin is a simple method to achieve this. The SCL pin can be 'output only' if you don't have other I2C master except your FPGA.

Kazu

Hi Kazu,

Thank you for these explanations. Indeed, the 'hardware' SCL and SDA pins are open-drained with a 4k7 resistor, so I configured them as such in the module I wrote.

Our design uses the basic altera GPIO, and I came upon this webpage: http://www.alterawiki.com/wiki/gpio where the author uses the opencore GPIO instead of the basic altera GPIO. So, do you think the bug I cope with can come from this difference?

jrm

Hi,

--- Quote Start ---

Indeed, the 'hardware' SCL and SDA pins are open-drained with a 4k7 resistor, so I configured them as such in the module I wrote.

Our design uses the basic altera GPIO, and I came upon this webpage: http://www.alterawiki.com/wiki/gpio where the author uses the opencore GPIO instead of the basic altera GPIO. So, do you think the bug I cope with can come from this difference?

--- Quote End ---

At first, please check the resistor's value, soldering of SDA line, m41t83's power line. And check the rising and falling time of SCL. It must be < 300ns. Please refer

http://www.st.com/st-web-ui/static/active/en/resource/technical/document/datasheet/cd00127116.pdf

at pp.53. If the rising time of SLC is not enough, it is one method to set the SLC hardware pin as output.

In the i2c-gpio method, SCL and SDA signals are generated directly by your Nios CPU, and this is the reason why the SLC clock period is not constant. If you have any doubt, there is another way to use an 'opencore's i2c core'.

Kazu

Hello,

--- Quote Start ---

At first, please check the resistor's value, soldering of SDA line, m41t83's power line. And check the rising and falling time of SCL. It must be < 300ns. Please refer

http://www.st.com/st-web-ui/static/active/en/resource/technical/document/datasheet/cd00127116.pdf

at pp.53.

--- Quote End ---

Everything is okay, I checked all timing specifications at pp.53. However, the SCL's frequency is never higher than 12kHz, even if I set the struct i2c_gpio_platform_data's udelay field (in the linux module) to 2 for example. Normally, the SCL's frequency should be 500kHz when setting udelay to 2. Anyway, even at 12kHz, the RTC device should acknowledged to I2C frames.

So I think I am going to try with the opencore's GPIO..

jrm