• State TI Thinks Resolved
  • Locked Locked
  • Replies 18 replies
  • Answers 2 answers
  • Subscribers 54 subscribers
  • Views 4318 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CCS/CCSTUDIO-TM4X: Another "CORTEX_M4_0: Error: Stat [ JLINKARM_IsHalted() call ] failed!" problem

Dave Hohl
Expert 2315 points

Part Number: CCSTUDIO-TM4X

Tool/software: Code Composer Studio

I have a similar problem as described in the thread at https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/618900. That thread seems to be locked now, without any resolution being provided. I was wondering if anything was discovered regarding this issue.

I am running CCS 8.0.0.00016, using a Segger j-link plus. I am using the TI DK-TM4C129X dev kit.

Thanks,

Dave

  • 0
    TI__Guru**** 168297 points
    Dave,

    The issue with the attached thread was never reproduced locally, but unfortunately I forgot to update it in time.

    With this, I really suspect the code may be playing a role in the error messages - if the debug probe is trying to halt the device in the middle of a peripheral access or some non-interruptible code, the debug probe will be unable to halt it. This sometimes happens even with the ICDI Debug probe, where the message "Cortex_M4_0: Error: Debug port error occurred." can be shown at apparent random times.

    Do you have an example code that is able to cause this issue constantly?

    At any rate, I will inform Segger about this thread and see if they have any additional comments to it.

    Regards,
    Rafael
  • 0 in reply to desouza
    Expert 2315 points
    Hi, Rafael,

    The error message does not occur all the time, so I cannot consistently reproduce it. However, when it did happen, it was after stopping at a breakpoint in that Micrium RTOS code that I posted a link to in the thread I created regarding the Segger debugger not setting the CONTROL register properly. I was setting a breakpoint at line 246 of os_cpu_a.asm to check the value of the R1 register. After running from there, I would often get the debugger message. You might be able to reproduce the issue using that code.

    Regards,

    Dave
  • 0 in reply to Dave Hohl
    TI__Guru**** 168297 points

    Dave,

    Sorry about the delay; I followed up with Segger about this particular error.

    I was able to reproduce both issues (the one in this thread and the one in the linked thread) and my strong suspicion is that it is a combination of factors between the application and the JTAG Debug Probe - the application may be jerking the JTAG communications either by changing PLL clock settings or by entering an exception. I captured one instance of the event (after halting at the breakpoint at linke 246) in the picture below.

    The reason of my suspicion is that the same happens with the built-in ICDI connection, although very infrequently - I couldn't capture a screenshot of the Debug Port error I mentioned previously in this thread. 

    I will wait for Segger's additional comments on the matter. 

    Regards,

    Rafael

  • 0 in reply to desouza
    Expert 2315 points
    Thanks for the update, Rafael. AFAIK, the app does not change the PPL clock. It should get set early on and not altered again.

    Regards,

    Dave
  • 0 in reply to Dave Hohl
    TI__Guru**** 168297 points
    Dave,

    Thanks for the clarification; I will see if Segger can provide me information to get some useful logs - they got back to me and mentioned they are still backed up but your two threads are still under their radar.

    Regards,
    Rafael
  • 0 in reply to desouza
    Prodigy 30 points
    Hi Rafael,

    Can you please create a J-Link log file representing a "bad" session?
    How to enable the J-Link log file: wiki.segger.com/J-Link_DLL

    We are busy this week with some other projects / inquires but plan to have a look at this next week.

    Best regards
    Erik
  • 0 in reply to user3777010
    TI__Guru**** 168297 points
    Erik,

    Please apologize for the delay; I just sent you a log via e-mail.

    Dave,

    If possible, would you mind attaching a similar log to this thread as well? This way Erik will have more information to track this.

    Regards,
    Rafael
  • 0 in reply to desouza
    Expert 2315 points
    I used J-Link to configure the log file, but I do not see any file getting created when I run the debugger. I tried to find a way to enable the log file from within CCS, but did not see anything. Is it possible to do from the IDE?

    Regards,

    Dave
  • 0 in reply to Dave Hohl
    TI__Guru**** 168297 points

    Dave,

    No, it is not possible to do it from the IDE; Segger uses their own protocol SW that performs the logging.

    The instructions worked fine for me - are you writing the log to a directory with read/write permissions?  

    Regards,

    Rafael

  • 0 in reply to desouza
    Expert 2315 points

    I changed the folder to a temp directory, and now the log file is showing up. However, after starting and ending a debug session, the file did not update with any new information. The only contents are:

    T2640 070:178 SEGGER J-Link V5.00 Log File (0000ms, 0000ms total)
    T2640 070:178 DLL Compiled: Jun 8 2015 21:22:48 (0000ms, 0000ms total)
    T2640 070:178 Logging started @ 2018-05-03 11:32 (0001ms, 0001ms total)

    Is there something I need to do besides running the debugger and executing the code? I even tried exiting CCS and that did not do anything.

    Regards,

    Dave

  • 0 in reply to Dave Hohl
    TI__Guru**** 168297 points

    Dave,  

    Between the start and end of the debug session, did you follow the procedure that throws the error? If so, the log should have much more information. We will need the help of Segger to try and identify what may be happening in your case.

    Just for reference, the log I captured follows attached. Line 95 is the one where the error is thrown.

    Regards,

    Rafael

    jlink_TM4C1294.rar

  • 0 in reply to desouza
    Expert 2315 points
    I set the breakpoint and tried repeating many times, but I was not able to reproduce the error any more. My code has changed quite a bit since the initial report, so that might be affecting it. But problem with the RTOS-related code (reported in the related thread) is still occurring. It's just that I am not getting the J-Link error any longer when I try to run after the breakpoint.

    Regards,

    Dave
  • 0 in reply to Dave Hohl
    TI__Guru**** 168297 points
    Dave,

    The issue in the related thread (mentioned in your first post) seems to be related to PLL changes and not RTOS changes. Perhaps I am missing yet another thread you posted?

    Regards,
    Rafael
  • 0 in reply to desouza
    TI__Guru**** 168297 points
    Dave,

    The lack of updates make me believe you got past the RTOS error you mentioned above. I will then close this thread but please feel free to reopen it if the issues are still happening.

    Regards,
    Rafael
  • 0 in reply to desouza
    Expert 2315 points
    The post I linked to was seeing the problem when trying to set the PLL, but I was getting a similar error message when running after manually changing a register value while halted in RTOS code. There were two Segger-related issues -- not setting the CONTROL register correctly (detailed in a separate post) and the J-Link error message after manually changing the register. So far Segger has not responded to either issue as far as I can tell.
  • 0 in reply to Dave Hohl
    TI__Guru**** 168297 points
    Dave,

    Thank you for reporting back; before I replied here I brought your threads again to their attention by directly writing to their support e-mail.

    I will monitor their responses and report back.

    I apologize for the inconvenience,
    Rafael
  • 0 in reply to desouza
    TI__Guru**** 168297 points
    Dave,

    I received a note from Segger that they were severely backed up but have your inquiries on their backlog.

    Also, they confirmed it is preferred to contact them directly so they have better monitoring capabilities.

    Regards,
    Rafael
  • 0 in reply to desouza
    Expert 2315 points

    Thanks for the update, Rafael.