AOUT NG J1 Connection Confusion

[TK.]

Thanks for the input!

Alright, I switched the #define AOUT_SPI_OUTPUTS_OD 0 setting (it was in \modules\aout\aout.h)

Just for the records: In aout.h you will find a "#ifndef AOUT_SPI_OUTPUTS_OD" statement, which allows you to overrule the default setting in mios32_config.h

Thats the reason why I proposed to add it there. Biggest advantage: if I ever update the aout.h file, you don't need to merge your local modifications.

status |= MIOS32_SPI_TransferByte(AOUT_SPI, 0x8 << 4);

Thats an error, I removed the "status |="

This is the voltage of every pin on the TLV5630 after sending the 64000:

It still looks like words which are sent to the device are shifted by one bit.

But now we know that the voltage range is very likely not the problem.

Could you please do another experiment: try different SPI transfer modes:

Replace:

    status |= MIOS32_SPI_TransferModeInit(AOUT_SPI, MIOS32_SPI_MODE_CLK0_PHASE0, MIOS32_SPI_PRESCALER_4);

[/code]




by:



1)

[code]

    status |= MIOS32_SPI_TransferModeInit(AOUT_SPI, MIOS32_SPI_MODE_CLK0_PHASE1, MIOS32_SPI_PRESCALER_4);

2)

    status |= MIOS32_SPI_TransferModeInit(AOUT_SPI, MIOS32_SPI_MODE_CLK1_PHASE0, MIOS32_SPI_PRESCALER_4);

[/code]




3)

[code]

    status |= MIOS32_SPI_TransferModeInit(AOUT_SPI, MIOS32_SPI_MODE_CLK1_PHASE1, MIOS32_SPI_PRESCALER_4);

And check if any mode sets the VREF output (pin #16) to 2.05V

Some of these transfer modes don't make sense, the intention of this experiment is to get a better understanding in which direction we have to continue the analysis.

Best Regards, Thorsten.

[greevous]

Ok, I will try these in an hour or so (having breakfast) and report back!

[greevous]

I reset J26 back to 5v and put #define AOUT_SPI_OUTPUTS_OD 1 back in (went back to the original code).

status |= MIOS32_SPI_TransferModeInit(AOUT_SPI, MIOS32_SPI_MODE_CLK0_PHASE1, MIOS32_SPI_PRESCALER_4);

pin 16 = 1.05v

status |= MIOS32_SPI_TransferModeInit(AOUT_SPI, MIOS32_SPI_MODE_CLK1_PHASE0, MIOS32_SPI_PRESCALER_4);

pin 16 = 1.05v

status |= MIOS32_SPI_TransferModeInit(AOUT_SPI, MIOS32_SPI_MODE_CLK1_PHASE1, MIOS32_SPI_PRESCALER_4);

pin 16 = 1.05v

...doesn't seem to make any difference in pin 16.

[TK.]

I did the same checks and can confirm, that all modes lead to the same effect (the phases are relevant once serial data is read).

To summarize:

• channel 0..2 are not working at all. If we would have a bitshifting problem, I would expect that channel 4 would show the same effect
  
• channel 3..8 output a voltage which is much higher than REF - I would expect a value between 0V and the reference voltage /edit: range between 0..2*REF ok
  
• the REF voltage is lower than expected
  
• it seems that the serial transfers are working, because some outputs are changing their value, but not within the 0...REF range
  

My current assumption: the DAC output pins are (or were) short-circuited.

It can't be excluded that this fried the chip (partly), but it makes sense to continue the analysis.

Which values do you measure on the DAC output pins if all jumpers and OP amps are removed?

Best Regards, Thorsten.

[greevous]

Ok, all jumpers and op amps pulled:

pin #1: 0.00v

pin #2: 0.49v

pin #3: 0.32v

pin #4: 2.97v

pin #5: 5.41v

pin #6: 2.22v

pin #7: 2.22v

pin #8: 2.22v

pin #9: 2.21v

pin#10: 0.00v

pin#11: 5.41v

pin#12: 0.01v

pin#13: 0.01v

pin#14: 0.02v

pin#15: 2.09v

pin#16: 1.13v

pin#17: 5.41v

pin#18: 0.00v

pin#19: 0.49v

pin#20: 5.41v

[greevous]

It looks like in the datasheet for the TLV5630 that the output channels range from 0 to 2X REF, so I guess the 5 channels that are running are working as expected (REF = 1.13v and they're putting out around 2.22v when sent 64000 == 4000 in 12bits).

The issue seems to be that the REF (pin 16) is stuck at 1.13v and we can't get it to take the CTRL0 command to use an internal reference of 2v, which is what the following should produce, correct?

// 00001000 << 4 == 1000XXXX (CTRL0 address)

MIOS32_SPI_TransferByte(AOUT_SPI, 0x8 << 4);

// 00000001 << 3 | 00000011 << 1 = 00001000 | 00000110 = XXX01110 (DOUT Enable + Ref Set to 2v Internal)

MIOS32_SPI_TransferByte(AOUT_SPI, ctrl0);

Maybe replace C10? The schematic shows it should be 100nf. I'll see if I've got another one. I really need to get that REF up to 2v so that 2X2 gets me to 4v output, which in turn could get stretched to approx. 10v by the op amps. I don't need all 8 channels, 5 would be ok, but I gotta get up to 10v on the outputs. Maybe I'll replace C10 and see what happens. Alternatively I could buy another TLV5630, but I'm not sure how to get the old one off the board. I'm disappointed that I apparently fried the DAC somehow.

Maybe we need an AOUT LC with a multi-channel S&H IC? Oh well, I'll replace the cap and see what happens.

[TK.]

It looks like in the datasheet for the TLV5630 that the output channels range from 0 to 2X REF, so I guess the 5 channels that are running are working as expected (REF = 1.13v and they're putting out around 2.22v when sent 64000 == 4000 in 12bits).

You are right, I forgot this detail.

I checked the voltages on the output channels of my TLV5630 and can confirm that they range from 0..4V

The issue seems to be that the REF (pin 16) is stuck at 1.13v and we can't get it to take the CTRL0 command to use an internal reference of 2v, which is what the following should produce, correct?

// 00001000 << 4 == 1000XXXX (CTRL0 address)

MIOS32_SPI_TransferByte(AOUT_SPI, 0x8 << 4);

// 00000001 << 3 | 00000011 << 1 = 00001000 | 00000110 = XXX01110 (DOUT Enable + Ref Set to 2v Internal)

MIOS32_SPI_TransferByte(AOUT_SPI, ctrl0);

yes, correct.

Maybe replace C10? The schematic shows it should be 100nf. I'll see if I've got another one. I really need to get that REF up to 2v so that 2X2 gets me to 4v output, which in turn could get stretched to approx. 10v by the op amps. I don't need all 8 channels, 5 would be ok, but I gotta get up to 10v on the outputs. Maybe I'll replace C10 and see what happens.

You could also check what happens if C10 is removed - does this increase the voltage?

Alternatively I could buy another TLV5630, but I'm not sure how to get the old one off the board. I'm disappointed that I apparently fried the DAC somehow.

Desoldering is easy if you use solder wick: http://www.ehow.com/video_4435740_use-solder-wick-remove-solder.html

Best Regards, Thorsten.

[greevous]

Well, for the record, I removed C10 and let the REF pin float and tried running again. It did not work -- everything was the same.

So, I ordered a new TLV5630IDW. Any advice on how to install it without frying it again? Do I need some kind of special heat sink to keep the solder pen's heat out of the chip? I don't know if I fried it with heat, fried it with static electricity, or fried it with a short circuit, but my guess would be heat.

Oh, also, for the record, after I decided to order a new DAC, I changed the CTRL0 control byte in aout.c so that it was switched to external reference (making the REF pin an input pin), and connected it to +5v (the data sheet says you can drive it all the way to AVdd, which is what I did). For the five working channels, it did indeed push them up to around 4.6v (AVdd-0.4, just like the datasheet says), which allowed me to use the op amps to push the outputs close to 10v. However, the first three channels still didn't work. I put the outputs on a scope, and noticed they were oscillating a bit (more as the voltage got close to max). So, presumably I'd need to add a cap to the REF line and ground it or something to get rid of the oscillation. However, running in that configuration, the DAC became warm to the touch (not hot, but uncomfortably warm) after a few minutes, so I decided this hack wasn't worth using. I'll just put a new DAC in, but I did want to document for posterity that external referencing does appear to work.

Since I'm replacing the DAC anyway, and need to wait for it to arrive, I may throw a cap on the reference line just to see if I can get rid of the oscillation in the output channels (maybe the oscillation was the cause of the heat, not sure). That way people would know that this is a viable configuration if they chose to do it.

[TK.]

Thank you, this is very useful input!

I never tried to supply the REF voltage from external, it's good to know that it works.

So, I ordered a new TLV5630IDW. Any advice on how to install it without frying it again? Do I need some kind of special heat sink to keep the solder pen's heat out of the chip? I don't know if I fried it with heat, fried it with static electricity, or fried it with a short circuit, but my guess would be heat.

Usually I don't take care so much about the temperature, but it shouldn't be higher than 350°C

Much more important is, that you only tip some solder on the pins for a very short moment - not longer than one second!

If the pin isn't properly soldered thereafter, tip again for another second.

This is save enough.

Since I'm replacing the DAC anyway, and need to wait for it to arrive, I may throw a cap on the reference line just to see if I can get rid of the oscillation in the output channels (maybe the oscillation was the cause of the heat, not sure). That way people would know that this is a viable configuration if they chose to do it.

The REF voltage has to be *very* stable, and it shouldn't be affected by noise. Usually an external shunt or a small VR is used - the TLV5630 has an internal reference source to save these costs. So, this is only a workaround for the case that the internal voltage source has been fried somehow, but it will result into additional hardware.

Best Regards, Thorsten.

[greevous]

FYI, I got my new TLV5630 (I got two of them for $7 each [5 euros] on ebay!)

I installed it, and at first I was disappointed because I wasn't getting anything out of the DAC outputs, but I switched to the 3.3v mode, removed the R32 resistor network, and moved the J26 jumper to 3.3v, and everything started working as expected!

So, probably I can't drive at 5v because of the crappy cables I'm using (Where can I get cheap headers, sockets, and ribbon cable? I'd like to make all this stuff nice and professional.)

I'm so happy now. I can now move forward with building my minimoog keyboard emulator!

Thanks TK for helping me debug the original problem (bad TLV5630).