The issue with A1 being high instead of low is interesting, as you also have SRC4392 NRST on the same upper 4 bits of the ATMEL's GPIO port which is shared with the JTAG connector.
Have you infact confirmed that A1 and SRC4392 NRST are being electrically pulled low? If this GPIO port is somehow miss-configured (as the upper 4bit nibble of this GPIO is shared function with the JTAG port - and you also have ADC analogue inputs), it might be that the SRC4392 is not being electrically Reset on powerup (to correctly initialize the internal logic).
We have been caught out many times by poor documentation, a line will be hidden somewhere in a 400+ page document saying that you need to set X register to enable Active pull-down on a shared GPIO or some such....
Hardwares Reset initializes the internal logic, all registers and buffers to there default state.
Software reset only sets registers and buffers to there default (does not initializes the internal logic).
Maybe try adding a 100nF Cap from Ground to /RST _SRC4392 line from the ATMEL to see if this helps.
Have you infact confirmed that A1 and SRC4392 NRST are being electrically pulled low? If this GPIO port is somehow miss-configured (as the upper 4bit nibble of this GPIO is shared function with the JTAG port - and you also have ADC analogue inputs), it might be that the SRC4392 is not being electrically Reset on powerup (to correctly initialize the internal logic).
We have been caught out many times by poor documentation, a line will be hidden somewhere in a 400+ page document saying that you need to set X register to enable Active pull-down on a shared GPIO or some such....
Hardwares Reset initializes the internal logic, all registers and buffers to there default state.
Software reset only sets registers and buffers to there default (does not initializes the internal logic).
Maybe try adding a 100nF Cap from Ground to /RST _SRC4392 line from the ATMEL to see if this helps.
Last edited:
Thanks John. When I run / debug the sw in Atmel AVR Studio is shows low for A1 all th time. However when I check the voltage on the A1 pin it is high. No idea how this can happen... there is no external pull up. Not sure how to disable JYAG ir check whether the PORTF acts as a generic i/o port. I will try to check on the scope what happens to /RST pin of SRC4392 when I force it low. Maybe it it really something with upper 4 bits of PRTF / JTAG conflict.
Yep, going to make a bet here that the Reset line is not toggled Low on power-up so the SRC internal Logic is not being "Hardware" reset upon power up...
With Atmel you often have to configure the shared function Ports mode (i.e Analogue / Digital) - they are often set to Analog mode by default. Take a careful read through the Datasheet and I bet you will find a cryptic line say you need to set register "x" for Digital mode GPIO's...
Hopefully its not an issue of the shared JTAG pins - NORMALLY some or all JTAG pins can be used for GPIO's but each MCU has its own "personalty".
Let us know how you get on
It really looks like you have the JTAG port enabled :-
If the JTAG interface is enabled, the pull-up resistors on pins PF7(TDI), PF5(TMS), and PF4(TCK) will be activated even if a Reset occurs.
• TDI, ADC7 – Port F, bit 7
ADC7, Analog to Digital Converter, Channel 7.
TDI, JTAG Test Data In: Serial input data to be shifted in to the Instruction Register or Data Register (scan chains).
When the JTAG interface is enabled, this pin can not be used as an I/O pin.
• TDO, ADC6 – Port F, bit 6
ADC6, Analog to Digital Converter, Channel 6.
TDO, JTAG Test Data Out: Serial output data from Instruction Register or Data Register.
When the JTAG interface is enabled, this pin can not be used as an I/O pin.
The TDO pin is tri-stated unless TAP states that shift out data are entered.
• TMS, ADC5 – Port F, bit 5
ADC5, Analog to Digital Converter, Channel 5.
TMS, JTAG Test Mode Select: This pin is used for navigating through the TAP-controller state machine.
When the JTAG interface is enabled, this pin can not be used as an I/O pin.
• TCK, ADC4 – Port F, bit 4
ADC4, Analog to Digital Converter, Channel 4.
TCK, JTAG Test Clock: JTAG operation is synchronous to TCK.
When the JTAG interface is enabled, this pin can not be used as an I/O pin.
:-If the JTAG interface is enabled, the pull-up resistors on pins PF7(TDI), PF5(TMS), and PF4(TCK) will be activated even if a Reset occurs.
• TDI, ADC7 – Port F, bit 7
ADC7, Analog to Digital Converter, Channel 7.
TDI, JTAG Test Data In: Serial input data to be shifted in to the Instruction Register or Data Register (scan chains).
When the JTAG interface is enabled, this pin can not be used as an I/O pin.
• TDO, ADC6 – Port F, bit 6
ADC6, Analog to Digital Converter, Channel 6.
TDO, JTAG Test Data Out: Serial output data from Instruction Register or Data Register.
When the JTAG interface is enabled, this pin can not be used as an I/O pin.
The TDO pin is tri-stated unless TAP states that shift out data are entered.
• TMS, ADC5 – Port F, bit 5
ADC5, Analog to Digital Converter, Channel 5.
TMS, JTAG Test Mode Select: This pin is used for navigating through the TAP-controller state machine.
When the JTAG interface is enabled, this pin can not be used as an I/O pin.
• TCK, ADC4 – Port F, bit 4
ADC4, Analog to Digital Converter, Channel 4.
TCK, JTAG Test Clock: JTAG operation is synchronous to TCK.
When the JTAG interface is enabled, this pin can not be used as an I/O pin.
Thanks John, digging into it now. Not sure how to check whether JTAG is enabled or not. I don’t change - not sure what is the default state. I think you can disable it using fuses during standard programming. However as I use programming using USB (FLIP app) I’m afraid I can’t disable it this way. Maybe by checking bit JTD in MCUCR reg? I’m not a se guy so any help would be welcome
It really looks like you have the JTAG port enabled
If the JTAG interface is enabled, the pull-up resistors on pins PF7(TDI), PF5(TMS), and PF4(TCK) will be activated even if a Reset occurs.
• TDI, ADC7 – Port F, bit 7
ADC7, Analog to Digital Converter, Channel 7.
TDI, JTAG Test Data In: Serial input data to be shifted in to the Instruction Register or Data Register (scan chains).
When the JTAG interface is enabled, this pin can not be used as an I/O pin.
• TDO, ADC6 – Port F, bit 6
ADC6, Analog to Digital Converter, Channel 6.
TDO, JTAG Test Data Out: Serial output data from Instruction Register or Data Register.
When the JTAG interface is enabled, this pin can not be used as an I/O pin.
The TDO pin is tri-stated unless TAP states that shift out data are entered.
• TMS, ADC5 – Port F, bit 5
ADC5, Analog to Digital Converter, Channel 5.
TMS, JTAG Test Mode Select: This pin is used for navigating through the TAP-controller state machine.
When the JTAG interface is enabled, this pin can not be used as an I/O pin.
• TCK, ADC4 – Port F, bit 4
ADC4, Analog to Digital Converter, Channel 4.
TCK, JTAG Test Clock: JTAG operation is synchronous to TCK.
When the JTAG interface is enabled, this pin can not be used as an I/O pin.
Let us know how you get on
JohnW,
Speaking of getting on with things, would you be willing to say anything about how you are getting on with your low-ish cost FPGA dac project?
Thanks John, digging into it now. Not sure how to check whether JTAG is enabled or not. I don’t change - not sure what is the default state. I think you can disable it using fuses during standard programming. However as I use programming using USB (FLIP app) I’m afraid I can’t disable it this way. Maybe by checking bit JTD in MCUCR reg? I’m not a se guy so any help would be welcome
I'm VERY much a hardware guy, so cannot help you much, apperantly it's the JTAGEN bit that needs to be set to 1, here s a few links:-
avr - problems using atmega644pv jtag pins as gpio - Electrical Engineering Stack Exchange
How to disable JTAG interface on ATMEGA1280 | Microchip
The JTD bit needs to be written twice :
In order to avoid unintentional disabling or enabling of the JTAG interface, a timed sequence must be followed when changing this bit: The application software must write this bit to the desired value twice within four cycles to change its value.
void setup() {
MCUCR = (1<<JTD);
MCUCR = (1<<JTD);
}
Last edited:
JohnW,
Speaking of getting on with things, would you be willing to say anything about how you are getting on with your low-ish cost FPGA dac project?
We had very good results with the first spins PCB's (couple of designs) - issued PCB files for the updated design earlier this week - HK Global sources and HK TDC show end of next week, so building of the boards will take a little longer then normal.
First PCBs:-
THD 0.0003%
DNR with 20 bit modulator, 117dB - we will improve that when we start to play with the FPGA...
Excited about the design, "Unfortunately" yesterday I developed an even simpler (cheaper) and higher performance analogue stage so there will be a respin - it offers such a potential improvement that we cannot ignore it...
Thanks John -this helped, first success By disabling the JTAG I have pulled A1 down so I have address E0 as expected. It seems JTAG active was really the issues. I have re-flashed firmware in both speaker and:
- one seems to be working ok (at least for now)
- the other one still no output signal
I tried to:
- read SRC4392 registers drom both and they are ok -correct values
- check status by reading registers 13 and 14 and there is an issue here:
- leaft speaker (working)- reg 14 shows 00 - no error, reg 13 shows 03 - ok, max available RXCKO freq
- right speaker (not working) - reg 14 shows 04 - error of not locking, reg 13 shows 00 - not ok
So it seems the right speaker still has an issue with DIR in SRC4392. I will try to power it on and off over the day to check whether left soeaker is still ok and right not working or whether it is still unstable - sometimes ok, sometimes not
By disabling the JTAG I have pulled A1 down so I have address E0 as expected. It seems JTAG active was really the issues. I have re-flashed firmware in both speaker and:- one seems to be working ok (at least for now)
- the other one still no output signal
I tried to:
- read SRC4392 registers drom both and they are ok -correct values
- check status by reading registers 13 and 14 and there is an issue here:
- leaft speaker (working)- reg 14 shows 00 - no error, reg 13 shows 03 - ok, max available RXCKO freq
- right speaker (not working) - reg 14 shows 04 - error of not locking, reg 13 shows 00 - not ok
So it seems the right speaker still has an issue with DIR in SRC4392. I will try to power it on and off over the day to check whether left soeaker is still ok and right not working or whether it is still unstable - sometimes ok, sometimes not
Sounds exciting, all right. Please keep those of us interested in dac development updated from time to time. Be nice to hear your dac when you are ready.
-Mark
Thanks John -this helped, first success
- one seems to be working ok (at least for now)
- the other one still no output signal
I tried to:
- read SRC4392 registers drom both and they are ok -correct values
- check status by reading registers 13 and 14 and there is an issue here:
- leaft speaker (working)- reg 14 shows 00 - no error, reg 13 shows 03 - ok, max available RXCKO freq
- right speaker (not working) - reg 14 shows 04 - error of not locking, reg 13 shows 00 - not ok
So it seems the right speaker still has an issue with DIR in SRC4392. I will try to power it on and off over the day to check whether left soeaker is still ok and right not working or whether it is still unstable - sometimes ok, sometimes not
Well some progress
, Just to confirm you are performing a"Hard" Reset (GPIO Toggle) on powerup, not just a software Reset (they are not the same function).Its important to scope the Reset line to confirm....
Thanks Mark, We are also excited about the design
Might start a thread here once we are close (hopefully next PCBs) - it would give some insight into Discrete DAC design Just made some measurements - the behavior of Reset looks ok - clear 3.3V (high), after 1 second going down for 20ms and then back up to high. Exactly following source code. Measured on the reset pin of SRC4392.
Also checked spdif input - looks ok, Vpp 400 mV. All power supplies clean, registers properely configured. One speak ok, the other one not able to lock (DIR SRC4392). I’m still thinking how to check the staus of DIR - SPDIF signal looks ok, MCLK as clock inout also ok. Registers properely configured (same for both speakers). But when I read lock bit or measure at lock pin it is not locked. Any idea what should try to do with DIR to check what can be wrong? One other thing I will try is to change Rx input - just in case it is destroyed or so.
Also checked spdif input - looks ok, Vpp 400 mV. All power supplies clean, registers properely configured. One speak ok, the other one not able to lock (DIR SRC4392). I’m still thinking how to check the staus of DIR - SPDIF signal looks ok, MCLK as clock inout also ok. Registers properely configured (same for both speakers). But when I read lock bit or measure at lock pin it is not locked. Any idea what should try to do with DIR to check what can be wrong? One other thing I will try is to change Rx input - just in case it is destroyed or so.
Well some progress
Its important to scope the Reset line to confirm....
Actually this is what is likely wrong - I have once more double checked critical signals and voltages on SRC4392 pins and everything seems to be ok. So I did one last check to feed SPDIF signal to a different RX input (RX2 —> RX3) and voila, it works now... just to make sure it is not only an accidnet I heated all solde junctions on tha path between input terminal and RX pins of SRC4392 and moved input back to the original one (RX2) and nothing... so I think something happened with RX2 pins as when I switch to RX3 now again it works.
I have only connected spdif CINCH connected from source signal to SRC4392 input circuit, so not sure what happened. Maybe some ESD or so?
I use stabdard input curcuit per SRC4392 datasheet - Resistor and two capacitors.
I also thought about the DC offset you mentioned but as there are series capacitor going to RX input it shouldn’t be an issue, or? I will double check the DC offset. What I know is thar RX- pin shows V high DC voltage only (3.3 or 1.8V?) while RX+ whows digial signal with 2.82 MHz Vpp ~ 400 mV (for 44.1kHz sampling rate)
I have only connected spdif CINCH connected from source signal to SRC4392 input circuit, so not sure what happened. Maybe some ESD or so?
I use stabdard input curcuit per SRC4392 datasheet - Resistor and two capacitors.
I also thought about the DC offset you mentioned but as there are series capacitor going to RX input it shouldn’t be an issue, or? I will double check the DC offset. What I know is thar RX- pin shows V high DC voltage only (3.3 or 1.8V?) while RX+ whows digial signal with 2.82 MHz Vpp ~ 400 mV (for 44.1kHz sampling rate)
RCA connectors (what you call CINCH) are a badly designed connector - anyone working in a Digital audio service department will be aware of blown SPDIF inputs.
The trouble with the RCA Phono connector is that the center contact is made first before the Ground collar - this results in Earth leakage currents (which can be surprisingly high in todays environment of Switch Mode PSU's everywhere).
This Earth leakage Current goes straight into the input stage the SPDIF receiver...
Thanks John. Will serial capacitor and 75 ohm resistor help with this current issue? I’m also thinking whether using input transformer can help too.
The other thing is some potential DC offset which may or may not influence whether SRC4392 input circuit sees the right input signal (“logic” levels). I need to check it with the scope as suggested above.
The other thing is some potential DC offset which may or may not influence whether SRC4392 input circuit sees the right input signal (“logic” levels). I need to check it with the scope as suggested above.
Ok, so I thought I will share the latest update
It seems that there were 3 different issues impacting unstable behavior of my design - digital speakers:
1. Disabling JTAG on the Atmel controller - same pins used to control SRC4392 (reset on) - sometimes worked and sometimes not - disabling JTAG solved it
2. Damaged SPDIF input of SRC4392 - maybe I destroyed it by manipulating with spdif input cables? By switching input to another one it started working (right speaker only)
3. Unstable power on - sometimes both left (master) and right (slave) speakers worked, sometimes not and sometimes right (slave) worked only - after some analysis I recognized that left (master) speaker sometimes showed NACK on I2C bus - SRC4392 and / or other TAS I2C slave circuits wern’t configured after power on - bad soldering of I2C pull up resistor...
I’m playing the music for last two weeks without issue so hopefully my problem is fixed now
Really appreciate help and support from diyaudio forum!
It seems that there were 3 different issues impacting unstable behavior of my design - digital speakers:
1. Disabling JTAG on the Atmel controller - same pins used to control SRC4392 (reset on) - sometimes worked and sometimes not - disabling JTAG solved it
2. Damaged SPDIF input of SRC4392 - maybe I destroyed it by manipulating with spdif input cables? By switching input to another one it started working (right speaker only)
3. Unstable power on - sometimes both left (master) and right (slave) speakers worked, sometimes not and sometimes right (slave) worked only - after some analysis I recognized that left (master) speaker sometimes showed NACK on I2C bus - SRC4392 and / or other TAS I2C slave circuits wern’t configured after power on - bad soldering of I2C pull up resistor...
I’m playing the music for last two weeks without issue so hopefully my problem is fixed now
Really appreciate help and support from diyaudio forum!
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.