We are developing on an ADSP-SC589 (custom hardware), and uncovered what looks like a possible bug in the CCES (V2.8.3) / ICE1000 (V1.1) Emulation - or maybe I am missing something.Using 'Secondary' DAG registers (switched via flags in the MODE1 register) within an assembler function called from C.It appears that if an ICE1000 Emulator breakpoint is positioned at the "bit set MODE1" instruction, once the program continues the data in i0 primary and secondary registers somehow becomes swapped.I can't see any way internally the SHARC could be swapping the contents of the registers, so I'm beginning to believe it must be the ICE1000 emulation causing the corruption.Example project attached to demonstrate the problem (with step-by-step instructions to recreate).Could someone please confirm whether this is genuinely a problem with CCES / ICE1000 or are we getting something wrong? (We've been using ADSP21369 in VisualDSP++ & an ADZS-USB-ICE for years without problems)
Currently we are in the position of being unable to use DAG0 in our project as every time we use the debugger there's a high chance of i0 data becoming corrupted, and thus the system becomes unstable - making further debugging impossible.ADSP-SC589_i0_CORRUPTION.zip
I apologize that this has not been answered. I have no idea how it got missed but I will look at this today.
Apologize for the inconvenience caused. We are not able to reproduce the issue as per the steps mentioned in your attached project.
1) We have tested the code. When control goes to BP-2 at line 52, we are not getting similar data as yours( "MODE1.SRD1L=1","I0(primary)=0x0802C001" and "I0'(secondary)=0").2) As per the instruction if we run the line:42, the code needs to go to line:52. But while we are trying it is going to "carry on(if we place a BP-3)" subroutine.
While looking into the code we are suspecting, because of enabling and disabling the secondary DAG in mode1 register, the index register value is switched from primary DAG to secondary DAG and vice versa.
Could you please help us to simulate the issue in our end. This will be helpful for us to proceed further.
Best regards,Santha kumari.K
The issue will only happen if starting out in code where the inactive/active registers are set one way in the application using the mode 1 register and then halting with them set differently. For instance the issue will not be seen if running from the nop prior to setting mode 1 because first in the emulator we do a single step and then run. Provided we don't break in with a halt or breakpoint while the inactive dag register bit is set then everything is fine. If you step from the set mode 1 instruction, then we do a single step that causes the inactive/active mode to change. This will be an issue. We are looking into a solution for this.
I believe I have found a fix for this issue. If you would like to get an early version of this change please email email@example.com. Let them know the link to this issue and that you would like the emulator fix for it. Otherwise we plan to get this in one of our next releases.