We're currently using STM32F373CC micros in several of our designs. Part of our standard design has an EEPROM connected via I2C. We have our own hardware layer that is tried and proven over the decades. However, it relies on the I2C port pins having pull-ups connected externally.
On some of our new designs we have designed out the pull-up on the SCL line and have set the port pin to Push-Pull mode. In theory, this should be no problem. However, what we've found is that the micro seems to be treating the port pin as open-drain regardless of the setting. For this particular design, we're using PF6 and PF7 as SCL and SDA respectively. With no pull-up connected, the SCL line is flat-lined. With internal pull-up enabled, the SCL line is pulsing, but the rise time is so long it's not working.
Nothing in the reference manual or the datasheet says anything about this issue. In the errata sheet we have (V4), there's quite a bit about the GPIO and I2C, but nothing that seems to relate to this.
For what it's worth, I'll copy and paste the relevant bit of the initialisation:
switch( kasPinMap[eSCL].lwI2CNum )
{
case 1: RCC_APB1ENR.I2C1EN = TRUE; nI2CEEpsRegisters = (void*)&I2C1_CR1; break;
case 2: RCC_APB1ENR.I2C2EN = TRUE; nI2CEEpsRegisters = (void*)&I2C2_CR1; break;
}
//configure the pins
DIO_vConfigure( kasPinMap[eSCL].ePort, kasPinMap[eSCL].lwBit, DIOkeM_Alternate, DIOkeD_PushPull, DIOkePU_None, DIOkeSP_Medium, kasPinMap[eSCL].lwAFN );
DIO_vConfigure( kasPinMap[eSDA].ePort, kasPinMap[eSDA].lwBit, DIOkeM_Alternate, DIOkeD_OpenDrain, DIOkePU_None, DIOkeSP_Medium, kasPinMap[eSDA].lwAFN );
//reset and enable the peripheral
nI2CEE_vReset();
In the debugger, GPIOF looks like this:
AFR values are set to 4.
The I2C registers look like this:
And the RCC registers look like this:
Our Technical Director mentioned that to comply with the I2C standard and allow for multi-master mode, both SCL and SDA should both be open-drain. However, all we have here is the F3 and the EEPROM.
Any thoughts on why we might not be getting the push-pull action out of the SCL line would be appreciated.
Related
I am having troubles using an I2C sensor with the Beagle Bone Black (BBB). The BBB is running a newly flashed 18.04 Ubuntu image specifically for the BBB.
I wired the sensor (VIN, GND, SCL, SDA) to the corresponding I2C2 pins (4, 2, 19, 20) on the BBB using the below pinout.
The sensor is supposed to be using address 0x40, but scanning I2C2 (using i2cdetect -r 2) does not show the sensor.
I have tested this with two separate sensors as I thought at first I may have fried the original sensor somehow, but the results are the same. In fact, running the I2C2 scan command yields the exact same results when nothing is connected at all.
I have read in many places that I2C2 may not be enabled by default, but I assume it is enabled in my case as I can scan I2C2 without getting an error. Is this assumption incorrect? Again, this is a freshly flashed BBB, and I have not enabled/disabled anything - it should be in the default state.
I have also verified the connectivity of my wires between the sensor and BBB. The voltage between VIN and GND on the chip is 3.3V, so it is definitely being powered.
Why can't I connect to my I2C sensors using the BBB?
it could be that the source you are using is outdated or not a viable entry for i2c.
Also, you could use this command to make sure i2c2 pins are available:
config-pin p9.21 i2c
config-pin p9.22 i2c
This may work, also. If this does not work, please reply with your entire source.
Seth
P.S. Also, if you have time, you may want to get an i2c library to use if your software falls short of setting up your own i2c library. They have smbus2 you can install with pip and other i2c libraries out there still.
Here are a few things you should check (in random order).
List all I2C buses wich i2cdetect -l and try them all. Depending on the platform, the i2c bus number in Linux may be different from the peripheral number used in the datasheet and pinout. E.g. "I2C2" might be bus i2c-1 or i2c-3 in Linux).
Use an oscilloscope or logical analyzer to see if the SCL and SDA lines are being driven. If they aren't check the bus number as above. If they are, then check whether the device gives an ACK; if it doesn't, anything else will never work: double-check the chip slave address. There are cheap logical analyzers that you can buy and user with pulseview.
Simply load the Linux driver for your chip (see the kernel docs on how to do it from userspace for a quick test). Then see check if the device appears or use dmesg to see any kernel error messages while probing.
Code below physically breaks nucleo boards. 2 so far.
ST links is unable to connect and boards are not detected.
first dead one was xncleo stm32f411re, another one is nucleo stm32f446re.
I'm a complete beginner and that is pretty much my first code.
and 2 boards dead;) The question is why it may happen? or can one reset the board harder that normal jumper reset
int main()
{
RCC->AHB1ENR = (1<<0);
GPIOA->MODER = (1<<5);
while(1)
{
GPIOA->ODR |= (0<<5);
}
}
This is similar to this question ->
https://electronics.stackexchange.com/questions/204996/stm32-st-link-cannot-connect-to-mcu-after-successful-programming
, answer to which helped me to restore the board, however answers to my problem in this thread are also very helpfull.
some pins used for debugging need to have some settings. if you change those settings the debugger cannot connect anymore. you need to set the debugger to connect under reset when the debug pins are in the initial corrct state. stm32 processors cannot be bricked this simple way.
so not listen to the advices that you need to use crappy STM libraries. just only set the pins you use, not the whole port.
Yes, your problem is with the line "RCC->AHB1ENR = (1<<0);". That enables power to GPIOA, but disables power to the other GPIOs (B,C,D,E, and H on the F411), which includes the SWD pins.
Edit:Reseting problem solved here: https://electronics.stackexchange.com/questions/204996/stm32-st-link-cannot-connect-to-mcu-after-successful-programming
the reason problem occured solved below
Ok, it doesn't physically break the board. Needed hard reset - shorting rst and sb11 pins on nucleo stm32f446re. didn't try on xnucleo yet.
User P__J__ got it right in the comment. I'll cite:
just do not assign to the moder. use |= or &= instead – P__J__
Done.
And the fixed code:
int main()
{
RCC->AHB1ENR |= RCC_AHB1ENR_GPIOAEN;
GPIOA->MODER |= GPIO_MODER_MODE5_0;
while(1)
{
GPIOA->ODR |= GPIO_ODR_OD5;
}
}
I have a sensor with the interrupt output connected to a input pin on my RaspberryPi. My goal is to trigger an event from the sensor interrupt. The data sheet for my sensor says that once an interrupt is triggered on the sensor, the interrupt status register will have the appropriate bit set to 1 and stay that way until it is cleared; while the status register has a status bit of 1, the interrupt pad on the sensor will be pulled down.
My problem is that I can see the status register correctly reflect an interrupt when I physically trigger the sensor. But when I read the pin from my Pi, I never see any change reflected. Here's the gist of my code:
import Sensor
import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BOARD)
GPIO.setup(11, GPIO.IN, pull_up_down = GPIO.PUD_UP)
s = Sensor.start()
while True:
print 'sensor int reg: ', s.readIntReg() # I do not clear interrupt
print 'pin value: ', GPIO.input(11)
The first print will change according to my interaction with the sensor as expected. The second print shows the pin holds 1 or 0 depending on whether it is set to pull up or down, respectively.
It seems like the problem lies in that whenever the interrupt fires, the sensor is pulling the pin down and the Pi is pulling it up... How should I handle this?
The sensor is the VCNL4010 [https://www.adafruit.com/products/466]
I suppose you have the gpio driver installed and active on the Pi?
Then you'll probably never see the interrupt triggering from the Python level since the kernel driver will service it (and reset the flag) already in the background.
I added a 10k external pull-up resistor with 3.3V and that did the trick... not sure why the internal pull-up on the Pi didn't do the same, perhaps I configured it wrong.
UPDATE: That turned out not to be the issue at all. I was neglecting to explicitly set the sensor to free run mode. Part of my code had the unintended side effect of setting that mode so in tweaking things for test sometimes it worked. The pull-up on the Pi works fine.
I checked the sysfs of GPIO, it only supports to configure the direction (in, out), active_level, edge.
I don't see it supports to change mode between GPIO and interrupt. Do any you know it ? Or any suggest.
Example:
Some GPIOs can supports either GPIO or IRQ. So I would like to change mode it under Linux via sysfs.
Thanks in advance.
The GPIO controller (and thus driver) will provide that support if any. In that case GPIO controller is registered as an interrupt controller. There are a lot of examples, like gpio-intel-mid.c where you have:
retval = gpiochip_irqchip_add(&priv->chip,
&intel_mid_irqchip,
irq_base,
handle_simple_irq,
IRQ_TYPE_NONE);
if (retval) {
dev_err(&pdev->dev,
"could not connect irqchip to gpiochip\n");
return retval;
}
I'm working with a Freescale MX6 and a 3.10.31 Freescale modified kernel. I have a Maxim MAX7325 used as an IO expander, which has pushbuttons attached to P0-P2. The interrupt line from the 7325 is attached to the GPIO_3 pad (which I believe is GPIO1_3...)
I set up the 7325 and gpio-keys in the device tree like this:
max7325_reset: max7325-reset {
compatible = "gpio-reset";
reset-gpios = <&gpio5 16 GPIO_ACTIVE_LOW>;
reset-delay-us = <1>;
#reset-cells = <0>;
};
gpio-keys {
compatible = "gpio-keys";
sw2 {
gpios = <&max7325 2 GPIO_ACTIVE_LOW>;
linux,code = <30>; //a
gpio-key,wakeup;
};
};
and
&i2c1 {
clock-frequency = <100000>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c1_2>;
status = "okay";
max7325: gpio#68 {
compatible = "maxim,max7325";
reg = <0x68>;
gpio-controller;
#gpio-cells = <2>;
resets = <&max7325_reset>;
gpios = <&gpio1 3 GPIO_ACTIVE_LOW>;
interrupt-parent = <&gpio1>;
interrupts = <3 2>;
};
};
What appears to happen is when probe for the MAX7325 driver is called, client->dev.platform_data is NULL. Because of this, when max732x_irq_setup is called later, it doesn't set up the chip->gpio_chip.to_irq pointer to point at max732x_gpio_to_irq function (presumably because it doesn't have the right info for this to work.) Later, when gpio_keys
tries to config the first input, it fails when it tries to set up the interrupt and none of the other keys get set up.
gpio-keys gpio-keys.20: Unable to get irq number for GPIO 242, error -6
I did determine using the /sys interface that P0 maps to GPIO 240, so yeah, GPIO 242 is the sw2 GPIO-KEY I was trying to set up.
I'm wondering, does this driver not work with a device tree? I don't see it trying to get any device tree properties, but other IO expander drivers I looked at didn't either, so I thought maybe the I2C core is reading the device tree and supposed to fill in the platform_data from there somehow before it calls the driver's probe function (?)
I'm fairly new at this, so any help would be appreciated. =) I did read a few of the Device Tree docs online, but I'm thinking this is something fairly specific that I'm not doing correctly, which they don't cover... (?)
I do have CONFIG_GPIO_MAX732X_IRQ configured in the kernel... and I did at one point try setting the interrupt-controller property for the max7325 I2c1 node, but I wasn't sure that was needed (?)
MAX732x device tree support
Driver you are using won't work with data from device tree. I have added device tree support to this driver and sent it to kernel mailing lists for review, but they are not merged yet. See this thread (total 4 patches):
You can either apply those patches to your branch or wait for them to get into upstream kernel and then cherry-pick them from there (into your branch).
Bindings documentation (see patches above) shows how to create device tree declaration for MAX732x. In your case it may look like this:
&i2c1 {
expander: max7325#68 {
compatible = "maxim,max7325";
reg = <0x68>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
interrupt-parent = <&gpio1>;
interrupts = <3 2>;
};
};
Another way for you to use this driver (without patches above) is to specify platform data in board file for your board. I believe it should be one of next files:
arch/arm/mach-imx/mach-imx6q.c
arch/arm/mach-imx/mach-imx6sl.c
arch/arm/mach-imx/mach-imx6sx.c
You can find an example how to do so here: arch/arm/mach-pxa/littleton.c, line 394.
But it may be not reliable way: I tried to do so and had some issues with i2c buses numbers (didn't look too much in that way though). It also looks bad to scatter devices' definitions between board file and dts file. So I strongly recommend you to use patches above.
Answers to questions
What appears to happen is when probe for the MAX7325 driver is called, client->dev.platform_data is NULL.
It happens because driver was binded with device declaration from device tree file rather than from board file. In that case driver should use client->dev.of_node instead of client->dev.platform_data. Just see how it's done in my patch above.
You can read more about how binding/matching/instantiating happens in kernel documentation here:
Documentation/i2c/instantiating-devices
Documentation/devicetree/usage-model.txt
I thought maybe the I2C core is reading the device tree and supposed to fill in the platform_data from there somehow before it calls the driver's probe function (?)
No. When binding is happening, client->irq being automatically populated in I2C core (before driver's probe function being called). Properties like gpio_base and irq_base -- you don't need them in case when data came from device tree.
I did at one point try setting the interrupt-controller property for the max7325 I2c1 node, but I wasn't sure that was needed (?)
MAX7325 issues interrupt to your SoC when it detects changes on input lines (more specifically, on open-drain I/O ports configured as inputs).
So if you want your driver to generate separate interrupts for each input I/O line (so that other drivers can consume them), you should specify "interrupt-controller" and "#interrupt-cells" properties. But for this you need all patches mentioned above to be applied.
Patches status
Now all mentioned patches were merged into upstream kernel (v4.0 and later):
gpio: max732x: Add device tree support
gpio: max732x: Rewrite IRQ code to use irq_domain API
gpio: max732x: Fix possible deadlock
gpio: max732x: Add DT binding documentation
Also notice that there are some new patches were made on top of my patches. You can watch them here.