signal levels, or something.. I'm stuck

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Freaks!

I'm a little puzzled and stuck here, maybe someone will throw an idea.

I have a circuit with a mega8L, cs8416 (SPDIF receiver) and AD1955 (DAC). The mega is SPI master, others are slaves. Before I soldered down AD1955, I was able to communicate with CS8416 flawlessly. After I soldered the DAC, I can't..

The problem, it seems, hides somewhere inside of CS8416, which has both I2C and SPI interfaces hogging same lines. The SPI mode is selected by hi-to-low transition on SS line after RESET. The trouble I'm having is that now the SS line (I'm using PORTB pin 0 for CS8416 SS) would not really stay low. It hangs somewhere at 0.5V, which is in my understanding slightly more than allowed for a good 0.

I tried to cut the SS track and it seems that the CS8416 is trying to pull its SS high no matter what. When its RESET is low, it goes low though. Apparently this is how 0.5V is formed when the track is not cut.

It seems that the DAC is not really interfering here: the RESET line is solid, the MOSI is solid.. CS8416 behaves like it has entered I2C mode. This is not really an AVR question because the atmega seems to be working properly and giving straight levels on RESET and SS lines.. It's a general experience question, what could have happened here? Probably it's also worth noting that mega8 and CS8416 are 3.3V and DAC is 5V, but DAC has no SPI MISO connection, it only receives things.

P.S. This time I'm pretty positive that I hadn't shorted any +80V to any input pins like I usually love to do :)
P.P.S. It is also worth noting, and is most puzzling, that once I managed to make the CS8416 work again by some poking around with scope and voltmeter probes. Of course after reset it went insane again.

The Dark Boxes are coming.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It seems that you have a wiring/connection problem...
[just guessing here... from the things you said about poking around with VM&scope.]
Or maybe the CS8416 is damaged and behaves erratically?

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

Last Edited: Mon. Feb 20, 2006 - 10:31 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Could it be the Mega 8 cant sink enough current to drag down to 0V? What is the required sink?

There are only 10 types of people in this world ; those that understand BINARY and those that DON'T!!!!!!!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Slava! AVR mega8 SW related question:
Is your PORTB pin 0 configured as an output, i.e. DDRB.0 = 1; ?

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Stan: Yeah, wiring was my first guess too.. But I checked every track several times, also checked impedances between tracks and tracks with ground/vcc, everything is within reasonable range (ranging 10k to >1M, depending on pin).

@Ducfreak: Well, the !CS pin is not intended to source any current, that's what is worrying me. This is an input and in theory it's ought to be hi-Z. It's not fully dead either because it reacts to reset. Quoting the datasheet:

cs8416 datashit wrote:

AD0/CS pin14
Address Bit 0 (I²C) / Control Port Chip Select (SPI) (Input) - A falling edge on this pin puts the CS8416
into SPI control port mode. With no falling edge, the CS8416 defaults to I²C mode. In I²C mode, AD0 is a
chip address pin. In SPI mode, CS is used to enable the control port interface on the CS8416.

The result is this (as I picture it to myself) - the CS line is not brought hi-to-low, thus CS8416 assumes that it's used as AD0 selection for I2C address mode (in i2c mode it has to be tied to Vcc or GND to select address bit). Other lines behave like I'd expect them to behave in i2c mode too - MOSI is hung at some 1.7V (middle level) (as if it was I2C-SDA), SCK is the only one that seems to be ok, MISO line only shows some crosstalk noise.

Uh oh.. It seems that I have to replace the CS8416. It's not that expensive, but I don't understand the root (tee hee) of the problem and this is bothering me - what guarrantees that the next one will not do the same thing? I'm changing chips like lightbulbs :)

@Stanley again: yes, of course PORTB 0 is output. I even checked that it does what it is supposed to do by cutting the track that goes to CS8416 and inspecting it separately. I have a pretty sophisiticated piece of software here that allows me to do things via a terminal (like dump spi registers, perform slave resets, set register values), so I could check every stage of the reset process in static.

The Dark Boxes are coming.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I'm changing chips like lightbulbs

Hmmm, one of those bad days?!
A good idea is to have some sort of "buffer-circuits" between chips, just to protect the sensitive parts if an unpleasant condition occurs... But I think you already did that! :-)

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
A good idea is to have some sort of "buffer-circuits" between chips, just to protect the sensitive parts if an unpleasant condition occurs... But I think you already did that!

Not really. I only have 22ohm inline resistors for that and to reduce transient noise. It would be an overkill to have buffers for SPI on a small board like that. Besides, who guarrantees that buffers never cause unpleasant conditions? :)

Still wondering what could have happened.. One possibility that comes to my mind is that somehow 5V could have reached the CS8416.. For example, if DAC has some undefined condition during power-on, it could theoretically shoot 5V on SCK line.. Or on its I2S input.. But it's a freaky thought, that would be very evil of it. Besides, most modern circuits are protected against such things.

The Dark Boxes are coming.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Besides, most modern circuits are protected against such things.

Hehe... maybe, maybe not! That's exactly what I told you before! :wink:
You know: better safe than sorry!

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Heh, well, in the world where even lightbulbs can't function properly, what would one expect from a SPDIF receiver chip :)
I'll try to check startup conditions tonight, maybe I'll see some traitor surges.

[Edit] I'm going to get fired soon for reading datasheets at work.. But after reading the datasheet backwards 18th time, I finally noticed that I'm missing a vital pullup on one line. It might have worked when the line was unconnected, but now that very line is attached to a DAC's input and CS8416 could assume that it's pulled low (not sure why low, but it's a possibility). In that case it decides for "hardware control mode" and ignores all software signal checks. On a side note, isn't it clever to use a pullup on I2S (not i2c) Data Out line to decide whether device is going to function in a software or hardware mode? I'd condemn that designer to some exceptionally slow and painful execution. Something like electric chair powered by a handheld dynamo.

The Dark Boxes are coming.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes!! It was the pullup. I'm actually a clever dude :D I've put on pullups on all I2S lines from the beginning, but was not sure about them so I separated them by a solder jumper, which I've had forgotten about. Ok, now it all works. Hooray hooray hooray!

The DAC is still silent, but well, you can't have all at once :D

[Update] Guess what, I have analog audio on output!!! :D

The Dark Boxes are coming.