This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS 3.3 Flash API Error



Hi,

 I'm running CCS 3.3.82.13 with a 334 target system and a SD 510pp JTAG emulator. When I first go to program after opening CCS, I frequently get API errors when programming, such as the following:

Trouble Writing Memory Block at 0x9040 on Page 0 of Length 0x800: Error 0x00001002/-1156 Error during: Memory, Target,  Lost processor clock. Device may be operating in a low-power mode.  Do you want to bring it out of this mode? 
Trouble Writing Memory Block at 0x9000 on Page 1 of Length 0x1: Error 0x00001002/-1156 Error during: Memory, Target,  Lost processor clock. Device may be operating in a low-power mode.  Do you want to bring it out of this mode? 
Trouble Writing Memory Block at 0x9014 on Page 1 of Length 0x2: Error 0x00001002/-1156 Error during: Memory, Target,  Lost processor clock. Device may be operating in a low-power mode.  Do you want to bring it out of this mode? 
Trouble Writing Memory Block at 0x9012 on Page 1 of Length 0x2: Error 0x00001002/-1156 Error during: Memory, Target,  Lost processor clock. Device may be operating in a low-power mode.  Do you want to bring it out of this mode? 
Trouble Reading Register: Error 0x00001004/-1041 Error during: Register, Target,  Device driver: Problem with the Emulation Controller. It is recommended to RESET EMULATOR.  This will disconnect each  target from the emulator.  The targets should then be power cycled or hard reset followed by an emureset and reconnect to each target. 
Failed to remove the debug state from the target before disconnecting.  There may still be breakpoint opcodes embedded in program memory.  It is recommended that you reset the emulator before you connect and reload your program before you continue debugging.

 

Multiple disconnect/reset emulator/connect and programming retries result in the same problem.

Immediately after getting this failure, if I open SDConfig and run the diagnostics using test loops of 0 (continuous run), I don't get any failures after letting it run for a while (sample dump below). These results seem to indicate my hardware is working and there's really not any clock issues as stated in your CCS API error message.

 

** Checking for a valid emulator/eZdsp
** Running diagnostic scan on EmuProductName=XDS510PP

** Checking emulator/eZdsp scan connection

Performed 286 test loops with 0 errors.

 

Then if I go back to CCS and try programming, everything works fine for the rest of the day! What could be the problem?

 

Thank you,

Bob

 

  • Hi Bob,

    It could be an issue with the TCK of JTAG of the emulator.

    When you run SDConfig, then scan tests in continuous loop run at a pre-defined JTAG frequency, usually lower frequency. So they might be running correctly.

    I dont remeber exactly, but XDS510PP emulator might be having a section of changing the default TCK. Setting a lower frequency may help in solving continuous errors like this at start-up.

    Regards,

    Sid

     

  • So are you suggesting that running SDConfig changes the clock frequency so that when I go back to CCS it's lower and that's why it works? This doesn't make sense since once programmed, my application runs and sets the clock and PLL for 150MHz. I can then program (after running) just fine.

     

  • Hi Bob,

    Its not the system clock I am speaking about. Its the TCK (JTAG clock) that I am referring to

    All the errors you are poitning to are emulator related errors which generally arise due to CRC/ similar errors in emulator operation and two of the most important factors responsible are TCK and TRST becasue these control the JTAG scan chain of the emulator.

    Regards,

    Sid

  • That makes sense, but I don't see any option to change the TCK speed. The only option I see in SDConfig is for emulator port speed which inserts read delays between the PC and the parallel port.

    The emulator pod manual does refer to the TCK coming from the POD at 10MHz. I have this tied to TCK_RET on my board. The manual also states that "You may also provide your own test clock for greater flexibility" but I'm not doing that. TCK speed is fixed in my system at 10MHz from the pod.

     

  • Well, you are using XDS510PP emulator which is quite old. XDS510 USB emulator and XD100V2 USB emulator are newer versions and they have the option of a variable TCK available.

    Probably, this might be a bug in the XDS510 PP which might have been resolved in the newer version.

    Regards,

    Sid

  • Anyone from Ti care to comment?