Search Results

Does the code build? If yes, Can you download it? If yes, Does it run? Can you use the debugger to see what's happening ?

can you be more specific? eg, link to the GCC documentation of that option

Look on the list of Supported CPUs: segger.com/products/debug-prob…pported-cpus-and-devices/ For ARM, there is a common standard debug interface (SWD or JTAG) on all their Cores - so a J-Link should work with anything ARM-based.

that's pretty much what Nordic do.

certainly, Nordic's use of RTT with Sleep ensures that the RTT is "finished" before going to sleep ...

Quote from satheesh: “From the Error I understood that there is a multiple definition and I need to get rid of one ” community.arm.com/developer/to…rror-l6200e/162495#162495 You're welcome. Please be sure to update that thread to point here - so that anyone else there will be able to find the resolution here. And mark that thread as Resolved.

Quote from MWet123: “how can I exclude single files from building? ” In the Project Explorer: 1. Right-click the file 2. Edit Options ... 3. Code > Build > Exclude From Build forum.segger.com/index.php/Att…e01a9d9dbb3ad90a0327f62ce

Quote from TxCodeMonkey: “make those variables in question volatile (and or static). ” Yes - that can help. Another option is to simply turn off optimisation!

Where, exactly, do you get that error? Which file does it apply to? Copy & paste the full text!

Duplicate: forum.segger.com/index.php/Thr…tview-widget-skin-problem

Is that actually a GCC thing, or just a 3rd-party library? This pubs.opengroup.org/onlinepubs/7908799/xsh/regex.h.html ? EDIT See: stackoverflow.com/questions/30…ch-file-or-directory?lq=1 - suggests this is not a compiler thing?

Quote from samsam: “Locals Window in debug mode is useless ” I disagree. Sure, as with any tool, it has limitations. It is important to understand the tools you're using.

Thanks for the reply. Use of sleep mode hasn't changed, so that leaves the illegal memory access. That is possible; is there a way to catch it - rather than the debugger just "disappear" completely without trace? But shouldn't illegal memory access be caught as a Hard Fault?

Quote from SEGGER - Nino: “when moving from one toolchain to the internal ones of Embedded Studio we recommend to do this manually ” I would second that - not just for SES, but for any IDE !

Hmmm ... now a new behaviour: The RTT trace has stopped, the Target has restarted - but the J-Link is still showing as 'Connected' so the SES Debug view is still there, but doing nothing. BTW This is SES 3.40 and a Nordic nRF52832. It's only started since recent code changes - but what could my code be doing that would break the debug connection and/or stop the RTT trace ?

OK, so I found the option to enable a J-Link Log file. In the log file, I see this pattern repeating: Source Code (12 lines) which, I guess, is the J-Link polling for RTT data? Towards the end of the log, it changes to: Source Code (10 lines)which then continues to: Source Code (13 lines)I guess this at least gives a record of the time at which the connection was lost - though it doesn't seem to have anything to tie this into what the code was actually doing at the time. Can you tell anything fr…

While debugging, I am getting 'Target connection has been lost' after a while: forum.segger.com/index.php/Att…e01a9d9dbb3ad90a0327f62ce The trouble is, the debugger then closes immediately - so all the RTT debug output, etc, up to that point is lost. How can I retain this information to see where, exactly, the problem is occurring? Or get more information on why, exactly, the connection drops? It makes it very hard to debug when the debugger just disappears completely & throws away all evidence!…

What optimisation setting are you using? It is possible (even likely) that "useless" variables will be removed by the optimiser, or that their values may not actually be set until "needed" I wouldn't expect any IDE's 'Watch' facility to be able to just run an arbitrary function, and display the result.

Have you seen this: Quote from Sourcetrail documentation: “ Supported Languages C C support is powered by Clang 8.0.1. For issues loading C code, please have a look at Clang language compatibility or report a bug in our bug tracker. ”

If there were a problem in the source, then you would get a build error or warning. Remember that all the 'C' language str... functions require a NUL-terminated string to work. Again, are you sure that the SES debugger 'Quick Watch' window is even supposed to be able to evaluate the result of a function call? I would guess that it's not.