I am using a PIC16F877A to control the TI PGA2310 device.
Right now, when I increase or decrease the volume, I can see the waveform grow or shrink on the scope, however when I stop changing the volume, the output immediately drops to zero.
Every now and then it "sticks" and the output stays on as it should, but most of the time I can only see an output waveform when the volume is actually being changed.
Does anyone have any experience or a possible explanation/solution?
Any help would be greatly appreciated.
Thanks.
Brian
Right now, when I increase or decrease the volume, I can see the waveform grow or shrink on the scope, however when I stop changing the volume, the output immediately drops to zero.
Every now and then it "sticks" and the output stays on as it should, but most of the time I can only see an output waveform when the volume is actually being changed.
Does anyone have any experience or a possible explanation/solution?
Any help would be greatly appreciated.
Thanks.
Brian
The mute pin is connected properly.
The strange thing is that the signal level is changing correctly as the volume is increased or decreased, but the output is only visible while it is being changed.
Brian
The strange thing is that the signal level is changing correctly as the volume is increased or decreased, but the output is only visible while it is being changed.
Brian
Hi Brian,
Maybe a silly question, but are you sure you have correctly connected the PSU to the PGA - I've seen situations where the power pins to CMOS logic have been left unconnected, but the logic gates still "function" by optaining there power from the "Inputs" via the internal static protection diodes..
John
Maybe a silly question, but are you sure you have correctly connected the PSU to the PGA - I've seen situations where the power pins to CMOS logic have been left unconnected, but the logic gates still "function" by optaining there power from the "Inputs" via the internal static protection diodes..
John
also -- make sure that your scope is DC coupling the signal if you are using a DC source -- I was using a DAC for a slowly increasing signal one time and forgot to make the switch.
Also -- make sure that the power supply ground is properly connected -- make sure that your scope and the DUT are on the same power line.
Also -- make sure that the power supply ground is properly connected -- make sure that your scope and the DUT are on the same power line.
The power supply is properly connected and I have been using a 1kHz sinusoidal source.
I'm wondering if maybe it's an issue with the timing and setting and clearing the CS'- I'm using a PIC @ 4 MHz.
Brian
I'm wondering if maybe it's an issue with the timing and setting and clearing the CS'- I'm using a PIC @ 4 MHz.
Brian
Can you rule out between a hard- or software reason?
That would make digging into a certain direction much easier...
I try to make some shots into the dark:
- On page 7 of the PGA2310 datasheet, they say: "On power up, all internal fli-flops are reset. The gain byte value for both left and right channel are set to 00hex, or mute condition." Sounds exactly like your problem description. Do you send a reset or interrupt power after ending the programming cycle? Are you sure you don't? 😉
- On page 8, the timing of the programming cycle is described. Does your problem occur just after you latch /CS back up? If so, do you probably shift a couple of bits too few or too many into the PGA? Maybe the relation between rising and falling clock edge also plays a role here?
- On page 9, the calculation of the volume setting is described. It goes: "For N=0: Mute Condition. The input multiplexer is connected to analog ground". Do you perhaps accidentally transmit some more zeroes when you actually want to end the programming of the intended volume?
- On page 11, the mute functionality is described. Of course you know there are two ways of affecting the mute behaviour, pin 8 and a zero volume (as mentioned). Are you sure you handle both correctly at the same time? E.g. not forgetting the mute pin when unmuting via software?
How does your software accomplish those 'changes'?
To my understanding, a volume change is a whole programming cycle (16 bits).
So inbetween those programming cycles the output doesn't mute, but after you stopped clocking in bits, you get problems. Do you latch up /CS inbetween those changes?
If so, how much time passes between /CS latched up and signal loss?
I'd say, going deeper into your application would require debugging both your hard- and your software. I would be happy if you sent me schematic, layout and sourcecode 😉
Ciao,
Sebastian.
That would make digging into a certain direction much easier...
I try to make some shots into the dark:
- On page 7 of the PGA2310 datasheet, they say: "On power up, all internal fli-flops are reset. The gain byte value for both left and right channel are set to 00hex, or mute condition." Sounds exactly like your problem description. Do you send a reset or interrupt power after ending the programming cycle? Are you sure you don't? 😉
- On page 8, the timing of the programming cycle is described. Does your problem occur just after you latch /CS back up? If so, do you probably shift a couple of bits too few or too many into the PGA? Maybe the relation between rising and falling clock edge also plays a role here?
- On page 9, the calculation of the volume setting is described. It goes: "For N=0: Mute Condition. The input multiplexer is connected to analog ground". Do you perhaps accidentally transmit some more zeroes when you actually want to end the programming of the intended volume?
- On page 11, the mute functionality is described. Of course you know there are two ways of affecting the mute behaviour, pin 8 and a zero volume (as mentioned). Are you sure you handle both correctly at the same time? E.g. not forgetting the mute pin when unmuting via software?
How does your software accomplish those 'changes'?
To my understanding, a volume change is a whole programming cycle (16 bits).
So inbetween those programming cycles the output doesn't mute, but after you stopped clocking in bits, you get problems. Do you latch up /CS inbetween those changes?
If so, how much time passes between /CS latched up and signal loss?
I'd say, going deeper into your application would require debugging both your hard- and your software. I would be happy if you sent me schematic, layout and sourcecode 😉
Ciao,
Sebastian.
Brian,
Have you tried scoping the SPI control bus to check signal timing? My guess is that you're raising CS' before the last bit is clocked in. The signal timing section of the datasheet shows that there is a minimum time of 35n between SCLK falling on the last bit to CS' rising (listed as Tcfcs).
I had a different problem controlling my PGA2310 and I attached a scope plot showing the SPI timing in this thread:
http://www.diyaudio.com/forums/showthread.php?threadid=24731
As a follow up to that thread, I replaced the offending PGA2310 and everything working fine. Faulty parts are rare these days but they still occur…
Nice one,
David.
Have you tried scoping the SPI control bus to check signal timing? My guess is that you're raising CS' before the last bit is clocked in. The signal timing section of the datasheet shows that there is a minimum time of 35n between SCLK falling on the last bit to CS' rising (listed as Tcfcs).
I had a different problem controlling my PGA2310 and I attached a scope plot showing the SPI timing in this thread:
http://www.diyaudio.com/forums/showthread.php?threadid=24731
As a follow up to that thread, I replaced the offending PGA2310 and everything working fine. Faulty parts are rare these days but they still occur…
Nice one,
David.
I tried everyone's suggestions, but I am still having the same trouble.
Sebastian- can I email you the schematic/source code if you wouldn't mind taking a quick look?
Thanks.
Brian
Sebastian- can I email you the schematic/source code if you wouldn't mind taking a quick look?
Thanks.
Brian
I don't mind 😉
But I can't promise to be of much help! Seriously!
Why don't you post it on the forum, e.g. as a zip file? It's probably no specific problem of the PGA or the PIC. And I'm not an expert in electronic design... so others should have a look, too.
Anyways, You can find my email adress at http://www.informatik.hu-berlin.de/~kraus.
Ciao,
Sebastian.
But I can't promise to be of much help! Seriously!
Why don't you post it on the forum, e.g. as a zip file? It's probably no specific problem of the PGA or the PIC. And I'm not an expert in electronic design... so others should have a look, too.
Anyways, You can find my email adress at http://www.informatik.hu-berlin.de/~kraus.
Ciao,
Sebastian.
This may be no pretty code, or what you would expect from a professional. But it does work with 16F877A and 16F628 .
Thanks for the replies and the sample code.
Attached is the code I have been working with.
My basic concept was to store the volume in 2 different locations (for balance control), and to send it out to the PGA using 2 loops, each 8 cycles. To send the serial code, I do a right logical shift through the carry bit, test the carry and then send it's value on the data line. I don't think there's a problem with this algorithim, since the volume does change, so maybe there's something wrong about how I'm setting and clearing the enable bits? I figured 4 NOPs would be enough time for the data to settle in.
The DECVOL and INCVOL subroutines relate to the optical encoder decoding chip. At the end of the code I move VOLUME1 to PORTC - this is so that I can see the value of the memory location using 8 LED's and verify that the program is working.
Thanks.
Brian
Attached is the code I have been working with.
My basic concept was to store the volume in 2 different locations (for balance control), and to send it out to the PGA using 2 loops, each 8 cycles. To send the serial code, I do a right logical shift through the carry bit, test the carry and then send it's value on the data line. I don't think there's a problem with this algorithim, since the volume does change, so maybe there's something wrong about how I'm setting and clearing the enable bits? I figured 4 NOPs would be enough time for the data to settle in.
The DECVOL and INCVOL subroutines relate to the optical encoder decoding chip. At the end of the code I move VOLUME1 to PORTC - this is so that I can see the value of the memory location using 8 LED's and verify that the program is working.
Thanks.
Brian
There should be no problem to modify the linear code for balance.
I tried with some loops for several hours, and did not get it working. So i descided for brute force, linear code, and it did like it should. I don´t know why, maybe timing. In case you get it workig, please tell me.
I tried with some loops for several hours, and did not get it working. So i descided for brute force, linear code, and it did like it should. I don´t know why, maybe timing. In case you get it workig, please tell me.
Hi,
As may have pointed out, CS timing or glich is the most probable cause of your problem, I'd say glich is most probobly. The only way to be sure is to look at your SPI signals with a scope.
/Jesper
As may have pointed out, CS timing or glich is the most probable cause of your problem, I'd say glich is most probobly. The only way to be sure is to look at your SPI signals with a scope.
/Jesper
Hi-
I agree- I think it must be a problem with the CS - however I can't figure out what it is- even with several NOP's before/after latching CS, it still does not work.
I tried the code bit-by-bit without loops, and it now works.
Thanks for all the help everyone!
Brian
I agree- I think it must be a problem with the CS - however I can't figure out what it is- even with several NOP's before/after latching CS, it still does not work.
I tried the code bit-by-bit without loops, and it now works.
Thanks for all the help everyone!
Brian
- Status
- Not open for further replies.