Hi All-
I've designed my first embedded system which brings vacuum tubes and uC's together (a tube stereo receiver, part fun/challenge, part sick of not being able to get a good sounding stereo anymore for decent $$).
I was extremely happy at how well everything came together with only some minor bumps in the road. HOWEVER, after successful tests of every subsystem, a major problem reared its ugly little head and I can't hear my work: The system freezes when I engage the high voltage supply. Agh...So close!
I've been working for 2 weeks or so on the solution but nothing seems to be working. Worse, I don't have adequate test tools (100Mhz Analog scope, Fluke DMM, and a function gen).
What I think is happening is that the current surge from turn-on of the high voltage supply is causing a fluctuation on the digital supply. I think it may actually not be causing the AVR to freeze, but the I2C bus which the entire digital system depends on.
The system is rather complex, so I'll just try to cover the basics. There are 4 power supplies in the unit, and I know the offending unit is the HV supply from removing fuses. All of the power supplies are fed from an MLX power connector and the HV supply goes left, and the LV supplies go down ("L" shape to minimize problems like this...fail). The digital supply has a common mode choke for EMI/isolation, and is dual regulated (12V first, then 5V). All supplies have grounds connected together at 1 point on the board. The digital circuitry is almost always more than 8 inches away from the HV supply, so I assume the only good radiative coupling path is right at the connector.
I can both measure a small voltage drop (50mV or so)when the HV supply is activated on the digital supply, and see LED's dim briefly, but I have no way of capturing the event at the moment. I've tried using the min/max function on the DMM to see if it was fast enough to show a huge drop/spike but it's not.
I should also mention that the digital supply has very hefty 3900uF caps on the input and output of the regulators, and a 470uF between them so I'm amazed these caps can't hold the line steady.
I've already written a lot, so I'll wrap it up with the questions:
1. How do I track down the source of the EMI/spike with the equipment I have?
2. Are what are some things I can try around the uC that may be making it susceptible to this beyond the basic stuff (coupling caps...have them, B.O.D., Watchdog disabling, etc.)? For instance, maybe my unused uC pins are the issue?
3. I know software fixes can be the answer, but I'd like to solve the electrical first as software would be like putting a bandaid on things. For instance, I could likely setup the Watchdog to restart the system, but that's a poor solution.
I'm using the Fleury driver, but I can't seem to figure out how to modify it or my code so that if the bus hangs, to try what it was doing again once or twice. I suspect some of the while loops in that code are primed to cause lock-ups like this. Any ideas on that front? I believe there's a TI app note about this, but I can't seem to find it.
Thank you in advance! Sorry for the novel, I just want to provide the necessary information to anyone generous enough to attempt to help!0
I've designed my first embedded system which brings vacuum tubes and uC's together (a tube stereo receiver, part fun/challenge, part sick of not being able to get a good sounding stereo anymore for decent $$).
I was extremely happy at how well everything came together with only some minor bumps in the road. HOWEVER, after successful tests of every subsystem, a major problem reared its ugly little head and I can't hear my work: The system freezes when I engage the high voltage supply. Agh...So close!
I've been working for 2 weeks or so on the solution but nothing seems to be working. Worse, I don't have adequate test tools (100Mhz Analog scope, Fluke DMM, and a function gen).
What I think is happening is that the current surge from turn-on of the high voltage supply is causing a fluctuation on the digital supply. I think it may actually not be causing the AVR to freeze, but the I2C bus which the entire digital system depends on.
The system is rather complex, so I'll just try to cover the basics. There are 4 power supplies in the unit, and I know the offending unit is the HV supply from removing fuses. All of the power supplies are fed from an MLX power connector and the HV supply goes left, and the LV supplies go down ("L" shape to minimize problems like this...fail). The digital supply has a common mode choke for EMI/isolation, and is dual regulated (12V first, then 5V). All supplies have grounds connected together at 1 point on the board. The digital circuitry is almost always more than 8 inches away from the HV supply, so I assume the only good radiative coupling path is right at the connector.
I can both measure a small voltage drop (50mV or so)when the HV supply is activated on the digital supply, and see LED's dim briefly, but I have no way of capturing the event at the moment. I've tried using the min/max function on the DMM to see if it was fast enough to show a huge drop/spike but it's not.
I should also mention that the digital supply has very hefty 3900uF caps on the input and output of the regulators, and a 470uF between them so I'm amazed these caps can't hold the line steady.
I've already written a lot, so I'll wrap it up with the questions:
1. How do I track down the source of the EMI/spike with the equipment I have?
2. Are what are some things I can try around the uC that may be making it susceptible to this beyond the basic stuff (coupling caps...have them, B.O.D., Watchdog disabling, etc.)? For instance, maybe my unused uC pins are the issue?
3. I know software fixes can be the answer, but I'd like to solve the electrical first as software would be like putting a bandaid on things. For instance, I could likely setup the Watchdog to restart the system, but that's a poor solution.
I'm using the Fleury driver, but I can't seem to figure out how to modify it or my code so that if the bus hangs, to try what it was doing again once or twice. I suspect some of the while loops in that code are primed to cause lock-ups like this. Any ideas on that front? I believe there's a TI app note about this, but I can't seem to find it.
Thank you in advance! Sorry for the novel, I just want to provide the necessary information to anyone generous enough to attempt to help!0