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: TIMAC

Hi,

I just wanted to bring to your attention a problem that we had with the CC2538 and IAR 8.20.

Just to recap what the problem was:

We had a project that was based on the TIMAC stack 1.5.2 and we were using IAR 7.40 with a Segger J-Link Ultra+ debugging probe.

A new developer came in and upgraded the project to IAR 8.20 (8.20.1.14188). Everything seemed to work fine, but after some time, the boards would get stuck in a hard fault without ever going through the main.

You can see this thread for more information:

I was going through the assembly instructions and comparing with a functioning board. I was trying to figure out what was going on, and doing so, I bricked another board with some weird debugger message.

I recalled that we had used IAR 7.40 and tried to load the PER tester FW available on your site. I was surprised, but the board started working. I was even able to go back to IAR 8.20 and debug my other project.

We had 4 boards that appeared to be bricked, and we have been able to "revive" 3 of those boards using the same method. We kept one if you wanted to "inspect" it.

We will revert our project to IAR 7.40, but is there something that can be done to get the latest IAR version working.

Regards,
Michel

  • Hi Michel,

    I am currently attempting to loop in someone who can address the issue you are experiencing between IAR versions.

    Regards,
    Ryan
  • Hi Michel,

    This is still being investigated internally. Have you found a solution or gotten into contact with IAR support?

    Regards,
    Ryan
  • Hi Ryan,

    We have gotten in touch with IAR with no leads yet. We're still in communication.

    My colleague has been exchanging with through email.

    In the last communication, Darren has requested to upload our project to try to reproduce the problem. But as mentioned, the phenomenon only occurs once in a while, so I am not sure how easily this can be reproduced.

    Should we continue through email with Darren, or through this forum?

    Regards,
    Michel
  • Hi,
    In the release notes for the SDK we specify with which IAR version the SDK was tested as well as mention that the SDK projects might not work with different IAR version.

    Regardless of this, I believe this could be happening because the "Valid Image" bits in the CCA(Customer Configurable Area) page might be getting flashed in a different place in flash.
    See section "8.6 Flash Lock Bit Page and Customer Configuration Area (CCA)" of www.ti.com/.../swru319c.pdf

    Check that "__cca" in "startup_ewarm.c" is placedin the correct address when using a different version of IAR

    Regards,
    Hector
  • Hi Hector,

    I'm not in the office so I'll check tomorrow morning, but if the __cca was incorrect, it would brick the device every time we ran the debugger. Unless my understanding is incorrect. In our case, the problem happens randomly because we can debug properly for a few days, and after a while, the device always falls into a hard fault. And we can't seem to be able to reproduce it at will.

    Could it be that IAR 8.20 would not program these bits every time the debugger starts?

    I'll update this forum after I verify the address in startup_ewarm.c.

    Regards,

    Michel 

  • Hi Michel,

    Have you been able to debug further?

    Regards,
    Ryan
  • Hi Ryan,

    We have just found the problem.

    The selected device in the project options was not correct. We copied a previous project which used the CC2538NF23. The EVM uses the CC2538SF53. The main difference being the size of the flash.
    We first changed the device in the project, however, that did not fix the problem. Since the main difference is the size of the flash, I thought there might some difference in the linker file.

    There is a define for FLASH_CCA which is the location of the CCA (where the valid bit is). Therefore, we never wrote to the CCA since our configured device did not have the correct address.

    Thank you all for your help and I apologize for taking all this time. This issue has been going on for a long time now.

    Michel