Search Results

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 wiki.segger.com/J-Link_cannot_…the_CPU#Target_…

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: wiki.segger.com/J-Link_DLL#Enable_J-Link_Log_File 3) Could you please send us a GDB log file? 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: forum.segger.com/index.php/Att…09cf16…

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? segger.com/downloads/jlink#J-L…twareAndDocumentationPack 3) Apparently you already found the article explaining the cJTAG sequnece. Have you tried what is mentioned i…

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 Embed…

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 …

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, wh…

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_frdm…

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: wiki.segger.com/UM08001_J-Link…#Reset_unlock_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_…

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: 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…

Hi, To prevent any device specific handling, you can override it with the script file here: wiki.segger.com/J-Link_script_…g_device_specific_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(). wiki.segger.com/J-Link_script_files#OnDisconnectTarget.28.29 This will skip the …

Hi, Did you try the options mentioned here? 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? segger.com/downloads/jlin…

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 era…