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.

reconnect to target.

Other Parts Discussed in Thread: BOOSTXL-DRV8301

I'm working on my own "boostxl-DRV8301" hardware. Occasionally I need to change something in the hardware, power it down, and then want to resume my program. 

The program has been flashed into on-chip flash, so re-flashing is unnecessary. The only way I've found to get back my debugging session is to hit the green debug button, but that starts a compile-and-flash cycle that takes a lot of time. The compile is quick enough, but the flash is slowing me down. Can I reconnect to the target without reflashing?

Run->connect target gives me: "device blocked debug access because it is currently running non-debuggable code". Hitting the debug then tells me "allready running" and when I confirm it reflashes and works....

Is there a way to avoid the re-flash?

  • Hi Roger,

    To allow debug access in real-time mode, you can enable "rude" real-time mode, or in other words disable "polite" real-time mode. In menu Run->Debug Configurations->Target tab, under Auto Run and Launch options, uncheck the checkbox for "Enable polite mode".

    Also under Program tab, be sure to select "Load symbols only" instead of "Load program" else it will try to erase and program flash again instead of just connecting to the running target.

    Regards,
    Gautam
  • The "enable polite mode" option is checked... and grayed out. I cannot uncheck it.
    When I set the option to "load symbols only" I can restart the debug session without the load wait. However, I don't get a working debug session. When I hit "run" I immediately get no source available for 3ff5d5, and apparently my processor is halted because the "run" button is not grayed out.
    I managed to do something that resulted in a popup giving me the option of "rude retry", but still no change.
  • Roger check this link for more help: e2e.ti.com/.../923695

    Regards,
    Gautam
  • Hello,
    Do you mean that you want to run the debug mode without erasing and uploading program again to the flash?
    If so, maybe this thread can help you e2e.ti.com/.../179311
    Thank you.

    Best regards,
    Maria
  • Maria, yes, that's what I want. However, disabling certain sectors from being programmed is not going to help me. Hmm. Maybe tell it to program, but then disable all sectors. I'll try that next. 

    Gautam, that helped in un-graying the enable polite mode. But It is still refusing debug access because of protected (boot?) code.

    [update] The "erase sectors" page will allow me to selectively disable erasing certain sectors. Not useful for me as my program spans all sectors as far as I can see. What IS useful on that configuration page is that I can select "verify only" as the programming step. That works, and is a lot faster than the whole erase/program/verify cycle.

    Also, I have to enable "real-time-mode" each time I enter the debugger. I came across the option to do that automatically I think. 

    run->debug configurations -> target -> auto run and launch -> enable realtime mode

    causes my debugger to stop again with the "cannot debug non debuggable code". 

  • Hi Roger,

    It sounds like what you want to do is "Load Symbols"/"Load Symbols Only". 

    What I usually do instead of just pressing the bug button is do each step individually: Launch the debug session, connect to the device, and then Load Symbols.

    However, I believe you can change the default setting for you 'bug' button press to be "Load Symbols Only".  Click the drop down next to the bug and select "Debug Configurations...".  Then once you've selected the target configuration project you're using on the left side of the window, select the "Program" tab.  If you change the Loading Options to Load Symbols Only and hit Apply, I think you'll be able to achieve what you wish.

    Hopefully this helps!


    Thank you,
    Brett

  • Brett, that's indeed what I'd like to do. However, when I select, "load symbols only", the CPU does not come up in a runable state: clicking RUN gets me "no debug info for 3ff5f" or something like that.
  • {Edited my previous message.}

    Some experimentation may be necessary, but I believe you can make it do what you want.

    My guess is that, with what you are doing now, symbols for your project aren't being loaded. 


    Thank you,
    Brett

  • Ok. Guys. I've set the program options back to "erase/program/verify".... and it no longer works.

    In trying/researching this, I've stumbled across a posting by someone who had what I have now: When you change a variable, it pops back to what it was. Also it seems the program is not running when I hit "run" (I change a variable in an interrupt, and the variable remains at what it was).

    Where are my settings stored? I could get my settings file from a backup if I know where it is stored....
  • Hi Roger,

    I think your questions are tilting more toward questions about CCS and how is it working (or perhaps more accurately, why it's not working).  I might suggest opening up a thread there.

    I will say that 'Load Symbols Only' is the feature you were hoping existed at the beginning of this thread.  I know that the method works if you follow a method similar to the one I described in the following as (1):
    https://e2e.ti.com/support/microcontrollers/c2000/f/171/p/328069/1151169#1151169
    (only instead of just clicking on the load icon, you now click the drop-down and select something like 'Load Symbols Only...")


    Thank you,
    Brett

  • You're right. It's a bit offtopic here. 

    I've just figured out what was wrong. Somehow, the "autoupdate" setting usually sticks around, but sometimes it doesn't. I'm used to clicking it once, and then forget about it. 

    When autoupdate is off, changing a variable should not just change it back. That to me is a visual indication that the variable was written to the chip, but then mysteriously changed back. Instead, it should say turn red as in: hasn't been written to the chip because autoupdate is off.