Hi,
The legacy USB driver is indeed to compatible to Windows ARM64.
See here: https://wiki.segger.com/J-Link_on_Windows_ARM#Requirements
As you can see here: https://wiki.segger.com/J-Link_EDU_V10
the EDU V10 does not list the WinUSB option and therefore does not support support it.
The unit is too old.
BR
Alex
Hi,
We can confirm that the problem is reproducible on our side.
We already have an internal solution for it but need to perform another round of iterations to check against unwanted side effects.
BR
Alex
Hi,
Does not sound familiar.
In general, Flashers do neither support RTT nor HSS (both J-Scope modes) so it is simulated on the PC side.
As you observed: With much less throughput
I do not see why timestamps and values should get corrupted if the TIF speed is the same and things are just more efficient because they are executed from within the firmware.
Does it also happen when issuing the reset via J-Link Commander?
Use „r“ to reset
Use „mem32 <Addr>“ to read the PLLCFGR
As you have also contacted us in parallel via another channel, we will continue communication on that 2nd channel and close this thread here.
BR
Alex
Hi,
I am assuming that you use the DLM tools in e2studio for this, correct?
In general, it should work with any current J-Link model.
Can you please tell us what J-Link Commander outputs at “Firmware: xxx” for your J-Link BASE?
Just to make sure that the J-Link in question is not too old.
Hi,
You might link the RTT control block & buffers to a fixed location, which is identicial in the BTL and APP.
Furthermore, the RTT control block & buffers should be marked as “do not initialize” in the APP part (e.g. by placing them in zhe .no_init section).
This way, the startup code of the APP will leave the RTT part alone, so no pending output from the BTL is lost/overwritten and the J-Link RTT logic is not confused by the control block & buffer locations to change at runtime.
Hi,
In the list you have sent a link to, none of the devices are supported by J-Link.
J-Link supports debugging on the MSP0 and MSP432 derivatives (Cortex-M based)
The “legacy” MSP430 are only supported by Flasher for production programming.
No debug support.
You may be lucky with J-Link + OpenOCD for MSP430 support though.
Sounds like it has to do with the “working directory” (https://en.m.wikipedia.org/wiki/Working_directory)
When you click the bat file, the working directory of the bat file code is the location of thw bat file.
That working directory is inherited by JLink.exe, so when opening the relative(!) file path <Example.bin> the file is searched in the working directory (same location where the bat file is)
When you call the bat file from within LabVIEW, the working directory is most probably the location of your LabVIEW project.
So that working directory is inherited by the bat file and finally by JLink.exe
Now <Example.bin> is searched where your LabVIEW project is located and not where the bat file is located.
See here:
https://forums.ni.com/t5/Example-Cod…EW/ta-p/3507703
Sorry for the delay in response.
We have no intentions to remove the open flash loader (OFL) support.
We also do and will continue to support CMSIS algorithms, as stated here:
https://wiki.segger.com/J-Link_Device_…SK_availability
(The SEGGER flash loaders provide more optimizations over the OFL and CMSIS, so are usually faster)
The price for the DSK is more a compensation for support + to make sure that it does not end up in "the wrong hands".
Unfortunately, the development tools for the Renesas don't support debugging with the P&E.
Just in case: Are you aware of Ozone and ever tried it out?
https://www.segger.com/products/devel…-link-debugger/
If yes: What's your feedback on this?
BR
Alex
Hi,
Sure you can connect 5x Flasher Compact using a standard USB hub.
Here you can find an example to program multiple targets in parallel:
https://wiki.segger.com/UM08003_JFlash…ets_in_parallel
Hi,
to 1)
See here:
https://www.segger.com/products/debug…-specifications
and look for VIF.
1.2 - 5V are fine for VIF (VTref)
to 2)
While it is a bit unusual to shared TRACED0 with SWV because SWV is usually shared with TDO,
I can see why SiLabs did it.
As their EFM32 do not support JTAG, there is no TDO signal to be shared with.
Actually, sharing SWV with TRACED0 is a clever move because you so not lose anything.
If you enable & use trace, the SWV data is merged into the trace stream and also transmitted via TRACED0-3.
So when using trace, the SWV pin becomes obsolete.
to 3)
Has a fair chance to work with TRACED0 only.
It heavily depends on the application how good the trace unit can compress the data.
But I see a 39 MHz CPU speed not really as critical.
Do you know the source of the trace clock for these chips?
Is it 1/2 CPU speed or some “fixed 8 MHz clock”?
If it is 1/2 CPU speed, 1 trace pin could work with a high chance.
Can you please PM me the S/N of your J-Trace unit?
Not being able to specify the SWO speed is bad… Having it on “max possible” is OK but not being able to change that setting is a bad thing because different models have different max. speeds 
May be worth opening a ticket at Renesas for this because it should not be a big change for them (nothing would change for 99% of their users)
But 67 MHz SWO speed has a high probability of being problematic. Many I/Os are not capable of speeds beyond 50 MHz (if that high at all).
You can easily mess things up for such frequencies by placing series resistors etc. that are too big for this league of speeds.
What you may try is:
Limiting the max SWO speed of the ULTRA+ artificially. You may achieve this via J-Link Configurator:
https://wiki.segger.com/J-Link_Configu…nk_Configurator
I recommend to set max. SWO speed to something like 8 MHz or so in your case.
You may even try 500 kHz like the OB but pretty sure that 4, 8 or even 16 MHz will still work.
Regarding the Ozone thread:
Pretty sure AlexD or someone else from the department will help you out.
Hi Steven,
I see that you have been in touch with Richard W. at TI. A very capable guy…
Pretty sure he can help you out.
As J-Link’s Cortex-M4 support is generally working and we are not talking about an issue with our flash algo etc. but a connect works and a simple halt command is not accepted / acknowleged by the core, it can only be something chip-specific like the M4 being held in reset.
My suggestion is to get one of TI’s example projects up and running that blinks an LED or so on the M4. Then modify the project into something like “turn LED on and enter endless loop” (something that does not go into any low power modes for sure, as these can also interfere with debug!)
I doubt that it is a problem with the ULTRA+ firmware but more a setup issue.
Probably you have set the SWO speed to “max”
and the ULTRA+ (which is capable to handle up to 100 MHz SWO speeds) leads to settings that exceed the max. speed of the MCU’s I/Os.
What SWO speed do you use?
Did you check if selecting a fixed speed of 1 or 4 MHz for SWO works with both probes?
Hi Pedro,
What unit do you use?
(Can you please PM me the S/N?)
There is currently no official way to do this via J-Link Commander but we should be able to add something like that.
Way easier than adding a whole command line handling to a heavy, almost GUI-only utility like the Configurator.
BR
Alex
Hi Steve,
Sounds a bit like the M4 is clocked, so the AHB-AP debug domain is accessible but the core itself is still held in reset.
This would explain why it is not responding to halt requests etc.
Is that possible in your case?
Hi,
There is no RTT support for ARM11, as ARM11 does not support background memory access.
The “emulation mode” is also not available for ARM11
That’s not how J-Link is intended to work.
Nope, there is no possibility doing what you plan to do, with the available script etc. APIs.
We strongly recommend to not further pursue this path but select the correct device in the IDE.
