[SOLVED] CC1310 debug doesn't work in Keil with 6.14a DLL

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] CC1310 debug doesn't work in Keil with 6.14a DLL

    I used CC13xx debug with J-link in Keil for long time with 5.02e version with more Keil versions.
    Recently, I have upgraded J-Link to latest version 6.14a. Unfortunately this "broke" Keil debugging.
    After some time trying to downgrade J-Link I tried downgrading DLL and it helped.
    The question is which version of DLL should I use to have the newest but also working :)
    Other question is what is wrong between Keil and latest DLL... but I have no idea how to trace the root of problem...
    Behaviour description: it seems that flash gets programmed but the code is not executed nor stopped at beginning of main().
    Keil version is 5.22.
  • Hi,

    We are not aware of any issues in the latest version of the J-Link software. Can you please send us a J-Link log file of a session where the issue pops up? How to enable the J-Link log file: wiki.segger.com/J-Link_DLL#Enable_J-Link_Log_File


    Best regards
    Erik
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Here are two log files:
    JLinkLog_502e.txt contains successful start of debug session
    JLinkLog_614a.txt contains unsuccessful debug session; debugger can't reach main function; I tried to stop execution - MCU is processing loop in ROM code; I guess it could be HIB feature of CC13xx ROM code?

    Only DLL version is different. Other parts of debug setup are the same (application MCU+HW, code, J-Link FW, Keil)...

    Is there anything what can I try to successfully use newest DLL version?
    Files
    • log.zip

      (8.93 kB, downloaded 404 times, last: )
  • Thanks for the log-files. The problem is pretty clear:
    V6.14a: PC after reset @ 0x10002F1C (unexpected)
    V5.02e: PC after reset @ 0x00000160 (expected)

    What J-Link does is:
    1. Reset
    2. Perform Download
    3. Reset
    4. Set BP on main
    5. Go
    6. Wait until BP is reached

    In the old version, BP is reached --> CPU halts
    In the latest version, it is not --> CPU runs

    We will check if we can reproduce the behavior here. If reproducible, we will of course fix it. Keep you posted.


    Best regards
    Erik
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • I too am having trouble using a J-Link Ultra+ debugger with a C26xx ARM based core. After a reset or interrupt the uC vectors to 0x10000000. I have verified that this happens while using code development software from IAR Embedded Workbench, as well as Keil's uVision. The uC vectors to the the same erroneous location with both software packages.

    Upon further investigation, I've found that the VTOR register within the uC is modified to 0x10000000 during a reset while using the J-Link debugger. I've also verified that the VTOR register is NOT modified during a reset while using Spectrum Digital's XDS200 debugger. The VTOR register appears to only be modified while using the J-Link debugger, and I cannot find any startup or config file that could otherwise be modified to prevent this from happening.

    Any advise on how to comment out the VTOR modification during a reset would be appreciated.

    Thanks,

    - MJK
  • I can confirm that it is not possible to reset CC1310 while debugging. I tried it in Keil and in GDB ('monitor reset') but it doesn't work; it always ends in ROM loop waiting for anything (HIB?)

    BTW, is there any progress testing/fixing DLL 6.14a?
  • Hello,

    Sorry for not getting back to you regarding this earlier. Crazy weeks due to Embedded World and some other open projects...I will try to allocate some resources in the J-Link department in the beginning of next week to investigate this behavior. We are pretty sure that if we are able to reproduce it, we can provide a fix short term (if necessary).

    Keep you posted.

    Best regards
    Erik
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hi,


    sorry for the delay in response.
    Unfortunately, I was not able to reserve a time slot for this issue due to other projects with had to be finished first.
    I have an idea on what causes this issue.

    Could you please check if it does work for you with V512j and does not work for you with V512k?

    The old versions are temporaly available here:
    download.segger.com/Niklas/Setup_JLink_V512j.zip
    download.segger.com/Niklas/Setup_JLink_V512k.zip


    Best regards,
    Niklas
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hi Hynek,


    Sorry for not getting back earlier and thanks for the feedback.
    I will try to reserve a time slot for this issue this week.


    Best regards,
    Niklas
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hi,


    could you please execute the following commands in J-Link Commander and post the results here?
    - mem32 0x0001FFA8 16
    - mem32 0x50003FA8 16


    Best regards,
    Niklas
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Here is J-Link window content copy:

    Source Code

    1. J-Link>connect
    2. Device "CC1310F128" selected.
    3. TotalIRLen = 10, IRPrint = 0x0011
    4. AP-IDR: 0x24770011, Type: AHB-AP
    5. AHB-AP ROM: 0xE00FF000 (Base addr. of first ROM table)
    6. Found Cortex-M3 r2p1, Little endian.
    7. FPUnit: 6 code (BP) slots and 2 literal slots
    8. CoreSight components:
    9. ROMTbl 0 @ E00FF000
    10. ROMTbl 0 [0]: FFF0F000, CID: B105E00D, PID: 000BB000 SCS
    11. ROMTbl 0 [1]: FFF02000, CID: B105E00D, PID: 003BB002 DWT
    12. ROMTbl 0 [2]: FFF03000, CID: B105E00D, PID: 002BB003 FPB
    13. ROMTbl 0 [3]: FFF01000, CID: B105E00D, PID: 003BB001 ITM
    14. ROMTbl 0 [4]: FFF41000, CID: B105900D, PID: 003BB923 TPIU-Lite
    15. Found 2 JTAG devices, Total IRLen = 10:
    16. #0 Id: 0x4BA00477, IRLen: 04, IRPrint: 0x1, CoreSight JTAG-DP (ARM)
    17. #1 Id: 0x2B9BE02F, IRLen: 06, IRPrint: 0x1, TI ICEPick
    18. Cortex-M3 identified.
    19. J-Link>mem32 0x0001FFA8 16
    20. 0001FFA8 = FFFFFFFF FFFBFFFF FFFFFFFF FFFFFFFF
    21. 0001FFB8 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
    22. 0001FFC8 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
    23. 0001FFD8 = C5FF07C5 FFFFFFFF FFFFFFC5 FFC5C5C5
    24. 0001FFE8 = FFC5C5C5 00000000 FFFFFFFF FFFFFFFF
    25. 0001FFF8 = FFFFFFFF FFFFFFFF
    26. J-Link>mem32 0x50003FA8 16
    27. 50003FA8 = FFFFFFFF FFFBFFFF FFFFFFFF FFFFFFFF
    28. 50003FB8 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
    29. 50003FC8 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
    30. 50003FD8 = C5FF07C5 FFFFFFFF FFFFFFC5 FFC5C5C5
    31. 50003FE8 = FFC5C5C5 00000000 FFFFFFFF FFFFFFFF
    32. 50003FF8 = FFFFFFFF FFFFFFFF
    Display All


    BR,
    Hynek
  • Hi Hynek,



    I was able to reproduce the described behavior if the IMAGE_VALID_CONF register (Offset FEC) is 0xFFFFFFFF.
    In this case, the target application does not run after a power-on reset or a reset command with V5.12k or higher, but it does run after a reset command with V5.12j or earlier.

    However, in your case, IMAGE_VALID_CONF is correctly configured to 0.
    If no debugger is connected, does your application run after a power-on reset?

    One further question:
    The BL_CONFIG Register (offset FD8) is configured to C5FF07C5.
    This means the boot loader backdoor is enabled -> the device will be stuck in boot loader if the DIO07 pin is high.
    Is this configuration intended?

    Best regards,
    Niklas
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Dear Niklas,



    bootloader backdoor is enabled intentionally. This signal contains external 10k pull-down.

    When no debugger is connected, is runs normally.



    Then I did tests on more HWs with CC1310 and found that used pull-down
    is not always working reliably. It probably depends on chip parameter
    variations.

    There are two problems with bootloader pin:

    - TI haven't mentioned using internal pullup for this pin until February (newest
    RefMan); and this note is not mentioned in revision history so I haven't
    known this until now

    - TI presents typical values for internal pull-ups/downs only so I can't calculate which value would be safe for all devices



    To be sure I used lower pull-down value (4k7) which works reliably with all HWs tested.

    But even with this new pull-down value, J-Link still doesn't start in
    Keil always successfully. Sometimes it directly goes to application
    without break in main, sometimes it remains in ROM on WFI instruction.



    BR,

    Hynek
  • Hi Hynek,


    could you please provide us with a reproduction project for Keil MDK, which works on an eval board for the CC1310, e.g. the CC1310 launchpad?
    Please understand that without being able to reproduce the issue that you are facing, there is not much we can do.


    Best regards,
    Niklas
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Unfortunately, I don't have Launchpad. I can use SmartRF06 Evaluation board if it will be also usable for You.
    It will also take some time to extract the bare minimum of code as example project...

    BR
    Hynek