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.

How do I get rid of an Error -1066

Windows 7 service pack 1

Code Composer Studio Version: 5.5.0.00077

Using XDS200

Each time I load the code I get the following:

C28xx_CPU1: If erase/program (E/P) operation is being done on one core, the other core should not execute from shared-RAM (SR) as they are used for the E/P code. Also, CPU1 will be halted to determine SR ownership for the CPU which will run the Flash Plugin code, after which CPU1 will be set to run its application. User code execution from SR could commence after both flash banks are programmed.

C28xx_CPU1: GEL Output:

Memory Map Initialization Complete

C28xx_CPU1: Breakpoint Manager: Retrying with a AET breakpoint

C28xx_CPU1: Trouble Setting Breakpoint with the Action "Finish Auto Run" at 0x9d139: (Error -1066 @ 0x9D139) Unable to set/clear requested breakpoint. Verify that the breakpoint address is in valid memory. (Emulation package 5.1.232.0)

And the PC is set on an ESTOP0 instruction.

What are the steps to resolving this issue?

  • The F28x devices are limited to two hardware breakpoints and you may be exceeding that number. Can you please take a look at this related thread and try the suggestions there?

  • I am aware of the two breakpoint limit. I have no breakpoints of my own set up and I have turned off the CIO function. The problem still persists. When I look at the address that it is saying it is failing to set it is the beginning of main(). I assume it is trying to set a breakpoint there and run the initialization code.
  • Does this error appear when loading any program? Can you try loading a couple of different executables with the same target configuration file and debug configuration settings?

    Gene Falendysz said:
    When I look at the address that it is saying it is failing to set it is the beginning of main(). I assume it is trying to set a breakpoint there and run the initialization code.

    Yes the default behavior is to try to run to main, but you could also disable that in the Debug properties. It might be worth giving that a shot to see what happens. However, with CIO and/or End of program breakpoint disabled, and no other user breakpoint set, it should be able to run to main.

  • Yes the same thing happens if I try to load a different program. If I use this same computer, CCS and XDS200 on different target hardware it works fine.
    It seems to not like the memory space that the program is loaded into. Looking at the memory map for this space (80000-3DFFFF) has R|W|AS2 attributes. Main is at 0x9d139.
  • Are both target boards for the F28377D? Are they custom boards or TI kits?

    Would you mind giving the latest version of CCSv6 (6.1.3) a try? Since there have been many updates to emulation drivers and C2000 support files since CCS 5.5, it is possible that this may not be an issue in the latest version. You can download and install CCS 6.1.3 in a separate directory so as to not affect your existing 5.5 installation.

  • Yes, both boards are F28377D based in fact the one that works is the same hardware version with an earlier firmware version of the same product. There is also an A8 ARM on the board. They are our own custom designs.
    I'm a bit leery of upgrading when it works fine on the other setup.
  • Gene Falendysz said:
    I'm a bit leery of upgrading when it works fine on the other setup.

    I understand your concern, but you can install the latest CCS version to a different directory and just perform some tests without really upgrading your entire development platform. You can simply try loading your existing executable (without rebuild) with CCS 6.1.3 to see if the errors persist. This page describes the manual launch procedure to use. This test could help narrow down if the issue is in the tools or hardware.

    Also as an experiment, could you try modifying your linker command file so the .text section (for main) is placed in a different flash sector, and see if the error still appears?

  • I imported the project into a new workspace and I am able to debug the application. I still get the -1066 errors but they don't seem to be causing me any problems. Earlier I was getting the -1066 error and a reset/restart always brought me to a ESTOP instruction. In the new workspace I still get the -1066 errors but it goes to my main() and I am able to step, run and run to breakpoints.

  • Gene,

    Thanks for the update. I'm not sure why the 1066 errors are still there, but I'm glad to hear that you are now able to get to main and debug your code without issues.
  • Well, it seems I spoke too soon. I have two different board designs with the same chipset and peripherals. On one board all is well, I can download and everything works. On the second board generally it does not write the code. If I load the working board, then move the probe to the other board without exiting the debugger, then the code download works once after a reconnect. Event though I have it configured to erase the flash before programming, when it fails it skips the erase. Does anyone know if there is lockout mode on the flash memory?

  • Gene Falendysz said:
    Does anyone know if there is lockout mode on the flash memory?

    I would suggest posting this question to the C2000 forum as the experts there will be able to provide more comprehensive answers on this.