Search Results

Hello, the FreeRTOS plugin is currently not tested with the Cortex-R CPU and therefore refuses to work with other cores than Cortex-M. What device and IDE are you using? Best regards, Arne

Hello, I am using a TMPM475 (should be the same as TMPM470 but with CAN interface) with your J-Scope project and a minimal application (register counter). It is currently running for over 20 minutes without any problems and with J-Link DLL/firmware v6.14d, no USB disconnect at all. Is there anything in your setup, I didn't regard? Do you leave your IDE connected to the MCU? Could you please check, if it works with a minimal application on your side? Regards, Arne

Hello, did you try using a blank target? This information would be very helpful, since it might have something to do with the application running on the target. Regards, Arne

Hello, thanks for the information, we have a TMPM475 evaluation board and will try to reproduce it. Could you please test, if the disconnect also appears if you use a blank device? Is it possible for you to send us the J-Scope project file? Meanwhile you can try to use our latest beta of J-Scope (v6.11f). If you want to downgrade the firmware, please have a look at the J-Link user manual UM08001 chapter 17.5. Downdating the firmware is not recommended and done on your own risk. Regards Arne

Hello, are you using Jscope 5.10d? If the J-Link disconnects, this is very likely an internal problem within the firmware. I just gave it a try with different v9 models and our emPower board, but all of them are working well. Could you please tell us the serial number of your J-Link? Which hardware are you connecting to?

Hi, the reason for why you have to specify the correct processor is the localization of the RTT block. Because every device has its RAM at a different location, the generic core can only be used in combination with either a fixed RTT block address or a RTT search range. To 1: I cannot reproduce that here, \n\r works as it should in the RTT Viewer. Are you using the latest version of the J-Link software? To 2: An automatic reconnect is not possible. You'll have to reconnect manually (F3/F2). Rega…

Hi, the J-Link RTT Logger logs the raw binary output on the selected RTT channel. It does not support virtual terminals as the J-Link RTT Viewer does, so any ANSI escape codes (the weird characters) are directly written into the output file. If you want to use the J-Link RTT Logger, just write to the RTT channel what you want to have in the logfile in plain text or replace the ANSI escape codes by yourself afterwards. Best regards Arne

Hi Alex, the plugin has an internal limit of a maximum of 63 priorities. Defines cannot be read by the GDB server, so it needs to rely on symbol base addresses. At first, it tries to read the symbol uxTopUsedPriority. As this symbol no longer exists in recent versions of FreeRTOS, it tries to use uxTopReadyPriority instead. Unfortunately this variable is treated in a different way, if configUSE_PORT_OPTIMISED_TASK_SELECTION is set to 1, so it does not work in this case and we cannot provide a pl…

Hi Mikael, thanks for the .elf file. The way, VisualGDB stores declarations of variables which are defined elsewhere, confused J-Scope's .elf file parser. We have released a new beta version, where this bug should be fixed: segger.com/downloads/jlink_beta Could you please download it and give it a try? Regards Arne

Hello Jack, the GDB server should not shut down, even if anything fails in the RTOS plugin. Is it possible for you to send us the project for reproduction? Regards Arne

Hi, we have decided not to change the DLL in this context. We will expand the usage of scriptfiles for devices requiring special handling, so JTAG configuration has to be done by editing these files. Best regards, Arne

Hello Dave, to test this, I have disabled the RTOS plugin and single-stepped to the location, the plugin reported as PC when the BT task got suspended. Attached is a screenshot of what I have got. I also compared the register values to the values reported from the plugin (these are taken from the stack memory, as the task is suspended there), they are 100% identical. I do not know, why the stack trace fails. Just one instruction ahead, it still was fine. But as you can see, this definitely has n…

Hello Dave, thanks for the project. You have turned on size optimization (-Os) for the debug build. This is the reason for the faulty stack trace. If you turn it off and rebuild the project with no optimization (-O0), it will work as expected. Best regards, Arne

Hello Dave, if it is not too large, just send it to segger.com/support/technical-support/ Best regards, Arne

Hello Dave, so far I was not able to reproduce it. Is it possible for you to send us the full project? If not, maybe you can strip it down to the specific task. Best regards, Arne PS: 0xA5 is the task stack fill byte, used for stack overflow detection (freertos.org/Stacks-and-stack-overflow-checking.html). This might have something to do with the value seen in the stack trace...

Hello Dave, it's unlikely, that the task itself is the cause. Any suspended task is treated in the same way, so I suspect the function call xQueueGenericReceive(). I just gave it a try using a sample project based on FreeRTOS V9.0.0 and a FRDM-K64F board, unfortunately the stack trace is OK and the task is suspended from within vPortYieldFromISR() called by xQueueGenericReceive(): Source Code (5 lines) Which version of FreeRTOS are you using? Is it possible for you to send us your queue.c file? …

Hello Dave, in general the IDE (KDS), or precisely its GDB client, is responsible for the stack trace. Did you turn on any compiler optimization? Regards Arne

Hi, the applications use different methods/objects for displaying the data. Some of them support CR, others do not. You can also use your favorite telnet application, just connect it to local port 19021. Best regards, Arne

Hi, we will change it back to configMAX_PRIORITIES-1, as this makes more sense and to be compatible with other solutions. Best regards, Arne

Hi Sébastien, there is one 8kB buffer for each sending and receiving. The wiki page is not a full reference for the JLink commander, it just gives some additional information on how to use it in automated environments. Best regards and thanks for providing feedback, Arne