I have a problem with the i2c/SMBus on a Linux System with an Intel Apollo Lake processor. I am trying to read/write from/to an EEPROM but I face some issues. My EEPROM is located at the address 0x56, and I am able to watch the Bus with my Logic Analyzer.
When I try to read from the device via i2ctools (i2cget) the System behaves as expected. My issue occurs when I try to perform a write command via i2cset for example. i2cset ends with an error (Write failed). Because I am able to watch the Bus electrically I can also say that all lines stay HIGH and the Bus is not touched. I was able to activate the dev_dbg() functions in the i2c driver i2c_i801 and when I perform i2cset I am able to find (dmesg) the debug message:
[ 765.095591] [2753] i2c_i801:i801_check_post:433: i801_smbus 0000:00:1f.1: No response
When running my minimal I²C Python code using the smbus2 lib, I get the following error message and the above mentioned debug message:
from smbus2 import SMBus
bus = SMBus(0)
b = bus.read_byte_data(86,10) #<- This is performed
b = bus.write_byte_data(86,10,12) #<- This is not performed
bus.close()
Error:
File "usr/local/lib/python3.8/dist-packagers/smbus2-0.4.0-py3.8.egg/smbus/smbus2.py", line 455, in write_byte_data
ioctl(self.fd, I2C_SMBUS, msg)
OSERROR: [Errno 6] No such device or adress
A big hint for me is that I am not able to perform a write command in the address space form 0x50 to 0x57. My guess is that some driver locks the address space to prevent write command to that "dangerous" area.
My question is: "Does anyone know this kind of behavior and is there a solution so that I can write to my EEPROM at address 0x56? OR Is there a lock surrounding the i2c adress space from 0x50 to 0x57 and who is my opponent?"
I am kind of a newbie to the whole driver and kernel world so please be kind and it is quite possible that I made a beginner mistake.
I would appreciate hints and tips I can look after surrounding my problem.
It seems that I found the cause of my problem. In this Forum post is described that Intel changed a configuration Bit at the SMBus controller.
OK, I know what's going on.
Starting with the 8-Series/C220 chipsets, Intel introduced a new
configuration bit for the SMBus controller in register HOSTC (PCI
D31:F3 Address Offset 40h):
Bit 4 SPD Write Disable - R/WO.
0 = SPD write enabled.
1 = SPD write disabled. Writes to SMBus addresses 50h - 57h are
disabled.
This badly documented change in the configuration explains the issues.
One Challenge is, that to apply and enable changes to the SPD-write Bit the System needs to be rebooted. Unfortunately while rebooting the BIOS will change the Bit back to the default. The only solution seems to be an adaption in the BIOS.
For me, this issue is resolved. I just wanted to share this information in case someone faces the same issues.
Related
Hi, I'm trying to read NVMe sensors using NVMeSensor from dbus-sensors. I have configured for 4 Nvmes in my *.json file of entity-manager (EM) config and it logged "Sensor x error reading" for all. I put the config in the common EM config for the board together with Fan sensors, ADCsensors and others, refering this (https://github.com/ibm-openbmc/entity-manager/blob/14a7bc9303d747dbc20cb702083e7af0a3cf0496/configurations/NVME%20P4000.json#L10-L41). In this case, I see that boost::asio::async_read at https://github.com/openbmc/dbus-sensors/blob/ce6bcdfc28f60173093087050a43adbc586fd6fa/src/NVMeBasicContext.cpp#L290 returns the response of size 0. But the resp from https://github.com/openbmc/dbus-sensors/blob/ce6bcdfc28f60173093087050a43adbc586fd6fa/src/NVMeBasicContext.cpp#L83 has size of 6 and valid value.
Howerver, when I config only 1 nvme in EM, it returns value normally on dbus.
I wonder if NVMeSensor only support nvme with a fru and we have to have a single json file for each just like NVMEP4000.json.
What should I do when I want to config all the nvme inside the EM config of the board?. Since I can't find any reference.
I have not found the meaning of "Address" in NVME1000 config since it will use 0x6a anyway, at least to what I have seen. Can you tell me what is it for?
I'm really new to OpenBMC and don't get much of the mechanism of the code, please help to remedy my understanding if it's not correct. Any advice from you will be appreciated a lot.
Thank you.
Edited
I realize that when 1 of the NVME is not present, all of them will fails. I think the failed one affects the stream for reading or the response stream (respStream) although each nvme has a separate request stream (reqStream). I don't know why they interfere each other, but I see that when the resp size from smbus is < 0, they still write them to the stream without resizing the resp vector like when the size is normal, I add the resp.resize(len) here (https://github.com/openbmc/dbus-sensors/blob/ce6bcdfc28f60173093087050a43adbc586fd6fa/src/NVMeBasicContext.cpp#L153), it works, and we can do hot plug. Is that because I did not use FRU probe for the NVMEs....?
I wonder if NVMeSensor only support nvme with a fru and we have to have a single json file for each just like NVMEP4000.json.
The "Probe" field in entity-manager configuration json is used for probe rules for the device. FRU is just one way. For example, if you know the exact i2c bus and address, you can use something like
xyz.openbmc_project.Inventory.Decorator.I2CDevice({'Bus': 4, 'Address': 60})
^ ^ ^
DBus Interface | Value
Property
And "Probe" can be an array with AND OR operators. Like this example.
What should I do when I want to config all the nvme inside the EM config of the board?.
I think adding all 4 NVME1000 blocks to your board json will do this, as long as they have different names and bus-address configuration.
I have not found the meaning of "Address" in NVME1000 config since it will use 0x6a anyway, at least to what I have seen. Can you tell me what is it for?
On Intel P4000 series SSDs, 0x53 (What in nvme_p4000.json) is the 7bit address of the FRU eeprom, while 0x6a is the 7bit address for NVM Express Basic Management Command (Appendix A of NVMe-MI 1.2b Specification). These addresses are only documented in the product spec that not generally available :(
Putting all nvme configs inside the baseboard EM config is OK. There are hotplug issues with dbus-sensors nvmesensor, so when one of my configured nvme is not present, all the others will fail. I only plugged 1 nvme to one of the 4 slots so it causes the problem. I was told they are checking on this, but I'm doing the trick I put in the Edit section of my question.
They hardcode 0x6A for i2c address in nvmesensor code, the reason is as #KagurazakaKotori said.
Let me start off with the components used:
GPIO extension board to connect the raspberry pi to components
Bme280
Pi 3B
Problem description:
This problem was intermittent at first. We were receiving reading and the error occured out of nowhere, made adjustment to the sensor(taking out and putting it back in) which solved it but when we touch the sensor the error showed up again.
We decided to change the sensor and the problem turned from intermittent to persistent. Now we have this as permanent issue.
We removed the package for BME280 and SmBus2 and decided to reinstall it again.
RPI Bme280: https://pypi.org/project/RPi.bme280/
I followed this BME280 installation guide, however when prompting for 'i2cdetect -y 1' there were lines but no number showing up.
What has been confirmed so far:
Patching up of circuits was fine, tested with my lecturer pi and it
works fine.
Codes is fine, we even use the sample code provided by RPi.bme280
I2c was enabled everytime
Please help me because I am really lost. I needa submit this by next week so any help is appreciated.
Problem pic --> Picture of the problem
I've tried to respond, but there is a few pitfalls in SMBus and i2c, so to break the question into smaller bits I've quoted your original message with an indent. The response is provided beneath.
This problem was intermittent at first. We were receiving reading and the error occurred out of nowhere, made adjustment to the sensor(taking out and putting it back in) which solved it but when we touch the sensor the error showed up again.
I locked onto the statement, "Touched the sensor". Is there a chance the BME280 experienced an ESD discharge? And therefore is now partially or fully broken?
Are you using an ESD safe room? or at least ESD bracelet. You will not notice small ESD discharges, and for small electronics even a sub 1000V discharge can cause damage instantly or over time. (Fundamentals of Electrostatic Discarge - incompliancemag.com)
I followed this BME280 installation guide, however when prompting for 'i2cdetect -y 1' there were lines but no number showing up.
The I2Cdetect -y 1
Will send a ReadBit message to each possible slave 0-127. Then listens for the ACK on the slave address.
The message is very simple, but does the trick for detecting working i2c slaves.
As you stated there is no "Lines", i would suggest the slave either has issues responding, if the BME280 has the correct 3v3+GND supplied.
As another possability, could you redo this step dtparam=i2c_arm=on,i2c_baudrate=400000
(Set the baudrate way down to 10000 /10k. Should this solve the issue and you need higher bandwidth, attempt on "50000 /50k" or "100000 /100k") This is just to eliminate the possibility the slave cannot opperate on this high frequency. 400k Baudrate for SMBus is high for a prototype/testing scenario. Very small amounts of interference can corrupt the data over SDA.
Another possibility is the Sink-Current which i've learned the hard way is not the same on i2c and SMBus over i2c.
Is you Pull-up resistor appropriate for the limited sink-current?
The SMBus specifies a minimum sink current of 100µA, and a maximum of 350µA, compared to 3mA for the I²C bus (Ampere=Voltage/Resistance Ohm).
Now to the Software issue.
From your supplied picture on imgur.
File "newcodes_''''''''''''''.py" line 2, in
Your compiler cannot find "bme" where you attempt to import bme280. Reference/path issue?
This can be the cause for other issues further into the code calls.
I don't know what SW you are writing the code in, but if there is an option to insert a breakpoint and run a debug build. I would suggest starting there :)
Alright I have resolved the issue, I changed the wire from jumper wire to hard wire. Thank you guys for your response. I appreciate all of them :D
Maybe I am asking the wrong question actually but I am just making my first steps in the embedded world. So I am sorry if the question is somehow stupid.
I am trying to program a software for 9DOF IMU in c++ and linux environment.
As far as I understood the SPI, the SS pin has to be low active in order for a transmission to occur. I have seen multiple reading or writing bytes function examples and all using the struct spi_ioc_transfer but they were all single slave examples and there is no mention about setting or configuring the SS in the code. Also When I check the structre of spi_ioc_transfer there is the cs_change however, how does it know which cs we are dealing with from the beginning ?
The chip select (CS or SS) to use is determined by which device node you open.
To talk to a SPI chip with the Linux spidev driver, you open a device such as /dev/spidev0.1. The numbers in the device node file name refer to the bus and chip select, respectively — in this example it would be the first bus (0) and the second CS (1). If you want to talk to devices on different chip-selects, you have to open different device nodes and do ioctls on the appropriate one.
I am using the instructions of https://pimylifeup.com/raspberry-pi-rfid-rc522/ to learn how to read my rfid-rc522.
I installed all the things needed, and cloned from git all the files. I connected accordingly and double checked the wire.
The code in Write.py is
#!/usr/bin/env python
import RPi.GPIO as GPIO
import SimpleMFRC522
reader = SimpleMFRC522.SimpleMFRC522()
try:
text = raw_input('New data:')
print("Now place your tag to write")
reader.write(text)
print("Written")
finally:
GPIO.cleanup()
When I run it- The result stops after "Now place your tag to write" and nothing happens when I place my tag. Any help please? What's wrong here? The module gives red light meaning it is connected. Is it really connected? How do I know? Please help.
Edit: My title and tags were wrong in this question due to already saved data. I edited. :)
It can be multiple reasons why your reader is not retrieving any data:
The RFID cards that you are providing to the reader are not supported by the ISO 14443: Mifare Classic, 4K. (Some DesFire, etc...) are the cards you want to try. Source: https://en.wikipedia.org/wiki/ISO/IEC_14443
The MFRC522 is not receiving enough input voltage. Try to increase from 3.3V to 4V. I have tried with 5V months and the reader is still running perfectly, but be cautious. The safe range in NXP is from 2.5V to 3.6V. Source: https://www.nxp.com/docs/en/data-sheet/MFRC522.pdf
The library you are using does not support IRQ (Interruption Request). This means the process of reading UIDs is high CPU consuming and low in performance. Try to use this popular library which supports interruptions: https://github.com/ondryaso/pi-rc522 . You will need to connect another wire from the IRQ pin in the MFRC522 to one GPIO pin in the Raspberry that is free and supports reading/writing operations.
Check if SPI interfaces are enable in Raspbian. Open a terminal and run:
ls -l /dev/spi
Lastly, it could be that your reader is broken. Some chinese versions do not work as they should do. Maybe you should buy another one and try more luck.
I suppose you have connected all cables in the correct way between the MFRC522 and the Raspberry Pi. Check that again.
I'm using linux kernel 3.3 (I cannot upgrade my kernel, sorry!) and am trying to use the wpa_cli utility to monitor the status of my WiFi connection. I'm using an Edimax WiFi dongle to connect to a wireless access point.
I expect to see something like this:
# wpa_cli status
Selected interface 'wlan0'
wpa_state=SCANNING
ip_address=XXX.XXX.XXX.XXX
address=XX:XX:XX:XX:XX:XX
Or the same thing but with wpa_state=COMPLETED, depending upon my connection status.
Parsing the this text output allows me to see if my wireless connection is active or scanning. However, I have noticed that after powering off my access point wpa_state=COMPLETED is still being returned. Using the command:
# iwlist wlan0 scanning
Forces a scan and wpa_state will occasionally be correct, but usually (99%) not.
Here is my /etc/wpa_supplicant.conf:
ctrl_interface=/var/run/wpa_supplicant
ap_scan=1
country=US
network={
ssid="myssid"
psk="mypsk"
key_mgmt=WPA-PSK
eap=
}
After some investigation, I believe something weird is happening causing the kernel to return a cached version of the AP list. I am using the RTL8192cu driver. I've already looked at this issue, and it is not the same as mine.
My belief is that the issue may be somewhere in the kernel. In the file net/mac80211/scan.c, at line 214 in function ieee80211_scan_rx, I see a bssid from the BSS of my AP appear (when AP has power) and get put via ieee80211_rx_bss_put (here). At this point, it is returned in scan results and wpa_supplicant causes the MLME layer in the kernel to authenticate and connect with that AP. However, after disconnecting AP power, I never see the MLME layer relinquish it's atomic_t hold on that BSS. This causes the BSS to never to unlinked in the function
cfg80211_bss_expire at the end of a scan (cfg80211_wext_giwscan), in file net/wireless/scan.c, line 205 (here).
Specifically, I would like to know why the atomic used to "hold" a BSS is not decremented on power removal from the AP - causing linux to miss sufficient beacons for a disconnect? Or, is there some configuration with wpa_supplicant I need to add to have the MLME kernel layer decrement it's hold on the BSS, or is this clearly a kernel bug?
I've already tried:
# wpa_cli bss_expire_age 10
# wpa_cli bss_expire_count 2
and have not resolved my issue.
So after a lot of digging, I found that the issue was because of the kernel's rtlwifi driver. To me, it looks like the rtl8192cu driver was suppose to be responsible for handling missed beacons, by calling the function ieee80211_beacon_loss, but that call is nowhere to be found. I removed support for IEEE80211_HW_BEACON_FILTER in the rtlwifi driver and the issue has been fixed.
This patch is essentially the same changes that I made, and the comments in this file are part of what led to me this answer.