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.

CC2640 Fatal error: Failed to do go: (Error -2134 @ 0x0) Unable to control device execution state.

Other Parts Discussed in Thread: CC2640, CC2650

The nature of the problem is that I am receiving this error using IAR when trying to invoke the debugger: "CC2640 Fatal error: Failed to do go: (Error -2134 @ 0x0) Unable to control device execution state." 

Conditions:

  1. Using IAR IDE as a developing environment.
  2. Using the XDS100v3 debugger on the Smart Rf 06 eval board as a debugger.
  3. The debugger is interfacing to a new pcb with the CC2640 5x5 running on it.
  4. Using the simplePeripheral project as a baseline for firmware. Targeting the cc2640 5x5 chip.
  5. Able to build with no errors or warnings
  6. Able to flash both the stack and application images successfully.
  7. The above error appears when I try to invoke the debugger itself. 
  8. Power supply voltages look good.
  9. The 'reset' line to the cc2640 is high - never goes low.
  10. Using cJTAG mode in IAR for flashing and download.
  11. Tried forcing a 'mass erase' using the SmartRF Flash Programmer2 software.

Interesting Notes:

  1. If we mount a CC2650EM board (7x7 device) on the Smart RF 06 eval kit - we can both flash the device and use the debugger without having a problem.
  2. I'm not convinced the 24Mhz xtal is running. If this xtal is not running - would that cause the problem? Shouldn't the internal oscillator be running?
  • Moving to CC2640 Forum for better support.

    Regards,
    JH
  • A subsequent piece of information that we stumbled on may provide a clue as to what the problem is:

    The development environment is split into 2 projects - one for the BLE stack, the other for the application. We have always built and downloaded the stack project first, then built and downloaded the application project 2nd. Then tried to start the debugger (this is the part that doesn't work).  However - one time we built and downloaded the stack and invoked the debugger on just the stack project. The development tool (IAR) has a few complains that it couldn't find 'main'  - then the debugger appeared to start working on the new board with the CC2640. I could step thru code etc.

    When we stepped back and tried this with the application project - again we received the 'cannot gain control of the processor' error.

    This kind of validated a could of things to me: 1) The fact that we can invoke the debugger on the new board running the BLE stack alone means that our HW set-up is OK. I.e. - clocks are running; chip is powered ok, connecting harness is ok, etc. 2) The fact that we can get the debugger to work on the cc2650EM board and not work on the cc2640 board when running the full application implies that there is something wrong with the project environment. Other than changing the target device at compile time - is there any other 'switch' that needs to be thrown that might impact if the jtag interface works?

  • E. Boris,

    have you referred to the BLE developer's guide? As you already noticed, there is a application project and a stack project. You need to flash both components to get a working BLE solution.

  • Correct. My question is more about the debugger. On the cc2650EM it works correctly. The BLE solution is working ie. advertising and connecting. However - on the CC2640 the part flashes correctly - but the debugger won't start. That is what I am trying to find out. What are some possible things that might prevent the debugger from working when going from the cc2650 to the cc2640?
  • I double checked the BLE Developers Guide without much help. There are a few items in there about how to use the debugger after it is up and running - but not much about what could be wrong if your debugger is not up and running.
  • Are you using the other board files?

    When switching from a 7x7 to a 5x5, you need to change the include search path:

    From:

    $TI_RTOS_DRIVERS_BASE$\ti\boards\SRF06EB\CC2650EM_7ID

    To:

    $TI_RTOS_DRIVERS_BASE$\ti\boards\SRF06EB\CC2650EM_5XD

  • Hi there,

    In addition to Tom's suggestions about the 5XD board file. I will issue a word of warning about this file that will cause the behavior you are seeing. Since you are able to load and debug the stack project, I think it is safe to assume that you hardware is okay. However, when using the 5XD board file, there is a risk that the application will crash before main.

    There are some required changes to the board file to get around this, please see this thread.
    e2e.ti.com/.../420803