Search Results

Hi, Thanks for the update. Good to hear that it is solved. - Alex

Hi, Sorry for the late reply, busy days... We are currently working on STM32L0 support and hope to have this ready by the end of next week (maybe earlier). It is planned to be part of V4.87a (beta). - Alex

Hi, Quote: “I notice that the WARNING: Unknown packet received: "qXfer:threads:read::0,fff" is a new message I have not seem in the previous releases, any ideas?” Unfortunately, this has been introduced in V4.86, since support for some new commands, sent by GDB, has been implemented. This implementation was faulty. Corrected in V4.86a. Sorry for any inconveniences caused. V4.86a: segger.com/jlink-software.html - Alex

Hi, Usually, it is just installing an older version, that's it. Anyhow, we have released V4.86a in which this problem has been solved. segger.com/jlink-software.html - Alex

Hi Larry, We already found the problem. This has unfortunately be introduced in the latest version by supporting some additional GDB commands. A fixed version comes later this week (probably tomorrow) Sorry for any inconveniences caused. Best regards Alex

Hi, Just checked this here. It is working absolutely fine. Programming, erasing, reading back etc. multiple times is absolutely no problem. No strange "recovery" sequences needed etc. If the LIS331EB is secured, this is properly detected by J-Flash and unsecure als succeeds. forum.segger.com/index.php/Att…6524e772df832ee54d44724fc Please find attached the J-Flash project file we used for verification. Did you make sure that your SWD signal quality is good, to guarantee a stable connection? Quote…

Hi, Just to make sure that I get everything correctly: Both boards are working fine with SWOViewer Only the K40 is working when used via GDBServer Correct so far? Did you check the SWO line via an socilloscope if there is any data output at all? Maybe it is a frequency issue... The problem with SWO is that the CPU and J-Link need to use the same frequency for sending + sampling SWO data (UART protocol), otherwise you will not receive correct SWO data. Now, J-Link supports a way of auto-detecting…

Hi, Alright, seems I misunderstood you. Yes, while J-Link is not used / no debugger is connected to it from the software side, the target interface is tri-stated / disabled. Best regards Alex

Hi, Quote: “I was hoping that the j-link is providing the power supply.” It actually can, but for this, you need to know what you are doing. J-Link is capable of providing 5V on pin 19 if power supply via J-Link is enabled (See UM08001 for more information). Anyhow, good to hear that it is working now. - Alex

Hi Kenny, Good to hear that it is working after all. - Alex

Hi, Thanks for the feedback. Good to hear that it is working now. - Alex

Hi, Quote: “When not debugging and the pin is outputting a GPIO signal, there's the risk of short circuiting.” If you do this, your debug session will fail/crash... Quote: “I already know RS-232 lets you short circuit the TX & RX pins indefinitely (I've tested this and the current is limited to 30mA). Is there such protection for the SWDIO & SWCLK on the J-Link?” You can do this on your own risk, if you really want to. J-Link will not be damaged if this happens. If your target is damaged depends…

Hi, Quote: “ Sorry: I tried to improve the formatting below and failed.” I fixed this for you... The configuration looks fine so far. Unfortunately, the J-Link model you are using is out of support, so I cannot assign a high priority to this. Anyhow, I have added this to the list of investigations to be done within the next weeks in order to check if we can reproduce this problem. - Alex

Hi, What external flash? - Parallel CFI NOR flash - Serial NOR flash - NAND flash - Serial EEPROM - Alex

Hi, The new beta version (V4.85e) which comes with this feature, is available for download: segger.com/jlink-software-beta-version.html Short feedback would be appreciated. - Alex

Hi, Quote: “Is it the call thats causing the fault, or is it that the value popped off the stack is supposed to be the address to the SendChar routine, and its not? ” Why don't you debug this?... Perform a single instruction step on the BL JLINKMEM_SendChar() will tell you if it is the call of the function etc. what is causing the HardFault... And to check from where the CPU jumped to the HardFault, the easiest way would be: - Set a breakpoint into the HardFault handler - Hit the breakpoint - Se…

Hi, For a normal system reset, the reset signal is not used on Cortex-M devices. The reset is done via software. The reset signal is only used for cases where a "connect under reset" needs to be done because the debug logic cannot be longer accessed via software (and so a software initiated reset would also not work) Best regards Alex

Hi, Quote: “Perhaps I'm being paranoid but is it correct to say that the blue wire of the 20-pin ribbon cable connects to the upper pin of the of the connector? ” "Upper" is relative and depends on how you look at the J-Link... If put it on your desk and look on the connector, pin 1 is the "upper right pin"... - Alex

Hi Hila, in general, one instance of the J-Link DLL can only connect to one core at the same time. If you want to connect to both cores in parallel, you will need a second instance of the J-Link DLL (here J-Link Commander). If you want to connect to the second core, you will further need to tell J-Link how to connect to it. By default, it will connect to the first core found in the CoreSight info. In order to connect to the second core, you need to configure its base address of its debug registe…

Hi, It can be used on any interface (JTAG, SWD, FINE, 2-wire-JTAG-PIC32,...) & supported core (ARM, RX, PIC32, ...). Could you please provide some more information?: - The exact call you are performing - The device (Manufacturer + Device name) you are using - The complete sequence, preceding the ReadMem() call - Alex