NGW meets IO board

The first thing I did was checking the position of the control signals on J5. I changed the configfs mask and output accordingly. I also added two lines to the script to accomplish the reset for the audio codec and pca. And than the moment arrived to switch on the power of both boards and let the linux kernel boot up. Ok so far so good power led lights up and off we go...

I noticed already in the boot sequence that the audio codec was still not recognized as an ALSA device. This could be due the fact the reset executes after the loading of the kernel module. So I tried with a warm NGW reboot after reset still the same. This means that testing the sound was not possible because I didn't have a DSP in the device list present. Still not sure if the message printed by the audio driver was applicable on the AC97 I posted a question on the freaks forum.

I let the AC97 behind I started to the focus on the I2C communication. I adapted the C program with the proper address of the output PCA. I first tried with a simple write of 6 bytes 1 control and 5 outputs hoping the acks where properly formed. This was not a success. The second thing I tried was sending them using the I2C message struct, which normally takes care of the acks in between before sending a stop condition. Still no success. Last thing I could do was taking back the I2C bus scan routine and see if the board controller was still connected. This test was terrible all 128 address tests failed in giving me the "connection time out" as an error message. If I cut all the flat cables to the IO board the test performed as it should be. At this point 4.7K resistors were used as pull up defaults from NGW. I tried in putting 3.3K in parallel on the IO board because the specification of the PCA recommends even 1.6K pull up. Still no success. After some initial checks on the PCB layout Manes discovered that the RESETs of the PCAs were not connected to the flat cable. So the second wire patch was a fact. Again restart with all tests still the same. Sounds like it had something todo with board itself and it was a good moment to start thinking on scoop measurements. The signal on both SCL and SDA were terribly bad, when the IO board was connected to NGW. I'm talking here of signal droppings from 3.3V to 1V. Of course this was the reason of the malfunction here. The I2C bus was to heavily loaded for the NGW open drain output.

The twi output of the NGW stops after a few seconds when testing a write in loop. The output remains static on SCL ca 0V and SDA ca 1V. And now it's even doing nothing anymore its just stays on 3.3V. It's obvious that these two outputs are broken. It's a pity that on evaluations like NGW apparently nothing is foreseen to protect or buffer the IOs. It was also unexpectedly because the proof of concept with a single PCF worked well. But if the amount of connected twi devices rises the charge on the bus will do the same and modern micro controllers like AVR32 and ARM9 are not that well protected against these loads.

Probably introducing a I2C extender or signal converter (3.3 -> 5V) solves issues like that. But that I can't prove at the moment I’m afraid. As my SDA/SCL is fucked up I must find a workaround. If I can't find it the NGW board will be of no use anymore and can be trashed. The linux is still booting so I think it's only these two outputs that are bad. Buying a new one is of course the only solution if I want to continue using the atmel dedicated twi. If I can go by the GPIO driver (no atmel twi but bit-banging) and switch to some other gpio pin numbers on the connector than there' s a bit of hope left. But the reason of malfunction must still be proved. So a test with extender/converter will be indispensable. A converter is preferred over an extender when a IO board revision will be made because lack of space on the NGW to mount extender.

I'm very disappointed. Maybe Manes could avoid things like that in considering worst-case situations. On the other side it still remains a low cost development kit of less than 100€. Now more and more the question gains presence in my mind:

"Is this a good solution to serve as a 24/7 application in situations where an influence like electrical disturbance is present?"

I still have some hope though.