Hello!
I thought I'd ask you DSP wizards a couple of suggestion on how to troubleshoot DSP hardware.
I got back an old Electro Harmonix POG with the "always ON" syndrome. The status LED stays ON all the time, the sound is bypassed, the footswitch doesn't change anything.
Opened it up, I was able to see that the footswitch on/off signal was arriving on the Microcontroller that was connected to the DSP through SPI.
The two faults I noticed were that the Microcontroller doesn't change the LED status if pressing the footswitch and that the DSP is not sending or receiving any data through the MCLK, LRCK etc.. to the CODEC. I initially thought that both microcontroller and DSP were fried but then I could see on some of their unused pins there were streams of data. As I could see they would be possibly communicating due to activity on the SPI lines.
I don't have a good enough oscilloscope to check the 16mhz crystal but I do get a faint very high speed sawtooth at the MCLK input of the DSP and I supposed that's what my oscilloscope reads from a very fast square wave.
What I'm asking is, is there a way to externally check if either of the microcontroller or the dsp are stuck in the program or faulty at all? Cause I thought if there's activity on the SPI line, the code must be running but then why would the CODEC be completely silent and the effect status not change with the footswitch?
I already tried resetting both the DSP and the Microcontroller from their assigned pins and in both cases the Status led that is connected to the microcontroller goes off (pin on the uC turns high).
Thanks in advance for your help!
Cheers,
Alex
Well normally debugging a board you'd check power supply voltages, oscillators, power on reset pulses, and if that all looks OK and it still doesn't work... ah... hmmm. You'd check the data bus signals on external program storage and see if those are going up and down. If there's no external program storage then you can't do that and the next thing you'd do would be to hook up a CPU emulator or attach a terminal to a serial port if there is one so you could see the boot sequence.
Thank you Larry for the response, how do you check the power on reset pulse? should I just probe the reset pin with an oscilloscope to check for a ramp?
I could see a data stream on the SPI lines so would it help at all getting an USB to SPI device and read what's happening? the SPI connects the controller to the DSP and to the potentiometer encoders, not sure who is the master in between the first two.
Other question: Does activity on the SPI bus means the device it's clearly running through the program or can it be that the program is frozen and some of the communication pins on the device still send out bit streams?
Cheers,
Alex
Normally a pin is supposed to be held low for some amount of time after the power supplies stabilize in order to reliably initialize the chip. You'd find the details in the chip documentation which may be tough if it's custom.
Above and beyond that you're getting into the realm of things that (I think, anyway) are going to be very difficult to debug without additional knowledge about the device(s) and specifically how they are programmed.
My final thought is that the DSP chip is faulty. It is quite expensive, around £30 and I don't have the tools to replace it. Even the fact that the effect program is stored in the microcontroller that, as far as I know, seems to be working.. I have already quite a few rabbit holes I got sucked into so I'll leave this as it is!
One of the rabbit holes, Larry, is programming an effect on the FV-1 without the SpinCad :icon_razz:
The FV-1 instructions set has become my new book to read on the train!
Quote from: alecacca on January 17, 2018, 08:34:14 PM
One of the rabbit holes, Larry, is programming an effect on the FV-1 without the SpinCad :icon_razz:
The FV-1 instructions set has become my new book to read on the train!
Haha, I certainly know that feeling! I've been doing a bit of FV-1 consulting lately, none of which uses SpinCAD because I am tweaking the customer's existing patches written by someone else ten years ago. I definitely printed out all the Spin ASM and LFO application notes, read them over and over, and they are still in a binder around here somewhere.