DSP Audio Fx board repairablity

[Leeroy]

Greetings!

TL/DR goto last line (:

Friend of mine asked if I could help him repair burnt out PCB (Fx module) from Dynacord PowerMate 1000-2.
He was reassembling it after cleaning and accidently connected CN7 (0V) to some wrong terminal.
As a result multiple ICs burned out so hard, that some of the pins welded to pads and PCB (which looks to be 4 layer) alone is going to be a piece of work to recover.

I am capable of carrying out necessary PCB rework but I'm here to ask good folks experienced in DPS circuits about my chances to bring back this module.
What I do not know is whether firmware is going to be an issue.

Attached you may find photo of PCB normal and current condition as well as schematic.
Chips damaged:
K6X4008T1F - RAM, should not be a problem
AK4527BVQ - CODEC, expect no issue
LP3470MS-4.63 - Voltage Supervisor
AT29BV010A - Flash, visually ok, supply not shorted even though sitting on the same 3.3V rail
DSP56364 - DSP, according to datasheet has 8k built-in ROM, which begs the question how it is usually used if at all

Parts are not too easy to obtain and there is a lot of work with PCB itself, so it would be a costly experiment to just start blindly replacing dead ICs.
Normally I do not attempt such endeavors of doubtful benefit, but it's a good friend. So I'd appreciate your input.

Have yet to test flash if it could be miraculously alive and well. If not might have to replace it as well, my friend said he could just manage to bring me identical device for this.
Cloning parallel flash without appropriate universal programmer would be a major PITA, but I believe in own ability to bodge something using general-purpose uC.
But in case of DSP, I have no idea whether internal ROM is used (hopefully not for something like cloning prevention) or could be read back from a working unit. These are the main questions.

[Leeroy]

What I gathered so far is that according to "Using Symphony Studio with the DSP563xxEVM" document, development software uses OpenOCD for debug.
So meaning one could use JTAG to dump ROM and probably even read/write external memory this way without extra programmers?

I have no prior experience with JTAG, GDB and debugging methods associated, but I'm interested as it is a skill I'd want.
So any input even for sanity checking any of my conclusions is wanted, since I'm not really sure what I'm doing here on software side of things.
Any pointers about assembling toolchain necessary for the job?

I made a brief attempt at installing Symphony Studio, but of course there were some errors about Eclipse dependencies and it failed to start on Win10.
At least from installer I see that it was packaged with FTD2xx driver. So my initial though is that I may go ahead and buy common FT232H USB-to-JTAG bridge on AliExpress if all comes to cloning DSP ROM and external flash is not enough on its own.

Not sure if Symphony Studio could be avoided at all, and just use CLI tools for GDB, but "Symphony™ Studio Development Tools" overview document mentions this:
"Debugging is achieved through the GDB (GNU project debugger) debugger interface within Eclipse, which has been customized specifically for the DSP56300 architecture."
So I am probably forced to use it?

Also accoridng to "Using Symphony Studio with the DSP563xxEVM" document there were two programmer options supported in Studio: Wiggler for parallel port and Signalyzer for USB bridge.
This begs the question if I could use Studio with common FTDI programmer and not these, which seem unavailable. It is confusing because there is a mention of FT2232 chip about "Signalyzer" in OpenOCD files.
So which one is meant to be used here with "FTD2xx driver", FT232H / FT2232H?

[Leeroy]

Apparently, it is possible to use GPIO on Raspberry as programmer interface for OpenOCD, which is really cool and predictable, but totally unexpected.
Moreover, DSP563xx is supported as OpenOCD target.

Additionally, I finally came across mention that flash read/write is available in debug mode in "Programming the DSP56300 OnCE and JTAG Ports" Application Note;
as well as example memory maps from "Interfacing EPROM and EEPROM Memory with the DSP56300 Family of Digital Signal Processors".

But that last ApNote also clearly states in 6.2 Disadvantages:
"For new programs or data to be stored in a ROM part, a new ROM mask and new parts must be manufactured.
Then the old parts have to be removed from existing boards."

Which now seems logical, since ROM != (E/EE)PROM. So if they utilized it in this particular Dynacord model, that unit is pretty much hardware bricked.
The question now is, whether I may be able to distinguish some program instructions after reading binary from working unit.
So that I could at least make a decision, if it is worth the time to try cloning external flash without ROM, buying ICs and repairing PCB.

[Leeroy]

I was blind, but now reading DSP User Manual properly,
I see operation modes which define program start address during reset using pins 1-3.
And according to schematic, it looks like in this case DSP boots from external flash.