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.

CC2538: Stuck in bootloader

Part Number: CC2538
Other Parts Discussed in Thread: Z-STACK, SEGGER

Hi guys,

I have a problem with a CC2538 evaluation module (I am using the SmartRF 06 evaluation board and the on board XDS 100v3 debugger).

My issue is the following: when I enter a debug session the microcontroller doesn't go to main() but is executing code in the ROM area (which is, I suppose, the bootloader code). However the backdoor for the bootloader is disabled in my code and seems to be disabled on the chip, as you can see below:

The PC points to these addresses when I start a debug session :

I tried the reprogram the chip several times, and I always have the same problem (but it was working before the problem occurred), thanks to the SmartRF flash progammer, I tried to erase the chip and I also tried the "Force Mass Erase" option and I reprogrammed the chip after but I still have the same result.

The exact same code is working very well on another evaluation module (with the same evaluation board).

Is anybody have a solution ?

Thanks

  • Hi,

    What code are you running on your device?
  • Hi Jason,

    the code running on the target is our firmware.
    Regards
  • Okay, but is it based off of any of our software examples? Like the CC2538 Foundation Firmware, Z-Stack 3.0.1, TI-MAC 1.5.2, etc.
  • Ah, I missed the part where you said it works fine on other EVMs. You could try using this program to "un-brick" the device. I am not sure it will help but you can give it a shot:

    e2e.ti.com/.../1948411
  • Our firmware is based on the TI MAC 1.5.2.

    I tried the CE with the console, I don't have any error displayed but here is the log of the Console application :

    Log start: Tue Dec 12 16:04:03 2017
    FlashDevice::FlashDevice()
    FlashDeviceCC2538()
    FlashDeviceCC2538::libInit() All libraries loaded with success.
    FlashDeviceCC2538::apiInit() API function calls loaded successfully.
    FlashDeviceCC2538::massErase()
    Executing system(me.bat components\traceprobe_72\scripts\icme >NUL).
    FlashDeviceCC2538::reset()
    FlashDeviceCC2538::isConnected()
    FlashDeviceCC2538::disconnect() m_iCtx.hpid == 0: Not connected to target. Skipping GTI_DISCONNECT() and GTI_QUIT()
    m_iDap.hpid == 0: Not connected to target. Skipping GTI_DISCONNECT() and GTI_QUIT()
    m_iIce.hpid == 0: Not connected to target. Skipping GTI_DISCONNECT() and GTI_QUIT()
    Target disconnect and session termination successful.
    ~FlashDevice()
    Log end: Tue Dec 12 16:04:06 2017

    Regards
  • Is there anything else I ca tried in order to unbrick the device ?

    Regards,

    Pablo

  • Hi Jason,

    With the information provided previously, is there anything else I can try to unbrick the device ?

    Thanks
  • If this issue is only happening with one EVM I suspect that there may be some hardware issue, aside from force mass erasing it with Flash Programmer 2 or using ArmProgConsole to unlock the JTAG interface, there aren't any other software-related fix options I could recommend for these devices.
  • Hi,

    The same problem happen with another evaluation module, it happened during normal operation (programming with IAR and Segger J Link Ultra +), the program operation were not interrupted and the previous debug session was ended normally. I also tried to use the XDS100 present on the SmartRF06 but it didn't change anything.

    I tried to Mass erase the device using Flash Programmer 2, and ArmProgConsole.

    Here is the log of the ArmProgConsole execution:

    Log start: Wed Feb 28 08:55:03 2018
    FlashDevice::FlashDevice()
    FlashDeviceCC2538()
    FlashDeviceCC2538::libInit() All libraries loaded with success.
    FlashDeviceCC2538::apiInit() API function calls loaded successfully.
    FlashDeviceCC2538::massErase()
    Executing system(me.bat components\traceprobe_72\scripts\icme >NUL).
    FlashDeviceCC2538::reset()
    FlashDeviceCC2538::isConnected()
    FlashDeviceCC2538::disconnect() m_iCtx.hpid == 0: Not connected to target. Skipping GTI_DISCONNECT() and GTI_QUIT()
    m_iDap.hpid == 0: Not connected to target. Skipping GTI_DISCONNECT() and GTI_QUIT()
    m_iIce.hpid == 0: Not connected to target. Skipping GTI_DISCONNECT() and GTI_QUIT()
    Target disconnect and session termination successful.
    ~FlashDevice()
    Log end: Wed Feb 28 08:55:06 2018
    

    Obviously the flash erase and program operation are successful (I am still able to read the flash and I see correct values, all 0xFF when erased and consistent values when programmed). But the device stay stuck in the bootloader ROM code when I start an debug session (and is not working obviously when no debugger is attached).

    Is there really no solutions ?

    I have some fears about integrating this chip in our design if the reference design and the programming tools are not reliable.

    Please, provide us a solution.

    Best regards

  • Pablo,

    Did you find a solution to this issue? if not, can you help us re-create the issue in on one of our development kits? My only guess could be noise on the JTAG line or the other line during bootup.

    Regards,
    /TA