Regarding the DSA815 with bootloader 1.04 and firmware 1.09, here is a possible temporary solution...
Firstly, these are not the words of a JTAG god, some other folks clever in that department can look for a less intrusive way to what's proposed here.
You need to have a some trial period left for this: it's dependent on taking back a timer when the unit is switched on - look out Marty. Enabling the write protect on the FRAM (U1105) which appears to be a Fujitsu MB85RC16 seems to make this timer reset at each boot. The WP pin is adjacent to VCC, and it's active high, so you can lift pin 7 from the pad carefully and pop a link to pin 8 (VCC).
It may be that pin 7 is left floating or has a weak pull down other than what's in the chip itself, but equally it could well go off somewhere else, so unless there is evidence otherwise, it's probably better to lift the leg off the board rather than just botch solder across the two pins.
Perhaps a microscope should have been used for this, it's not as neat as it looked under the illuminated magnifier apparently.
Notes...
The way it appears to work is that every 10 seconds when it's on it writes to address 0x200 eight consecutive bytes in little endian format. This appears to be a ticker related to a 400MHz clock, so every ten seconds it's incremented by as near as damn it 4 billion. I guess that's why they use an FRAM and not an EEPROM, the endurance of FRAMs can usually be considered infinite for practical purposes. With an endurance of 10^10 write operations per bit, and one write every 10 seconds, it'll last over 3,000 years by my maths.
The way this FRAM works is a bit different to EEPROMS in the way it's addressed, which confused things a little. There is no pin addressing on the FRAM, it responds to all addresses 50 thru 57, and uses these three bits as the MSBs of the 11 bit address required for addressing purposes.
Perhaps by design (i.e., to stop hacking), unusually the I2C SCL is held low by the master during idle time. This prevents a second master jumping in.
Note that there is more than one I2C bus. The test points marked on the board SCL and SDA are for something else completely, don't waste any time looking at these.
It may be also possible to do some microcontroller thing, and indeed that was the original intention, to auto-sniff the I2C bus and pull down SDA at the appropriate time: being an open drain bus, this is entirely reasonable from an engineering perspective.
Folks may be interested to know that I used an MSO1074Z-S to trigger and decode the I2S, and I take back some of the negative comments I've said before about the decoding feature of this series of scopes. Once you've got your head around its limitations, it's not that bad in practice. The event table though, remains useless due to the limited amount of decode it displays.
Caveats: this
may well mean that other things like re-calibration or network settings et al won't save, so I suggest you cal and configure the unit first. I haven't tried changing any non-volatile settings yet. If you're really handy, make an externally accessible jumper. Irrespective, anything that breaks is your responsibility.