error trackings

In the previous blog I mentioned the i2c problems when connecting the IO board to the NGW. The TWI lines of the AVR32 stayed at 3.3V so I had to find a workaround for that in the first place. I rebuild the kernel with the GPIO i2c instead of using the atmel twi driver. First it didn't work when simply selecting the GPIO and deselecting the twi in the menuconfig. I had to comment out the GPIO defines in the setup.c file so it was always taken. This must be a small config bug somewhere in the buildroot I use. After that the GPIO was proper recognized and i2c-0 appeared in the dev list. Even more, the device name was the same as the twi driver so any modification on my user space programs were not necessary. This is a good example of portability if you ask me. I checked out the waves on the bus with my scoop and this seems to be as it should be. Happy for sure because I could continue using the NGW to connect to the IO board.

In the meanwhile Manes started to dive into the IO board measurements as you can see on the picture in this blog. First of all he discovered the same voltage drop when connecting his debug AVR (8 bit) master. He disconnected the extender , put on the board for future use , and start running his output test program for the PCA. The 40 leds started to blink at last ! But he also saw that the signal level on SDA was only ca 2V. So his test program for the DA converter failed. He decreased the pull up a bit and the DA converter test was also running fine. I visited Manes one evening and connected the NGW , now with GPIO, to board in order to check if I could also play with the 40 leds on the output. But none of my tests seemed to work. So making use of the linux i2c driver was indeed not the same as the assembler (also bit-banging) test program of Manes. further investigations needed here.

Just one more test to go : the inputs. First try outs of reading a simple pin change and put it onto the output leds failed. Second test with printing the input read outs constantly on the serial console failed with same behaviors. Manes took the initiative to cut the SDA line of the PCA input. And guess what : our signal drop was gone ! Both SCL/SDA had a proper 3.3V. Than the idea that the PCA input was fucked up was more or less clear. After that, he started to run his input tests on the output PCA. Until now he didn't succeed in getting this working. Even with the addition of the repeated start condition. He will investigate this with logic analyzer this afternoon.

The fucked up list until now:

• AVR32 twi lines
• Extender P82B96
• 1 PCA9698

We have to wait now for the results of the logic analyzer. The moment we have a reference level/transition i2c construction for the PCA to work in both read an write will be very important to make decisions for the future of this project. If this indeed is a kind of a special signal, than changes to the default GPIO driver from linux will be indispensable.

Stay tuned for the thrilling moments to come...