• State Resolved
  • Locked Locked
  • Replies 28 replies
  • Subscribers 57 subscribers
  • Views 11800 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC-DEVPACK-DEBUG with IAR results in error "Failed to halt after bootloader 2"

Lucian Copat
Intellectual 430 points
Other Parts Discussed in Thread: CC2650STK, CC2640

So I'm playing with IAR EWARM 7.40.2 with added support for XDS110. Everything seems fine from driver point of view, I can visualize the expected drivers being shown in Device Manager. When I'm trying to load either the Application or the Stack binaries, I get the following error:

"Fatal error: Failed to halt after bootloader 2"

Why is this happening ?

Thanks,

Lucian 

  • 0
    TI__Mastermind 29650 points

    Hi Lucian,

    We have seen this on devices where the customer configuration of the device (ccfg.c )is either missing or incorrect.

    Assuming you are using the SensorTag, did you erase the flash of the device?

    If so, please see the following post: https://e2e.ti.com/support/wireless_connectivity/f/538/t/425368

    If not, can you try to erase the device using Smart RF Flash Programmer 2 and re-flash the original SensorTag hex file? (ble_cc26xx_2_00_00_42893\Accessories\HexFiles)

    Regards,
    Svend

  • 0 in reply to svendbt
    Intellectual 430 points
    When this first happened, I hadn't done anything to the original application on the board. The green LED was blinking while IAR was waiting to flash the application image, and then I received the error. After that, I tried flashing the application .hex file from the output folder, using Smart RF Flash Programmer v2, which worked successfully.

    I did as per your reply, erased the whole flash using Smart RF, then flashed the original .hex file, and now the green LED is blinking again. But I get the same behavior as before, when I try to download and debug the stack project. My project is a copy of SimpleBLEPeripheral sample project, and contains all the files from there. The Application project also contains ccfg_appBLE.c file, which includes the original ccfg.c, so I assume all should be OK here ?

    It looks like while IAR waits for the download to begin, the board does not enter bootloader mode (green LED still blinking in the app).

    Regards,
    Lucian
  • 0 in reply to Lucian Copat
    Intellectual 430 points

    To add one more detail, when I click Download and debug button on IAR, the red LED flashes shortly, then green LED starts blinking, from the original SensorTag application. So I assume red LED is for the bootloader, but looks like it fails to remain in the bootloader and wait for the download.

    LE: I am using SensorTag (CC2650STK).

  • 0 in reply to Lucian Copat
    Intellectual 430 points
    I tried a forced mass erase using Smart RF Flash Programmer, and now the red LED on the SensorTag is always on (I guess this means the bootloader is active). Now downloading the application and the stack with IAR works, but debug doesn't start and I get the following error: "XDS reported an error: Unknown CPU Status". The messages in the debug log are as follows:

    Wed May 27, 2015 21:39:53: Loaded macro file: C:\Program Files (x86)\IAR Systems\Embedded Workbench 7.2\arm\config\debugger\TexasInstruments\CC26xx.dmac
    Wed May 27, 2015 21:40:03: No valid application found in flash. The CCFG field FLASH_IMAGE_VALID is non zero
    Wed May 27, 2015 21:40:03: Initial reset was performed
    Wed May 27, 2015 21:40:04: TI XDS ARM, device revision: 0x00000001, big endian: false, cache: false, board revision: 0x00000000, driver revision: 0x0B020200
    Wed May 27, 2015 21:40:04: Watchdog disabled
    Wed May 27, 2015 21:40:05: 21613 bytes downloaded (13.38 Kbytes/sec)
    Wed May 27, 2015 21:40:05: Loaded debugee: D:\Work\Test\IAR\Application\CC2640\FlashROM\Exe\TestAppFlashROM.out
    Wed May 27, 2015 21:40:09: No valid application found in flash. The CCFG field FLASH_IMAGE_VALID is non zero
    Wed May 27, 2015 21:40:09: Target reset
    Wed May 27, 2015 21:40:13: 0 bytes downloaded (0.00 Kbytes/sec)
    Wed May 27, 2015 21:40:13: Loaded extra image: D:\Work\Test\IAR\Application\CC2640\..\..\Stack\CC2640\FlashROM\Exe\TestStackFlashROM.out, image ID 2
    Wed May 27, 2015 21:40:45: Fatal error: Debug session aborted by user Session aborted!
  • 0 in reply to Lucian Copat
    TI__Mastermind 29650 points
    The SimpleBLEPeripheral project is made for the CC2650EM-7ID + SmartRF06EB board. If you try to flash that onto the SensorTag it will try to write to the LCD which is not existing, probably causing some LEDs to light up.
    On top of that you might end up with driving some pins on non-powered sensors, causing excessive current draw and a corresponding device reset.

    If you want to use the SimpleBLEPeripheral project make sure to disable the LCD by removing the compiler directive TI_DRIVERS_LCD_INCLUDED and change the board file search path to use the SensorTag board file instead of the CC2650EM-7ID evaluation module.

    There is a dedicated project for the SensorTag available that is meant for development on this board.

    Best regards,
    Svend
  • 0 in reply to svendbt
    Intellectual 430 points

    Thanks for pointing that out ! I noticed that after I flash it, the green LED is half lit. Also, my application tries to open the LCD. 

    But it's still strange, that download and debug doesn't work after the original SensorTag application is running on the board. Or is it normal?

    Regards,

    Lucian

  • 0 in reply to Lucian Copat
    TI__Mastermind 29650 points
    From the error message you posted I think this is due to the CCFG area being overwritten by the Application image. Since the linker places an empty ccfg area in the flash last page the previous contents of that page is erased.

    Could you try following the guide I linked to in the very first post (Option A) to see if that solves the problem?

    Thanks,
    Svend
  • 0 in reply to svendbt
    Intellectual 430 points
    I have tried Option A as well, but still with the same error. What I did:

    Mass erase chip
    Flash original SensorTag application with SRF Prog 2 (green LED is blinking)
    Remove definition of FLASH_LAST_PAGE, corrected region FLASH size, remove references to .ccfg area, recompiled
    Tried download and debug with IAR - same error (Failed to halt in bootloader 2)

    I have noticed that download and debug only works when the chip is erased and the bootloader automatically starts. So it looks like Devpack is not able to indicate when it wants to flash the chip, and it doesn't stop in bootloader after a reset. Should I use a custom flash loader ? I just selected the option, but didn't choose a custom one.

    Regards,
    Lucian
  • 0 in reply to Lucian Copat
    Intellectual 430 points

    I somehow managed to get it running. I mass erased the flash, then did some changes from SensorTag project, commented out LCD init function, and now I am able to debug. Also, it enters bootloader next time when I try to download and debug.

    Now it's getting stuck in ICall task, and BLEPeripheral task is not getting to run. Also, debugging is painfully slow...

    LE: Too fast with the conclusion. It still doesn't work all the times...


    Regards,
    Lucian

  • 0 in reply to Lucian Copat
    TI__Mastermind 29650 points
    Lots of details here so I am not fully sure what sequence you have done things in. Anyway, here is the sequence I have used to get it working:

    1:
    Insert battery into sensorTag, connect the CC-DEVPACK-DEBUGGER, plug it into USB.
    2:
    Using Smart RF Flash Programmer 1.6, erase "All unprotected pages" and program simplelink\ble_cc26xx_2_00_00_42893\Accessories\HexFiles\CC2640_SmartRF_SensorTag.hex.
    Green light now blinks on SensorTag.
    3:
    Open SensorTag project in IAR 7.40.2.
    For both projects, goto Project options->Debugger->TI XDS. Select TI XDS110 as the emulator
    4:
    Compile and download stack, exit debugging
    5:
    Compile and download application, run. Green light is flashing on SensorTag and application is running
    Flashing the application image takes around 10secs + 5secs to start the debugging session on my computer.

    From here on I can modify the SensorTag application just fine and download it again without any problems.

    Can you compare this with what you are doing?

    Regards,
    Svend
  • 0 in reply to svendbt
    Intellectual 430 points

    Sorry for the delay.

    I have meanwhile verified that it works in a variation of the sequence you are describing. The key I think is to disable the last block on the flash.

    Best regards,
    Lucian

  • 0 in reply to Lucian Copat
    Intellectual 625 points
    Hello Svend,

    I was having this same issue except I am using my own CC2640 hardware and I am trying to use the Simple Peripheral project. I think I have found the issue. When I have the DebugDev Pack plugged into an USB3.0 hub I get the "Failed to halt after bootloader 2" every time I try debugging the app project. As soon as I moved directly to a USB2.0 port everything works fine. Might this be an issue with the driver not corking correctly on a USB3.0 port?
  • 0 in reply to Ryan Erickson
    TI__Mastermind 29650 points
    Hi Ryan,

    Thanks for the feedback. We will get in touch with our debugger team to have them check this and provide a FW update if needed.

    Regards,
    Svend
  • 0 in reply to svendbt
    Expert 1010 points

    Hello Svend!

    I have the same problem as   and tried to follow your instructions in this topic and https://e2e.ti.com/support/wireless_connectivity/f/538/t/425368 just I use XDS100v3. In CCSv6 flash the device ok, but in IAR I get "Fatal error: Failed to halt after bootloader". 

    Why is this happening ?

  • 0 in reply to svendbt
    Expert 1010 points
    Hello Svend!
    I have the same problem as Lucian Copat and tried to follow your instructions in this topic and e2e.ti.com/.../425368 just I use XDS100v3. In CCSv6 flash ok, but in IAR I get the message "Fatal error: Failed to halt after bootloader".
    Why is this happening ?
    Thanks
  • 0 in reply to svendbt
    Expert 1010 points
    Hello Svend!
    I have the same problem as Lucian Copat and tried to follow your instructions in this topic and e2e.ti.com/.../425368 just I use XDS100v3. In CCSv6 flash ok, but in IAR I get the message "Fatal error: Failed to halt after bootloader".
    Why is this happening ?
    Thanks
  • 0
    Prodigy 50 points
    Hi Svend,

    I have a similar issue.
    I'm working with IAR 7.40, on my own CC13XX board and using a stand-alone JTAG (Olimex TMS320-XDS100v3).
    At first all went well, but when I started testing my board with low power consumption, I got the "Fatal error: Failed to halt after bootloader 1" message. Since then I always get the message, no matter what project I try to burn.
    I am able to erase flash using the flash programmer, but not to download and debug.
    When I use the smartRF EVB as a JTAG, all is well (burning + debugging).
    I tried to follow the work-around suggested, but luck there.

    Why is this happening
  • 0 in reply to Eli Cohen4
    TI__Guru 56345 points
    Hi,

    On your custom board, is the JTAG reset line also connected to CC13xx?
    Can you post your schematics so we can better assist you?
  • 0 in reply to Christin Lee
    Prodigy 50 points

    Christin hello,

    Thank you for the quick respond.

    In our custom board we use the following lines to connect the JTag:

    We connect the relevant lines to the co-responding lines in the emulator, using a 14-pin cable.

    Same connection method is used with the smartRF EVB.

    Thanks,

    Eli

  • 0 in reply to Eli Cohen4
    TI__Guru 56345 points
    Can you probe your reset_n pin to see if a proper reset was executed when you using your own debugger?

    You can also take a look at our XDS100 wiki page.
  • 0 in reply to Christin Lee
    Prodigy 50 points

    Hi Christin,

    Here's a print-screen from scope of all the JTAG line during burning:

    Thanks

    Eli

  • 0 in reply to Eli Cohen4
    TI__Genius 12900 points

    Eli,
    Can you share a zoomed in screenshot of the RESET_N and TCK activity in the beginning?

    TIABO

    Edited

  • 0 in reply to TIABO
    Prodigy 50 points

    Tiabo hello,

    Please let me know if you need a higher/lower resolution (this is 2ms resolution)

    Thanks,

    Eli

  • 0 in reply to Eli Cohen4
    TI__Genius 12900 points

    It's difficult to say as I don't see how long the TCK is toggling after RESET_N is released. My first impression is that the TCK frequency is very low. It may be too low to trigger the halt-in-boot mechanism device needs 8 TCK flanks (a) after the device powers up, (b) before the boot code completes.

    If you use the XDS100v3 on SmartRF06EB (which you said is working) do you see the TCK toggling faster?

    TIABO

  • 0 in reply to TIABO
    Prodigy 50 points

    Hi Tiabo,

    After a discussion with Olimex support it seems that I have connected the wrong PIN from the JTag to the reset IO on board, TRSTn instead of SRSTn.

    What is the difference between the two?

    Thanks anyway for your assistance

    Cohen Eli

  • 0 in reply to TIABO
    Prodigy 40 points

    Hey Tiabo,

    It was a case of using nTRST instead of nRESET. 

    Can you please edit your post? It would be very nice if these unjustified rumors circulate in the search engines forever.

    Thank you,
    Lub/OLIMEX

  • 0 in reply to Eli Cohen4
    Prodigy 40 points
    System Reset (SRST or nSRST = nRESET in TI's naming conventions) - mandatory signal - the SRST hardware signal resets all chips connected to the JTAG adapter, such as processors, power management chips, and I/O controllers. Normally resets triggered with this signal behave exactly like pressing a RESET button.

    JTAG TAP Reset (TRST or nTRST) - optional signal - the TRST hardware signal resets just the TAP controllers connected to the JTAG adapter. Such resets should not be visible to the rest of the system; resetting a device’s TAP controller just puts that controller into a known state.