Search Results

Hi, Usually devices are locked when produced for release to prevent them from being read out. The i.MX534 for example has multiple debug modes which either require the correct key to be passed or disable debug access completely. I would be very surprised if the car manufacturer did not enable security for the device. In such a case there is not much you can do, I'm afraid. I suggest to contact, the car manufacturer for help instead. Best regards, Fabian

Hi, We will look into this and see if we want to adjust the code to prevent these warnings. However, we are currently fully booked with projects and this is the first request regarding this, so I cannot say when we will be able to look into this. I would suggest that you suppress these warnings on your side for now, by wrapping the include of the header file in pragmas to disable/enable these warnings. Example: C Source Code (18 lines)That way you can still update the RTT sources without manuall…

Hi James, VCOM (virtual COM port) is what is used to use J-Link as a virtual com port device. This makes it possible to use the related J-Link pins to be used as UART interface. The article Alex linked should do exactly what you require: Show J-Link as a COM port device, which can then be used by what ever application you are using to send/receive UART information between your PC and your target chip. For further information please refer to: wiki.segger.com/J-Link_Virtual_COM_Port For informatio…

Hi Gabriel, this is intentional. SEGGER_RTT_printf() is (by far) not a complete printf() implementation. Flags, FieldWidth and Precision will be ignored for specifiers s & c. Unfortunately, this information was missing from the API documentation in the Wiki. We just added this information to prevent confusion: wiki.segger.com/RTT#SEGGER_RTT_printf.28.29 For your specific use case, I would suggest to use snprintf() or similar, provided by the library of your choice. BR Fabian

Hi, good to hear that the problem could be resolved by a reboot! As the issue is resolved, we will close this thread now. Best regards, Fabian

Hi, Sorry for the delay in response. We were able to replicate the issue and fix it. A fix will be part of the next J-Link Software release planned for some time tomorrow (V7.88k). It will be available for download here: segger.com/downloads/jlink#J-L…twareAndDocumentationPack We are sorry for any inconvenience caused. BR Fabian

Hi Gabriel, RTT is already executed in background mode on the RM4x devices. The background AP is implemented natively, so no actions/script files on your side needed. You can verify this by opening the RTT tab in the J-Link Web Control Panel: wiki.segger.com/J-Link_-_Web_control_panel Only normal memory reads (e.g. via Mem32 in the J-Link Commander) will use stop mode, as background access mode is currently only used by RTT & HSS. I also answered you in the support ticket case. BR Fabian

Update: The following steps solved the issue: - In J-Link Commander, connect to the J-Link and issue the following command ResetConf - Powercycle the J-Link - In J-Link Commander, connect to the J-Link and issue the following command Calibrate BR Fabian

Hi Philipp, Sorry for the delay in response. We agree that a crash should be avoided here. We will add a "NULL" (or similar) return message at some point in the future. Please note that we are currently fully booked with projects, so we cannot provide a timeline for when this will be available. We will close this thread now. Best regards Fabian

Hi, we are not aware of any such issue. Does the issue also occur when using the latest J-Link Software version? segger.com/downloads/jlink#J-L…twareAndDocumentationPack Do you use custom hardware or an evaluation board? In the latter case which one? If custom hardware, do you experience the same problem on an evaluation board? Could you please provide the following? - A J-Link log file of a faulty download attempt? How to enable: wiki.segger.com/J-Link_DLL#Enable_J-Link_Log_File - A Small sampl…

Hi, Before replacing anything, did you make sure that VCOM was not disabled for the J-Link Compact? wiki.segger.com/Using_J-Link_VCOM_functionality BR Fabian

Hi, - Only one loader is loaded to RAM at a time, and - the RAM region used by the loader is restored after each programming sequence. BR Fabian

Hi, there is no such issue known to us. Would it be possible to send us the FL_Test*.FLM files so we can check on our side? Could you please send us a J-Link log file? How to enable: wiki.segger.com/J-Link_DLL#Enable_J-Link_Log_File BR Fabian

Hi, Thank you for your inquiry. We will answer you in the support ticket system regarding this. BR Fabian

Hi, No, it will not be reverted automatically. As a verification error indicates an issue during programming it would not really make sense to attempt another programming procedure to revert the changes, as this might very well fail again. The data on the target is not defined from the address where the verification failed onward. You can check it by reading back the programmed ranges. BR Fabian

Hi, Requests like this are handled in our Support Ticket system. Could you please create an inquiry regarding this there? Please also add a link to this forum thread, so the supporters know that these cases are related. Best regards, Fabian

Hi Sharon, Quote from sharon: “1. Where could I find the flash loader documrent to support older version? ” The older documentation is not available anymore, as it is a discontinued product. Quote from sharon: “When provide flash bankinfo in my device.xml, it seems must to provide flash loader, even I see the AlwaysPresent="0". Is it normal? ” If you specify a new flash bank via the xml, you definitively have to add a flash loader. Otherwise it would not really make sense to specify it, as no fl…

As Skvo correctly indicated, you are using a clone/cracked J-Link. Please note that the use of such a device in combination with our Software is illegal. We will close this thread now. BR Fabian

Hi, Connecting to the Apollo 3 devices should not trigger a reset by default, so connecting with the J-Link RTT Viewer should also not do so. Could you please 1) tell us what lead you to the conclusion that the device is reset on connect? 2) send us a picture of the Configuration Dialog of the J-Link RTT Viewer? 3) send us J-Link Log file of the RTT Viewer session that presumably resets the device? How to enable: wiki.segger.com/J-Link_DLL#Enable_J-Link_Log_File BR Fabian

Hi, Quote from Ouble: “Finally should I start a new thread if problems occur with loading and/or debugging the program onto the Due? Or should I ask in this thread? ” I think it is fine to stay in this thread regarding this. As it all concerns the sample project in the wiki that is discussed here. Quote from Ouble: “Is SWD functional in this case? ” Yes it is. The Connector is simply used to connect the signals between board and J-Link. See: segger.com/products/debug-prob…s/9-pin-cortex-m-adapte…