Search Results

Hello, the J-Link RTT Client uses the plain RTT Telnet interface, provided by another instance (IDE/J-Link Commander/etc.) The RTT Telnet interface is fixed to RTT channel 0, there is no way to change this setting. Best regards, Arne

Hello Elm, today's beta release will include a new version of the JLink RTT Viewer. It supports the new command line parameter "-b" or "--bright", activating a bright color scheme with dark text on white background. Best regards, Arne

Hi Manuel, the RTT Viewer's "terminal channel" is fixed to RTT channel 0 and it's "data channel" is fixed to RTT channel 1. The terminals itself are all virtual terminals sharing RTT channel 0. The terminal is switched using an ANSI command. You can log both types of channels with the recent version of the RTT viewer. Best regards, Arne

Hi Sébastien, in general, if you want to send data to the MCU, the the JLINK_RTTERMINAL_Write() function calls are relevant. We have changed the buffer size for sending and receiving over telnet connections to a total of 16kB. This ought to be enough for quick transfers using telnet. Thank you for pointing this out and best regards, Arne EDIT: Today's beta release will include the changed buffer sizes.

Hi, maybe it has something to do with this bug report: bugs.launchpad.net/gcc-arm-embedded/+bug/1566054 Best regards, Arne

Hello Christian, we are currently focusing on other projects, so unfortunately there is no release date for this feature yet. Best regards, Arne

Hi, I just gave it a try using KDS, the original ISR example and a FRDM-K64F board. As I already assumed, this is caused by an erroneous behavior of the call stack backtracking. Although the GDB client when used by KDS does not enter an infinite loop, it shows _isr_execute() being called recursively by itself. Probably KDS sets some kind of a backtrace limit to avoid the infinite loop. I suggest you to report the problem to the GDB developers. Meanwhile you can try to set a backtrace limit for y…

Hi, please take a look at the manual page 25 (regarding the "f" type). Best regards, Arne

Hi, yes, it is implemented in the V5.11d beta available here: segger.com/downloads/jlink_beta Your comments and feedback will be greatly appreciated. Best regards, Arne

Hi, could you please post the log from before the moment it's stuck? The memory read commands are useless as they are being served correctly by the GDB server. There might be an error/misbehavior before, that leads to the endless loop in the GDB client. But chances are high that the server behaves correctly but the client misinterprets the data ending in the loop. Maybe you could try a newer version of your toolchain? Best regards, Arne

Quote from v01d: “Quote from SEGGER - Arne: “your *complete* application and the hardware. Could you please send us the part of the GDB server from hitting the BP to the first "Read 4 bytes @ address 0x3F802804"? ” Complete application is easy, as this is just based on the MQX example. What do you mean by the "part of the GDB server from hitting the BP" ? All I could see is the trace read 4 bytes..” Hi, the GDB server's log should look like this: Source Code (12 lines) I'm interested in the part…

Hi, I consider this as a bug in the plugin. It will be changed in the next release, uxTopUsedPriority should be set to configMAX_PRIORITIES for the plugin. Additionally I have added support for using uxTopReadyPriority instead of uxTopUsedPriority, so you no longer need to set uxTopUsedPriority any more. Feel free to give feedback. Best regards, Arne

Hi, what value did you set uxTopUsedPriority to? configMAX_PRIORITIES? Best regards, Arne

Hi, pxOverflowDelayedTaskList is just a pointer to the task list holding overflowed tasks. It either points to xDelayedTaskList1 or xDelayedTaskList2, which both are being searched. Could you please check if the symbols xDelayedTaskList1 and xDelayedTaskList2 have the correct values? Best regards, Arne

Hi, finally we were able to reproduce it. The bug will be fixed in the next release, expected to be available later today. Best regards, Arne

Hi, do you need it to be fixed in the DLL? Best regards, Arne

Hi, the GDB server supports J-Link scriptfiles, too. "JLinkGDBServer.exe -device VF6xx_A5 -scriptfile Freescale_Vybrid_AccessA5.JLinkScript.txt" Best regards, Arne

Hi, did you change your hardware setup? Your last screenshot showed TotalIRLen = 14, while the current one shows TotalIRLen = 24. You can change the values for JTAG_IRPre and JTAG_DRPre in the script file according to your hardware setup. Best regards, Arne

Hi, please find attached a J-Link script file. Could you please give it a try? You can start J-Link commander using: "JLink.exe -JLinkScriptFile Freescale_Vybrid_AccessA5.JLinkScript.txt" There is no need to configure the device position, everything is set up in the script file. Best regards, Arne

Hi, I'm suspecting the GDB client causing this behavior. Most likely the GDB client is permanently requesting data from 0x3F802804. I know that some versions of the GDB client are not able to do a correct stack backtrace, when the (Cortex-M) CPU stops in an event handler. In most cases, there is only some garbage displayed in the call stack window. Maybe in your special case the GDB client gets confused in a way, that leads to an endless loop. Such problems are very hard to reproduce, since they…