Posts by SEGGER - Fabian

Hi,
From the message it seems like the VTref pin is not being powered on your setup.
I guess that you have to change some jumper settings to enable connection to an external debug probe or similar.
We recommend to check the board manual regarding this.

In general it is easier to first get things up and running with J-Link Commander (JLink.exe) to verify that the connection.
Could you please follow the troubleshooting article on the page linked below
https://wiki.segger.com/J-Link_cannot_…rget_connection

In case you can confirm that VTref is 0V with a multimeter, we would suggest to contact NXP regarding this,
as this seems to be a board related setup issue.

Best regards,
Fabian

Hi Maximilian,
This is the first time we have heard about such an issue.
1) Did also turn to the MCUXpresso / NXP forum?
2) Could you please send us a J-Link log file? How to enable:
https://wiki.segger.com/J-Link_DLL#Enable_J-Link_Log_File
3) Could you please send us a GDB log file?
https://wiki.segger.com/J-Link_GDB_Server#-logtofile
If I remember correctly, the command can be passed via
Debug Configurations -> JLink Debugger -> Additional Options -> Other server Options:

BR
Fabian

Hi,
A couple of things:
1) Please refrain from spamming in this forum.
If you want to add information to the thread before anyone answered, please use the "Edit" function.
I removed the other messages and included it to the original one.
2) J-Link V7.22 is fairly outdated. Could you please check if it works with the latest version?
https://www.segger.com/downloads/jlin…cumentationPack
3) Apparently you already found the article explaining the cJTAG sequnece.
Have you tried what is mentioned in the note about the short cJTAG sequence?
https://wiki.segger.com/J-Link_cJTAG_s…onnect_sequence

Best regards,
Fabian

Hi,
the issue lies on SEGGER side here.
Some month ago, Embedded Studio was adjusted to natively import RTT as library, when selected in the project options.
The issue is that this may lead to building errors with projects that still include the old RTT files.
The issue can be resolved by

• removing the RTT files from the project and
• changing Project > Options > Library > Library I/O from "None" to "RTT".

I uploaded a new version of the project should build out of the box with the latest Embedded Studio.
Could you please give this a try and tell us if it works on your side, too?

BR
Fabian

Hi,
Your question is not related to RTT but is concerning a general topic
related to a general C and Assembler language.

Please understand that this far exceeds the scope of the help we can
provide in this Forum or in our support ticket system.

I suggest that you take the time to check the RTT target side implementation, which you have all sources for.
You could either
a) follow the function calls or
b) step through the code
until you find where the memory is copied in the source.

As a hint:
As long as RTT_USE_ASM is set, you can find the memory copy implementation in SEGGER_RTT_ASM_ARMv7M.S => SEGGER_RTT_ASM_WriteSkipNoLock().

I dare say that it is well enough documented to find the code where the memory is copied.

Regarding the question why some memcpy implementations are faster than others:
I suggest to search the internet for this information. I am sure you will find well explained answers to this questions.

If you can come up with a faster/more optimized routine to copy the memory,
you are free to adjust the code you are using for RTT.
You have all the sources and are free to change them.
Please understand however, that we can not provide any support or similar for code
adjusted by users.

Please understand that for these reasons we cannot provide any more answers regarding this topic.
We will close this thread now.

BR
Fabian

Hi,
it seems like there might be some misunderstandings here.
So I hope to clear them out with this post.

1) When is the ASM sub module used
The ASM sub module contains an ASM variant of SEGGER_RTT_WriteSkipNoLock().
This function is used per default for most cores (e.g. Cortex-M4).
However, you are using SEGGER_RTT_Write() not SEGGER_RTT_WriteSkipNoLock().
So in your example code the ASM routine is actually not used.
You can check this by looking into the SEGGER_RTT.c and SEGGER_RTT.h files, which contain the compiler switches (asm available or not) and code used by RTT (asm version of SEGGER_RTT_WriteSkipNoLock() used or not).

2) What does output time actually mean
The output time is the time it takes the RTT module to output data.
It is the time between the call of the RTT function until the data is available to be read by J-Link, so until it is in the buffer, without overhead(!).

So to measure the output time can be done by using a scope and an application that toggles a pin:
a) Set the pin (e.g. LED pin).

b) Measure the time (clear to set) of the following calls to get overhead time:
BSP_ClrLED(0);SEGGER_RTT_LOCK();Status = SEGGER_RTT_WriteNoLock(0, 0, 0);SEGGER_RTT_UNLOCK();BSP_SetLED(0);c) Measure the time (clear to set) of the following calls to get actual output time:
BSP_ClrLED(0);SEGGER_RTT_LOCK();Status = SEGGER_RTT_WriteNoLock(0, "01234567890123456789012345678901234567890123456789012345678901234567890123456789\r\n", 82);SEGGER_RTT_UNLOCK();BSP_SetLED(0);I repeated the measurement on the SEGGER Cortex-M Trace Reference Board (168MHz) and the result was as follows:
Measurement 1) (overhead): 2.04usMeasurement 2) (82 chars): 2.70us=> Time without overhead: 2.70us - 2.04us = 0.66us

3) What factors can impact the output time
The test I did was executed from flash.
As the string is copied from flash to RAM, the RAM write speed and cache handling (if the core has any) has an impact on the time measured for example.

BR
Fabian

Hi,
Sorry for the delay in response.
It seems like I misjudged where the problem was originating from:

J-Flash does not accept aliased areas but only the actual flash areas for programming.
On the KW38 devices, the flash from 0x1000_0000 - 0x1004_0000 is aliased to 0x4_0000 onward.
It seems like the data file was created using the aliased flash area.

Could you please try the following J-Flash + command line?

%JLinkInstDir%\JFlash.exe -openprj%KW38ProjectPath% -open%PathToDataFile%\ble_shell_frdmkw38.bin,0x0 -delrange0x0,0x3FFFF -relocate0x0FFC0000 -merge%PathToDataFile%\ble_shell_frdmkw38.bin,0x0 -delrange0x40000,0x7FFFF

You would have to replace the following:
%JLinkInstDir% == Install directory of the J-Link Software
%KW38ProjectPath% == J-Flash project file path

%PathToDataFile% == Directory containing the data file

This should also work with the .s19 file instead of .bin.

The Command line will open the J-Flash project with a data file containing the data in the correct ranges.

Best regards,
Fabian

Hi Marco,
we were able to recreate the issue and fixed it internally.

A fix will be part of the next J-Link Software version, planned for some time next week.

Thank you for making this issue known to us.
We are sorry for any inconvenience caused.

BR
Fabian

Hi Qi,
Please refert to the following article:

https://wiki.segger.com/UM08001_J-Link…ock_message_box

BR
Fabian

Hi,
I can confirm that J-Flash is able to save data files with dots and in paths/folders containing dots.
We are not able to recreate this issue.

However, it seems that the two paths that you mention are not comparable:
1) C:\Users...\TEST_TEST_V1.0.3-rc.4_BL_V1.0.1-rc\Device.pex
2) TEST_TEST_V1_0_3-rc_4_BL_V1_0_1-rc_2.cfg

Could you please provide step-by-step instructions explaining how to
reproduce this issue?

BR
Fabian

Hi,
This looks like you are having overflows of the RTT buffer.
This happens when the device is sending data faster than the J-Link can retrieve it and
the following modes are selected by the MCU application:
- SEGGER_RTT_MODE_NO_BLOCK_SKIP
- SEGGER_RTT_MODE_NO_BLOCK_TRIM

You can improve this situation by e.g. increase the target interface speed in the configuration dialog.
If this does not help, and the application is not time critical, you can also change the mode to:
SEGGER_RTT_MODE_BLOCK_IF_FIFO_FULL

Could you please check if this improves things?

BR
Fabian

Hi,
Sorry, but we didn't manage to squeeze this in.
It will be part of the next one.

So either next week or the week after.

I uploaded the J-Flash samples so you have access before then:
https://share.segger.com/index.php/s/ETZyJoA3P6NrxAa

Does this work for you for now?

BR
Fabian

Hi,
it works with the J-Link Commander, because you are flashing different files.

.bin files do not contain any address information, nor do they specify empty ranges, s19 files do.
Thus, J-Flash has to assume that it is a continuous block of data that you are trying to program.

The flash on the MKW34A512 devices is split in two parts, that are not next to each other (2x256KB, 0x0000_0000 - 0x4_0000 and 0x1000_0000 - 0x1004_0000).

So J-Flash correctly points out, that continuous 512 KB do not fit in the selected address range.

If you use the s19 file instead of the bin file, it should work.

BR
Fabian

Hi,
To prevent any device specific handling, you can override it with the script file here:
https://wiki.segger.com/J-Link_script_…pecific_connect

This should prevent the DBG_MCU registers from being written during the debug session.

Additionally, you would have to add an "OnDisconnectTarget()" routine to the script file, which also does nothing except for returning 0,
the same way as it is done with InitTarget().
https://wiki.segger.com/J-Link_script_…ectTarget.28.29
This will skip the reset of the registers on disconnect.

Best regards,
Fabian

Hi,
Did you try the options mentioned here?
https://developer.arm.com/documentation/ka003020/latest

BR
Fabian

Hi,
Do you need to reset these bits during debugging?
If so, could you please explain why you would require this?

Or do you mean that the bits are not reset after the debug session ends?
If so, we changed the behavior a while ago so that these bits are reset after debug session end automatically.
As this is not the case for your setup, I suspect that you are using an outdated version of the J-Link Software.

Does it work as expected when you update to the latest version?
https://www.segger.com/downloads/jlin…cumentationPack

BR
Fabian

Hi,
The samples are left out by mistake.
They are supposed to be part of the package.

We will adjust this so they will be provided with the next version of the J-Link Software Pack.
The next version is planned to be released some time tomorrow or the day after.

Thank you for making this known to us.

BR
Fabian

Hi sharon,
The Mem and SaveBin commands are supposed to show the memory from the CPU's point of view.
Therefore it would not be correct to use the SEGGER_FL_Read() function when using these commands,as they would not represent the memory space that the CPU "sees" anymore.

BR
Fabian

See: Erase a secured ATSAM device

Hi Michael,
We answered you via the the case you opened in the ticket system.

For completeness the most important points:
- The unsecure works fine on our side.
- Please note that the unsecure is only possible, if the device can be mass erased via the DSU.
- The device can NOT be unsecured if the mass erase was disabled via the CELCK command (NVMCTRL register).
- It is the responsibility of the target application (user responsibility) to make sure that the device is in a state where the mass erase is not disabled.

So, either you do have a way to make the application on the device issue the CEULCK command, thus re-enabling
the mass erase via DSU, or the device cannot be unlocked and is "bricked".

Regarding the J-Link Commander output:
We will revisit the device specific connect of these devices and improve the output/functionality as follows:
- The user will be notified in case mass erase is disabled.
- A loop where "Mass erase done!" is printed again and again, even though it is clearly not will be prevented.

BR
Fabian