Posts by SEGGER - Fabian

Hi,

Quote from tinydrop

I connect target device with swd (7pin 9pin 2pin)

It should be:
7 - SWDIO
9 - SWCLK
1 - VTREF (not 2)
5 - J-Link-Tx (J-Link out => Target in)
17 - J-Link-Rx (J-Link in => Target out)
One of the pins you mention is wrong.

If this does not fix the issue:
Could you please check the following?
https://wiki.segger.com/Using_J-Link_V…ality_and_speed
If the self test works, the issue lies on either
- the connection between Target & J-Link (Faulty cables, Wrong pins connected, ...) o
- on target side (wrong pins toggled, no data send, ...)
We advise to use a Oscilloscope for signal verification.

Could you please check?

BR
Fabian

Hi Peter,
We are not aware of any such issue.

I just gave it a quick try and it works without issues on my side, using an STM32F407VE:

SEGGER_RTT_printf(0, "Some %u Test %u.\n", 123, 456);
SEGGER_RTT_printf(0, "Some %u Test %u.\n", 456, 123);

Resulted in the lines:
Some 123 Test 456.
Some 456 Test 123.

Could you please provide a working sample showing the issue?
Which MCU are you working with?
Are you using the RTT source code from the latest release?
https://www.segger.com/downloads/jlin…cumentationPack

Best regards,
Fabian

Hi Torsten,
this depends on how you reset the device and what exactly happens when you do so.

From the description I would guess that the debug interface is reset,
so a reconnect is required to establish it again.
As an active debug interface is a mandatory requirement for RTT to work,
it would explain the observed behavior.

BR
Fabian

Hi Kaushalya,

It sounds like you are using Nordic Tools for handling RTT on PC side, correct?
If so, please understand that we cannot provide help for applications which are not supported by SEGGER.

If not:
Which application are you using?
Could you please describe your setup in more detail?

Quote from kaushalyas

I know if I try the serial console, I get a reply for the same command.

What kind of serial console are you referring to?

BR
Fabian

Hi,
We added option byte programming via .hex-file to our feature request list.
We will try to squeeze this in within the next couple of weeks.

Stay up-to-date regarding J-Link:
https://www.segger.com/notification/s…php?prodid=7,94

BR
Fabian

Hi,
Both at once:
Executed via cross trigger.
Not supported yet. It's on our list but without a fixed schedule at the moment.

M7 only:
You should be able to halt the M7 in the M7 debug session.
If this does not work, could you please share a J-Link log file of this session with us?

How to enable: https://wiki.segger.com/J-Link_DLL#Enable_J-Link_Log_File

BR
Fabian

Hi,
You can look them up in the release notes.
You can search for the term: "RISC-V: Firmware module version" for differences and compare them.
https://www.segger.com/downloads/jlin…otes_JLink.html

Please note that the list will grow further with time, as features are constantly added and issues constantly resolved.

Best regards,
Fabian

Hi,
Currently, option byte programming via .hex file is not supported for the STM32C0 device with J-Link.
I will check internally if there are any plans regarding this.

Best regards,
Fabian

Hi,
Sorry for the delay in response.
We are not aware of any such issue.

Are you using the latest version of the software?
https://www.segger.com/downloads/jlin…cumentationPack
If so:
Could you please provide a sample data file (e.g. .hex) this issue is reproducible with on an evaluation board?

This way we can look into this on our side.

Best regards,
Fabian

Hi,
sorry for the delay in response.

0x0800_0000 and 0x0C00_0000 describe the same physical flash area.
The first is cached the latter is uncached.

When programming data to 0x0800_0000, it is remapped internally to 0x0C00_0000 by J-Link,

which was always the case for these devices.

It seems that the auto-update did not fully work.
If you setup a new project it should still work with the same address range,
however, programming to 0x0C00_0000 should lead to the same result.

BR
Fabian

Hi,
sorry for the delay in response.
Even though it is probably not required anymore, please find the answer below:

In general we recommend to make use of our trade-in program in such a case:
https://www.segger.com/purchase/trade-in-program/

The damaged part is an ESD-Protection.
You could try to unsolder the part and check if the OB still works, as it also works without the part.
If so, you can replace the part with a new IC (On Semi NUP4114UCW1T2G).
If it does not, more parts were damaged by the over current and the whole J-Link is unusable.

BR
Fabian

Hi,
Even though the thread is quite old, an answer to the question can be found here:
https://wiki.segger.com/S32Kxxx#Readou…_internal_flash

BR
Fabian

Hi,
We updated the wiki-page.
The "Force go on connect" option is now explained:
https://wiki.segger.com/J-Link_RTT_Vie…e_Go_on_Connect

Does this answer your question?

BR
Fabian

Hi tsche,
Unfortunately, we had to postpone the implementation of PIC32MK support.It is still on our list of feature requests, but without definitive timeline.
MIPS is not our core business, so we cannot prioritize this, unfortunately.

Best regards,
Fabian

Hi Peter,
No worries!

Best regards
Fabian

Hi Peter,

Quote from hotbrix

As far I understand you, there is no way around this. I need the perma connection to stay open in order to be able to connect to the server.

This is correct.
As long as you want to use RTT, you will have to have an active debug connection.
Otherwise it is not possible to retrieve the RTT data from the target.

However..

Quote from hotbrix

So during target programming I have to parallel connections, during unit testing with the telnet client I use only the perma-connection to maintain the telnet socket.

...this is not entirely correct.
Yes, you need an active debug connection for RTT, but you could simply continue using the J-Link Commander session used for the application download.
Example:

device ATSAMD21G18A
si SWD
speed 4000
connect
exec SetVerifyDownload = 0
loadbin <TestApp1>.bin, 0x2000
r
g
//
// Do RTT test 1 here...
//
loadbin <TestApp2>.bin, 0x2000
r
g
//
// Do RTT test 2 here...
//
//...
q

Note:I removed the "h" because reset implicitly halts the device & the device is released from reset on "q" anyway.

BR
Fabian

Hi tsche,
Could you please send us a picture of the front and the back of you J-Link for support purposes?

BR
Fabian

Hi Peter,
it seems like you misinterpreted what "SetCompareMode=0" does.
This is not really a surprise as it was not properly documented. We will revisit the documentation an adjust this.
In short:
When SetCompareMode=0 is selected, the J-Link will skip the Blank check and thus has to assume that the device must always be erased before program.
=> Forcing SetCompareMode=0 will force J-Link to always trigger erase when calling LoadFile.

From what I understand you intend to skip the verify, correct?
If so, you would have to use another Command String "SetVerifyDownload=0":

Please note that there is currently no way to Skip the blank check & also skip the erase.
This is currently only possible via J-Flash.

Does this answer your question?

BR
Fabian

Hi,
A good way to approach such an issue is usually the following troubleshooting guide:
https://wiki.segger.com/J-Link_cannot_…rget_connection

Additional hints:
1) The STM32F4 devices allow to set permanent protection (RDP level 2),
which will effectively disable the debug features of the chip.
So if RDP level 2 is set, you will never be able to connect to the chip.
2) In some cases, applications do override the debug pins.
In such a case you would also have to connect the nRESET pin between J-Link & Device.
Otherwise the connect under reset can not work, which is basically the only way to connect to the device in such a case.

BR
Fabian

Hi Peter,
First of all:
As Alex pointed out, an active debug connection is mandatory for RTT to work.
If you are wondering why, please refer to the following article:
https://wiki.segger.com/RTT

This does not change regardless of how you retrieve the data (via TELNET channel or via SDK API calls).

Quote from hotbrix

- upload the firmware

I assume you are referring to programming the target device, correct?
From your message it is not clear to me how exactly you are doing this,
but I would further assume that it is either with J-Link Commander, J-Flash, or the SDK correct?
If so:
All of these provide the option to not disconnect on programming completion.
You could use this option to keep the connection alive while you are using RTT via the TELNET channel.

Quote from hotbrix

maybe this is something that could be achieved with your SDK ?

As mentioned, it will not allow you to use RTT without an activte debug connection (this is physically not possible).
However, you could of course combine all steps using it:
- Connect to the device
- Flash Application
- Read / Write via RTT
- Disconnect from the device

Does this answer your questions?

BR
Fabian