No Ecu Found Vag Eeprom
Prisc Chandola
@el_supremo: Now, Suddenly without any change from my side, the I2C scanner started to found device at all addresses it scans, what does that means?
Still no luck with getting the right values from the EEPROM chip, everything is 255. (after write).
Of-course all this with 4k7 resistors.
It looks like you are jamming two or more pins into one hole in the breadboard. In IMG_0721 it even looks like you have the red wire, an IC pin and two resistor leads all jammed into the same breadboard hole. That's not a good way to hook them up. It also looks like the two pieces of breadboard are too far apart and you've had to spread the IC pins to make them fit. They may not be making proper contact. Get a complete breadboard and wire the thing up with one lead per hole.
I did the multipin per hole to make sure that the connection is strong and stable.
The red wire is 5V, the blue is SDA, purple is SCL, green is GND.
I didn't changed anything to the IC pins of the chip in order to make them fit, its simply 2 parts of a breadboard, which i had to cut since i had to put it inside a small package.
@el_supremo, I've put it on complete breadboard, and no luck...
Again, lets start with the simple issue for now, the I2C scanner found devices at any address it checks.
How that can be? Why?
If i remove the resistors its not found anything...
Of course again, the data from the chip is wrong...
I'm simply using the extEEPROM library for read/write from/to the chip.
I've also tried few other examples I've found on the web using the Wire library directly. Same results.
Maybe the one found device is the WiFi101 chip, since its built-in on my board i cannot remove it and check ...
I've anyway have 3 MKR1000 boards which same as Zero and I've got the same results on all of them.
Finding zero devices is a clue that something is not wired up properly. Finding 112 devices is something else entirely and at the moment I can't think what could make it detect that many phantom devices.
I doubt that the 0x60 address, when the chip is disconnected, is the WIFI101 because that uses SPI. Unless it also has an I2C EEPROM on it, but those are usually addresses 0x50, 0x51, ... 0x57.
I believe that you are seeing the presence of all the registers in the EEPROM when you scan for the addresses. If you change the scanner to look for 0 to 127 I think you will find a few more "addresses".
OK, Pete and cattle dog, both of you helped me a lot!!!
Now i've understood my mistake about the chip itself.
It's totally different than the typical EEPROMs in the market, its very small (bytes vs bits), and work in a different method of addressing in the I2C bus.
It is saying that the EEPROM.h can not be found. But if i select a UNO board and compile the same code it compiles with no problem. Still new of new to the whole M0 board. Can someone please help me out?
The EEPROM library is architecture specific. For that reason, each hardware package will bundle its own version of the library. The libraries folder in a hardware package is only in the include path when compiling for a board of that package, or one that references it.
A convenient way to store data into Flash memory on the ATSAMD21 and ATSAMD51 processor family - GitHub - cmaglie/FlashStorage: A convenient way to store data into Flash memory on the ATSAMD21 and ...
Hello I'm trying to read a External eeprom chip for it's address. It is a 24c02w6 chip that is a on a Dell PCB used for a Raid key. I'm not trying to copy whatever is on it. I'm trying to see If i can reuse it for other things. It has a 2k eeprom. I thought it would be good for something. Below is the Results of what the i2c scanner came up with. and Also images of the device. I have no other device on the i2c or attached to my arduino. Can someone help me to figure this out please?
Hello John, From What I read on the site The pinout is Pin 1 is Vcc; pins 7 and 9 are ground. Pin 4 is Scl and Pin 8 is SDA They said. This Is the only thing I can find online. And they did a great job tracking down the pins with all the resisters ands capacitors on it. As far as the enable pin. Noting on it. I need to see that myself because There is no marking to indicate whick is pin one.
Hi @josephchrzempiec
To use an I2C BUS you need it to have pullup resistors.
FFrom what I see by the schematic shown that the board does not have these resistors, so it will be necessary to put the SDL and SCA.
Try 4K7 resistors.
The Arduino have internal pull-up resistors.
Well. Uno, Leonardo, Micro, Pro Micro, Mega, Zero and the SDA0 on the Due all have pull-up resistors. Only the SDA1 on the Due do not.
And this is more apparent that the SDA1 on the Due use I think the "wire1" library
I had tried to find a datasheet for it but couldn't find one. You would want one to know the expected behavior (e.g. what commands you need to send to read info, in what format, and what command is needed to write to the chip and stuff. Perhaps the chip is dead, for some reason. Like a power surge or something that took it out.
Hi @cdr_xavier @josephchrzempiec
The values of the internal pull-up resistors are too high and therefore not within the I2C protocol recommendation.
Read :
"The value of Arduino (ATmega328P) internal pull-up resistors.
The inbuilt pull-up resistors on the Arduino/AVR outputs aren't well defined. When these are used, the exact value rarely matters - the datasheet gives a pretty wide range: 20kOhm-50kOhm.
There is a discussion on the official Arduino forum here, with a pull-up measured as R=30.9K from an effective voltage of 4.58V (which is different to the supply voltage). In short I measured the value on one chip as 34k from 4.6V, it will vary from chip to chip and even with temperature."
I had an issue with a a feeder. I was able to isolate it to a RadarBox1090 stick. I pulled that stick and was running 978 only using the:
sudo systemctl disable dump1090-fa
sudo systemctl disable piaware
Thanks for the help. A buddy knows how to flash eeprom chips. I have a good one from RadarBox that can be used. The problem is that both SDRs that came off of the same Pi Zero 2 W. Which makes me think something on that unit is corrupting the SDRs.
Yes, I can read/write the eeprom file with data, and when I do either the bind or manual setup through new_device, dmesg will show a message from the at24 driver showing that the device is bound correctly.
So I believe it was added somehow. Can you please test this overlay? Remember to activate only this overlay, so we can remove other conflicts that might be happening. You can check the overlays.txt file.
With the utility I am now able to program the EEPROM (once). But is there a way to reprogram it? Now that I have set 55h at 00h to load settings from the EEPROM, the programming utility can no longer find the EEPROM.
Do you have a sample EEPROM load for the TUSB4041? I seem to be bricking devices with my latest settings (instructions above no longer work - device manager code 10, device cannot start) and haven't been able to get working communication with the 4041 with EEEPROM attached.
I am sometimes able to enter programming mode - on a blank eeprom, or on a programmed eeprom with my initial settings, but not with a programmed eeprom on my latest couple of settings attempts.
The feature I am particularly interested in enabling is HS_UP (at F0). But I am assuming I need to set reasonable values over the entire memory space (00 to FF).
When I program, I am able to read back, so it is programming successfully.
Not sure if I am exiting programming mode correctly. As I understand it setting 55 at 00 should cause the device to exit programming mode on reboot.
I am getting to the point where Windows installs the generic USB driver for the device, but is unable to connect to it.
A "brief" forewarning: running EEPROM updates can include risks all the way to bricking your Raspberry Pi 4B, therefor I must emphasize that trying out anything mentioned in this reply is DOING SO AT YOUR OWN RISK. ALWAYS MAKE A BACKUP COPY OF YOUR EXISTING SYSTEM BEFORE ATTEMPTING AN EEPROM FLASH UPDATE. Especially a copy of the boot partition, which is quite easy (and small in file size) to backup to another computer by simply copying all files and directories that are inside the boot partition.
It is more than recommended that you backup the entire OS by creating an image clone of it - that is, with all partitions and their files etc. included), and then store them on a separate drive for safekeeping and reverting the process, should anything during update go wrong.
As for now (August 2020), the rpi-eeprom-update script that you can download from i.e. GitHub ( see: -eeprom ) is more or less broken on other distros apart from Raspbian/Raspberry OS (where it is supposed to be either pre-installed, or can be installed with sudo apt install rpi-eeprom-update without any extra hassle). This means that it might be risky to try to run the EEPROM updater from any other OS than the official Raspbian/Raspberry Pi OS's.
Since it's an EEPROM flash update , you should be able to use any installation you've had for Raspbian on the RPi4B -- as long as it's thoroughly updated first! Or, get a separate MicroSD card / USB boot stick for that purpose.
When booted into Ubuntu, check the status of your firmware with sudo rpi-eeprom-update (with no command line options after that -- and, assuming you have it installed or available on the Ubuntu side nonetheless, if not, see below.)
sudo rpi-eeprom-update (with no added commands) should just list the version details and notify if an update is available that the script can see -- see if the output from that command matches the correct EEPROM firmware version you are trying to install.
If the firmware version doesn't match, or if you don't have the rpi-eeprom-update at all on your Ubuntu -- which wouldn't be a surprise, since Ubuntu for the RPi4B does not come with the rpi-eeprom-update pre-installed, nor can it be installed via apt or any PPA's that I know of as of writing this.
4a15465005