Search Results

It's part of a much more complex test system so I doubt it will make much sense to you, which is why I have been pulling out the relevant parts, but if you insist then the relevant files are attached.

Yes, that's correct. nrfjprog is started with the command line: nrfjprog -f nrf52 --program nrf52840_xxaa.hex --chiperase --verify -r -s <serial number here> The Python code that does this is Source Code (3 lines)The download is allowed to complete successfully, the Python sub-process exits all by itself with return value 0. J-Link is then started to obtain RTT logging from the same board with the command line: jlink.exe -Device NRF52840_XXAA -If SWD -Speed 4000 -Autoconnect 1 -ExitOnError 1 -RT…

Thanks for your swift response. The port numbers we use are distinct for each parallel case, of course. No port number is specified at all to nrfjprog: the download process needs/takes no Telnet port, as far as I'm aware: please tell me if I'm wrong. Could you explain what the line "Process: xxx" printed by J-Link means? Why is any other process involved at all, all we have asked for is for the target serial number in question to have its RTT output sent to a Telnet port that we specify. The onl…

Further to [SOLVED] J-Link freeze in multiply parallel environment, having resolved that problem in a multiply parallel environment we seem to be left with a residual issue, which is that on some occasions (around the 1 in 10 times mark again) a J-Link session opened for RTT logging fails to emit any logging whatsoever from the target. On these occasions it seems that J-Link, or whatever underlies it, is confused about the process it is serving. In detail: we run Nordic nrfjprog to download to t…

Confirmed: for the benefit of the forum, in case anyone else has this problem, if you are using J-Link for RTT logging (reading from its RTT-socket), driven from an [e.g. Python] script, there is only ONE way to reliably shut J-Link down again and that is to keep a stdin pipe open to it and send it the string "exit\n" before terminating it. If you send J-Link SIGTERM/CTRL-C/CTRL-BREAK signals, or if you just terminate it, some percentage of the time (with us it was anything from 10% to 40% of th…

That's *better*! Some real information, thank you :-). FYI, I have since modified my Python script to send a Windows termination, CTRL-C, to the application, so it is not like the power is being pulled, it is being told to exit (5 times at 1 second intervals) before the task-manager-style termination of terminate() is invoked. I hoped that would be a sufficiently clear "tidy up now" signal but obviously not. I will try typing "exit\n" at it over stdin next. Thanks, again, for your support.

For instance, could you explain what "Out of sync, resynchronizing..." means, aside from "it's broken"? What is out of sync with what: is it the target debug chip, a DLL, something else, and what is it that Jlink is doing to regain sync? That would help me try to work out what is going wrong here.

I guess we'll have to agree to disagree: I find it difficult to believe that the amount of flash used in tracking how much heap is in use is large versus the negative impact of not knowing that you've lost the much scarcer resource that is RAM. And heap checking, in my view, should be done on the target, in real scenarios, at which point you wouldn't be using a "test" malloc()ater because then you're not testing the real thing; practically speaking you'd just end up having to entirely replace th…

Any thoughts on this? It is currently failing 40% of the time, so having quite a large impact. A workaround would be fine.

Thanks: it is quite an important function to have. Not having it is like driving a car without a fuel gauge; a little worrying when one is, for instance, running on an NRF52 with a "tank" only 64 kbytes in size. And of course, as a matter of principle, one's unit tests should always check that the code they are testing has not leaked any memory, which is impossible without this function. Without this function I have to run all the same code on GCC also, which starts to make SES a bit irrelevant:…

I guess there's no way to do this...?

I would like to determine the current heap usage (in order to check for memory leaks). On platforms that use newlib I can do this by calling mallinfo() but of course SES uses its own C libraries so that is not available to me: what is the equivalent function in the SES world? Rob

I can see that in both fail cases the log says: T25F8 000:009.788 JLINK_OpenEx(...) T25F8 016:870.921 Out of sync , resynchronizing... ...where it should be connecting to the probe. Why did the previous J-Link session leave the probe in a state that causes this failure? What can I do about it?

OK, some logs. Find attached two fail cases and a success case. Do let me know what you can see. forum.segger.com/index.php/Attachment/4385/ forum.segger.com/index.php/Attachment/4386/ forum.segger.com/index.php/Attachment/4387/

Thanks for your remarkably swift attention. Just getting logs for you now. On the other stuff: We use JLink for two things: RTT logging and downloading to a board. To do the RTT logging part we open a Python sub-process as follows: Source Code (5 lines)We connect to the Telnet port and let it run, monitoring the trace output. When the trace output tells us that the target has finished doing what it should, we terminate J-Link as follows: Source Code (5 lines)After this has completed we wait 5 se…

Hi there. We are using JLink [V6.84a] to download code to our test boards and then do RTT logging in a multiply parallel environment, i.e. we have many boards (Nordic NRF52/53) connected to the [Windows 10] PC in question. All operation is controlled through Python [3.8.5] scripts. Each board serial number is specifically addressed with the -USB parameter in the call to J-Link. We have a lock in place so that JLink is never called to download to two boards at the same time. Our problem is that a…

FYI, I've found a workaround for this. In my common pre-processor definitions I have added 10 generic entries with dummy default values as follows: $(EXTRA0:__dummy0) $(EXTRA1:__dummy1) $(EXTRA2:__dummy2) ... I can then launch SES from the command line and supply the actual values for each one as parameters, e.g.: "C:\Program Files\Segger\SEGGER Embedded Studio for ARM 4.50\bin\emstudio" -D EXTRA0="MY_CONDITIONAL=1" Not elegant but it works.

Ah, S'OK, I hadn't realised that the things that appear under the "Project" toolbar menu are context sensitive depending on where you are in the hierarchy of the view in the left-hand window. Now sorted.

Following the ticket here: forum.segger.com/index.php/Thr…n-Segger-Embedded-Studio/ ...I've tried following the instructions here: wiki.segger.com/Enable_RTOS_Awareness_in_Embedded_Studio ...to add FreeRTOS thread awareness to my SES 4.5 (Nordic license). However, I can't find the debug options menu that is mentioned. Can anyone point out to me where that option has moved to? Rob

Referring to this thread from Feb 2018: [SOLVED] EMBuild -D option ...can I ask if it is still the case that there is no way to pass in #defines from the outside world into Segger Embedded Studio? I don't mean change ones that SES knows about, I mean just pass in the random stuff I need to get into my code. Not being able to do this is a real barrier to automation and to writing/maintaining cross-platform code. I have to deal with building/testing my code under many different SDKs at the same ti…