Core Blown?
Hi! I am pretty sure I killed the Core on my 1467. I am working on a project that uses two 1701 board providing serial data on SDATA0 and SDATA3. During this work to identify the proper register settings, at some point, my 1467 started returning all FFFFFFFF on register reads. I had also just cycled the input power, and thought that perhaps I had exceeded the input 6 volt to the on board regulator. My supply seems to be in good order, and have been monitoring the output during power cycles and the voltage has never exceeded 6.45 volts as indicated on my bench DVM doing statistical analysis over the past 48 hours. but I am not ruling this possibility out. I suspected that maybe the onboard DVDD regulator had failed, so I bypassed and supplied my own DVDD power from a bench supply. I noticed the current was only 10ma @ 1.1 volts and I read that some programs would use around 200-300 ma of current, so it seems dead. All other functions (this is an EVAL board) operate such as program download, EEPROM write and verify, and Sigma Studio shows Active, but a single DC block and readback show no connection to the core. The actual register controls tab shows no flags on the core, but I cannot toggle "kill core" and see the "core running" status change, so I am assuming they are just showing green with no core connection. Admittedly, I tried a number of combinations with the 1701s that would include disconnecting the serial inputs and clocks, power cycling of the 1701, etc., without powering down the 1467, so my question is, do you think it is possible to kill the core of the 1467 by perhaps back feeding across the SDATA or CLK lines when the 1701s were dead, but had serial connection? Would you be more suspicious of this as a failure point, or a spike in the primary power to the 6v onboard regulator? I am sure the onboard regulator is functioning, as I can communicate with the board over SPI, but could the onboard pass on a spike to the DVDD during a power cycle that could damage the DSP? I am in the process of designing permanent power supplies, so was also wondering if there is a sequence of powering up the 1467 with serial connected boards? Should I power the 1701 first and then the 1467? Have you heard of killing the DSP through serial data connections not being properly power cycled, disconnected without powering down, etc? I want to obviously mitigate whatever might have caused this to happen, and so far have some theories, but since I am not well versed on the potential vulnerable areas in interfacing with this dsp chip, I don't know where to concentrate. I have a spare board, but dont want to introduce it back into the circuit until I have exhausted all potential cautions that you may have in regards to powering and interconnecting these devices. I have had this board running in this configuration for about 6 months, so it must be something related to either the 6b volt supply cycling, or the terminating and disconnecting of live data lines. Anything you can share on this topic is appreciated!! Thanks!!
dsp core fail
hardware
adau1467
serial data interface
processors and dsp
Integrated/Special Purpose A/D Converters
Processors and Microcontrollers
Show More
Hello ElsaDog,
I couldn't access the link you posted, the server says, "page not found". Could you please attach as projects?
Did you disconnect 1701 completely from 1467 and just try basic LED blink or DC block & readback cell project?
ElsaDog said:
but a single DC block and readback show no connection to the core
Is it when both boards are connected or 1467 alone?
You can 'kill the core' using the GUI setting and to make the DSP run again you have to 'toggle the KILL CORE button again' and you must toggle START CORE button (you first STOP the core and START the core)
Did you try this in your project?
Regards,
Harish
Hi, Harish! Yes, I built an entirely new project brining in the DSP and USBi, and then loaded the simple DC source and readback. I see the capture messages running , the read request line, read result line, Block write, etc, but the readback always shows 0.000000. When i connect the board 6.0 volts, I get -0.000000 When I do a read of the Core Status, is always shows "core not running" . I tried the cycle per your instructions. It seems like everything else is normal, but the DSP is not communicating. 1467 Core Test.dspproj
Further Update. I decided to wipe the EEPROM, even tho I have not been booting from EEPROM, just the active project in SS. Again, the SS program would not communicate with the DSP, even when the basic block read program was loaded. After I wrote the EEPROM with the basic Block Read Program, presto, it started to work and the core showed running. So, 1) I dont know how the EEPROM was still corrupting whatever state was going on when I just loaded the program from SS. and 2) there must be something wrong with my base program that is forcing the core to hibernate. The last thing that I did was to modify the input block from the external 1701s, not sure if this in the program is causing any issues? Also, the 1701s are disconnected from the board, and perhaps it is looking for them and is failing as no data is present? Any ideas around this I would appreciate. Here is the full program that started the issue after 1701 mo1467 DSP Audio Controller 05272026 v2.2.dspprojifications were applied (upper right of the schematic, 1701 Pi Voice input block)
Hello ElsaDog,
The attached program works fine in my Eval board, so it seems your hardware has a problem.
Either the DSP is not programmed in the first place or there is a problem with USBi reading back the data from the DSP. Make a basic audio pass thru project with DC block and readback cell included or LED blink. If reading back with USBi is an issue, then audio pass thru and LED blink should work fine.
Once you did Link compile download, probe any serial port clock pin (master) and see if you can see clocks coming out of the pin?
if there are no clocks then DSP is not programmed at all. Either the USBi has an issue in writing to DSP or DSP doesn't acknowledge the writes. we can probe the slave control port to see if the USBi sends out the sequence correctly.
If you see clocks, then PLL and other serial port registers are programmed correctly, so eventually PM,DM will also be programmed. In this case you may have an issue in reading back the data, it could purely be an USBi issue. If you have extra USBi module then you can rule this out, even the 2nd USBi also gives the same result then the issue must be something in the power section of the DSP. we have to look very carefully since you did some modifications there.
Regards,
Harish
Please log in to reply.