Hi Pierre,
sorry for the delay in response.
The issue you described was already fixed with V7.92l:
While the update notification pop-up was visible, other dialogs (e.g. flash programming dialog) would not be shown until the pop-up was closed. Fixed.
I would suggest to upgrade to the latest version:
https://www.segger.com/downloads/jlin…cumentationPack
To disable the notifications entirely, please refer to the following article:
https://wiki.segger.com/J-Link_Update_Notifications
BR
Fabian
Hi Pierre,
The update notification dialog should be non-blocking, so it should not interrupt your script execution.
Could you please tell us a little bit more about your setup, so we can investigate this?
1) Which J-Link Software version are you using?
2) Could you please send us a J-Link log file of the session?
How to enable: https://wiki.segger.com/J-Link_DLL#Enable_J-Link_Log_File
BR
Fabian
Hi,
You are welcome! 
It is good to hear that this is no longer blocking for you.
We will close this thread now.
Best regards,
Fabian
Hi,
The RTT TELNET channel is technically a RAW socket.
See: https://wiki.segger.com/J-Link_RTT_TELNET_Channel
Except:
Note:
The channel is "TELNET-like", which means:
- The TELNET protocol is not fully implemented, so not all functionality is supported.
- It is TELNET compliant for RTT data that is solely consisting of printable characters, only.
- Raw (non-character) RTT data has to be interpreted as raw bytes.
What does this mean?
When you are sending bytes, these bytes will be written just as they are to the Socket, which is not TELNET complient.
Example:
If your target does something like:
char ac[12] = {0x23,0x00,0x01,0xff,0xfe};
SEGGER_RTT_Write(0, ac, 5);Then the 5 bytes will be written to the socket.
So, reading 5 bytes from the socket will give you the desired data.
You can verify this by reading raw data from the socket.
In short:
Simply read the data from the Socket as raw bytes and you should be fine.
"NVT something 0xff,0xfe"
the NVT came from Jlink driver, not from my code.
I guess it's control commands for telnet.
That is incorrect.
Where ever it is coming from, it is not from the J-Link Software.
Googling suggests that NVT stand for "Network Virtual Terminal", which is not supported by J-Link Software.
See: https://www.geeksforgeeks.org/what-is-networ…inal-in-telnet/
So I guess that some background layer of your software is using it.
Best regards,
Fabian
Hi AbhiAsh,
My requirement is to open a text file and send the data line by line to the target in handshake.
We do not have a tool or example with such a feature directly.
However, you could do one of the following:
1) Acquire the J-Link SDK & use e.g. C/C++ or python to read the file contents and send it to the target line by line.
The SDK comes with RTT samples in C & python.
https://www.segger.com/products/debug…ols/j-link-sdk/
2) Read the file content & send it line by line to the RTT Telnet channel:
https://wiki.segger.com/J-Link_RTT_TELNET_Channel
3) Read the data file & send it line by line vie StdIn of J-Link RTT Client:
https://wiki.segger.com/J-Link_RTT_Client
Best regards,
Fabian
Hi,
we just gave it a try on the latest MacOS version.
Everything worked as expected.
Could you please send us a J-Link log file of the failing scenario?
How to enable: https://wiki.segger.com/J-Link_DLL#Enable_J-Link_Log_File
BR
Fabian
Hi,
J-Flash & the J-Flash project format was updated sever times since V5.02l.
I would guess that the Project does not work flawlessly with the new J-Flash version.
Does it work when you setup a new J-Flash project with the latest J-Flash Software?
Best Regards,
Fabian
Hi Ali,
Did you already check out the troubleshooting guide?
https://wiki.segger.com/J-Link_cannot_…rget_connection
Please note that the connection can not be established if RDP was set to Level 2:
https://wiki.segger.com/ST_STM32#Device_security
Best regards,
Fabian
Hi,
Thank you for your inquiry.
We are not aware of any such issue.
We also highly doubt that the issue lies on J-Link side here. Please find the reason below:
If the devices are indeed locked by programming NONMAIN with problematic data,
this would mean that the J-Link was told to program it and that the data had a valid CRC value.
Please note, that NONMAIN changes only take effect after a power-cycle of the device.
This would explain why the effect shows "sometimes" but not always.
If you send us a data file (.elf/.hex/.bin/...) with a sample application this issue is re-creatable with,
we can have a quick look at it.
Could you please also tell us which device revision you are working with (PG1/PG2)?
Best regrads,
Fabian
Update:
The board arrived.
We soldered a 10 pin connector on it and hooked up the J-Link.
It did work out of the box on my side (see below).
We are confident that this issue is related to your setup (soldering/cable/...)
Connecting to target via SWD
Found SW-DP with ID 0x2BA01477
DPIDR: 0x2BA01477
CoreSight SoC-400 or earlier
Scanning AP map to find all available APs
AP[1]: Stopped AP scan as end of AP map has been reached
AP[0]: AHB-AP (IDR: 0x24770011)
Iterating through AP map to find AHB-AP to use
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0xE00FF000
CPUID register: 0x410FC241. Implementer code: 0x41 (ARM)
Found Cortex-M4 r0p1, Little endian.
FPUnit: 6 code (BP) slots and 2 literal slots
CoreSight components:
ROMTbl[0] @ E00FF000
[0][0]: E000E000 CID B105E00D PID 000BB00C SCS-M7
[0][1]: E0001000 CID B105E00D PID 003BB002 DWT
[0][2]: E0002000 CID B105E00D PID 002BB003 FPB
[0][3]: E0000000 CID B105E00D PID 003BB001 ITM
[0][4]: E0040000 CID B105900D PID 000BB9A1 TPIU
Memory zones:
Zone: "Default" Description: Default access mode
Cortex-M4 identified.BR
Fabian
Hi,
Thank you for the detailed post.
1. To be perfectly honest, the solder job looks horrible, but if you verified that all pins connect correctly andthat there are no short circuits (except for the ones between GND pins), so be it.
2. Regarding the flat cable: You say that it was delivered with the J-Link EDU correct?
This is a sounds a little bit odd to me. As far as I know all flat cables we deliver with our products
- are light grey
- have one red wire which connects both pin 1.
On the picture however, it looks like the cable is dark grey and does not have a red colored wire.
To verify if the cable is broken or working, I would suggest to check the connection between the pins of the J-Link & the board,
while the cable is plugged on both.
3. Unfortunately, it is a little bit hard to see how the cable is connected to the board.
But it looks like the nose is pointing to the top, so with pin1 on the right top side.
According to the board pictures on the SparkFun website, this would be correct.
It is hard to tell what exactly is going wrong here, but I would assume that the issue is caused by a faulty physical connection between J-Link & Board.We will order a sample of this board and create a wiki page explaining how to connect it to J-Link.
I will notify you once the article is available.
BR
Fabian
Hi Gavin,
I had a quick look at this. CORTEX_R52 is currently not pre-defined.
I will forward this internally.
For now you can use the magic value instead:
JLINK_CPU = 0x1404FFFFNote:
JLINK_CPU and CPU refer to the same variable.
BR
Fabian
Hi everyone,
this was officially added with the release of J-Link Software Version V7.92i.
Excerpt from the release notes:
SEGGER_RTT_vprintf(): %s handling: In case string is NULL-pointer, function will now write "(NULL)" instead of doing a NULL-pointer access.
BR
Fabian Federschmidt
Hi,
I assume that you are using the J-Link SDK, correct?
If so, could you please contact us via our support ticket system?
https://www.segger.com/support/technical-support/
Best regards,
Fabian
The power pin is not enabled by default.
Please refer to:
https://wiki.segger.com/J-Link_Commander#Power
Best regards,
Fabian
Hi,
We implemented a verbose mode option for J-Link Log files.
Please refer to the following article:
https://wiki.segger.com/J-Link_Command_Strings#SetLogVerbose
BR
Fabian
Update:
Device support will be available with the next J-Link Software release (V7.92g)
planned for Wednesday, next week (23-09-27).
It will be available for download here:
https://www.segger.com/downloads/jlin…cumentationPack
BR
Fabian
Hi,
R7FA6M5BG is currently only supported by Flasher.
https://www.segger.com/supported-devices/search/R7FA6M5BG
I will check internally, if there are plans to support this chips already.
BR
Fabian
Hi Florent,
I just gave this a quick try on the STM32H735G-DK (STM32H735).
I could not test it on an STM32H730, as there are no evaluation boards available as far as I know,
but both should behave the same from a debug standpoint.
On our side it worked without any issues with J-Trace Pro V2 Cortex-M (see below).
Do you have any target application running on your device?
If so, does the same issue appear after erasing & power-cycling the device?
Best regards,
Fabian
Firmware: J-Trace PRO V2 Cortex-M compiled Jun 6 2023 10:51:16
Hardware version: V2.00
J-Link uptime (since boot): 0d 00h 00m 01s
S/N: 752060000
License(s): RDI, FlashBP, FlashDL, JFlash, GDB
USB speed mode: High speed (480 MBit/s)
IP-Addr: DHCP (no addr. received yet)
Emulator has RAWTRACE capability
VTref=3.307V
Device "STM32H730IB" selected.
Connecting to target via SWD
ConfigTargetSettings() start
ConfigTargetSettings() end - Took 15us
InitTarget() start
SWD selected. Executing JTAG -> SWD switching sequence.
DAP initialized successfully.
InitTarget() end - Took 7.04ms
Found SW-DP with ID 0x6BA02477
DPIDR: 0x6BA02477
CoreSight SoC-400 or earlier
Scanning AP map to find all available APs
AP[3]: Stopped AP scan as end of AP map has been reached
AP[0]: AHB-AP (IDR: 0x84770001)
AP[1]: AHB-AP (IDR: 0x84770001)
AP[2]: APB-AP (IDR: 0x54770002)
Iterating through AP map to find AHB-AP to use
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0xE00FE000
CPUID register: 0x411FC272. Implementer code: 0x41 (ARM)
Cache: L1 I/D-cache present
Found Cortex-M7 r1p2, Little endian.
FPUnit: 8 code (BP) slots and 0 literal slots
CoreSight components:
ROMTbl[0] @ E00FE000
[0][0]: E00FF000 CID B105100D PID 000BB4C7 ROM Table
ROMTbl[1] @ E00FF000
[1][0]: E000E000 CID B105E00D PID 000BB00C SCS-M7
[1][1]: E0001000 CID B105E00D PID 000BB002 DWT
[1][2]: E0002000 CID B105E00D PID 000BB00E FPB-M7
[1][3]: E0000000 CID B105E00D PID 000BB001 ITM
[0][1]: E0041000 CID B105900D PID 001BB975 ETM-M7
[0][2]: E0043000 CID B105900D PID 004BB906 CTI
I-Cache L1: 32 KB, 512 Sets, 32 Bytes/Line, 2-Way
D-Cache L1: 32 KB, 256 Sets, 32 Bytes/Line, 4-Way
Memory zones:
Zone: "Default" Description: Default access mode
Cortex-M7 identified.Hi,
I think the reflasher does not support st-link v3 boards
Correct.
will it support and how soon ?
There are no plans to add reflash tool functionality for STLINK-V3 and it is unlikely that there will be any in the foreseeable future.
The reflash utility was designed to provide J-Link support for ST evaluation boards, which did not come with headers for external debug probes.
ST promised, that all evaluation boards that come with a V3 would also come with an external debug header,
so J-Link can be supported out of the box.
As the ST-LINK reflash J-Link is not allowed to be used in a commercial context,
I would assume that you would want to use it non-commercially correct?
In this case, I would suggest to purchase a J-Link EDU from one of our official distributors.
BR
Fabian