Search Results

Hi Peter, as I said before, backtracing generally is the GDB client's job. It has to switch the stack on an exception return (to 0xfffffffd) if this is necessary. I do not see any chance to work around this lack of functionality from GDB server side. Best regards, Arne

Hi, no, the SDK is available free of charge. Best regards, Arne

Hi Jiri, the SDK is available now. Please contact sales@segger.com for the "J-Link GDB Server RTOS plug-in SDK". Best regards, Arne

Hi Peter, thank you very much for your positive feedback. Of course this feature will find its way into one of the the next stable versions, at least it will be in the official beta builds from now on. Future builds will accept a parameter after -excdbg, specifying the number of steps to do after the breakpoint. Some IDEs with automatic code generation might have their default handlers that only call custom code as a subroutine. This would require additional steps to get out of the exception han…

Hi Peter, please try this: download.segger.com/Arne/JLinkGDBServer.tar.gz This archive includes the libjlinkarm.so from the same build, works for me on a Debian jessie live system (hopefully on CentOS too). If it does not work for you, please let me know. Best regards, Arne

Hi Peter, you can do any evaluations by yourself in the hardfault handler, if you branch to different "bkpt n & bx lr" instruction blocks dependent on the fault register. The only requirement for the fault handler is to have the "bx lr" directly after the "bkpt n", everything else is up to you. Best regards, Arne

Hi, I have created a beta version with this feature: download.segger.com/Arne/JLinkGDBServer The GDB server must be started with the command line parameter "-excdbg". The hardfault handler must have a "bx lr" directly behind the "bkpt" and it must be declared with the naked attribute. The simplest implementation of a working hardfault handler: Source Code (7 lines) The immediate value of the bkpt instruction is directly passed as signal number to the GDB client. The above sample (signal number 1…

Hi, this might not be possible, you cannot access the debug/breakpoint registers from within your application. We maybe could implement in the GDB Server to do two single steps after a software BP. If your hardfault handler immediately does a branch to LR after the software BP, the PC should be exactly at the exception's cause. As a side effect you would no more need to do anything else, since the exception return is executed by the CPU and every register is restored to the state before the exce…

Hi, take the stacked PC (offset 24). This is the address that caused the exception. Best regards, Arne

Hi, this confirmed my suspicion, that the GDB client uses the wrong stack for its backtracing. You could try to replace the LR with the SP before the exception (saved on the stack). Best regards, Arne

Hi Jiri, the release of the SDK is planned for Friday the 17. I will post again as soon as it is available. Best regards, Arne

Hi, in the link you provided is to be read "works in conjunction with a tiny hard fault exception handler". I'm sure most of the work for getting the call stack built up correctly is done in this handler, as the call stack is completely generated by the GDB client using the GDB Server only for reading memory. We already have Tools, which can build up the call stack even from within an exception handler. Maybe you want to give Ozone - The J-Link Debugger a try? Our IDE Embedded Studio is also abl…

Hi, there were many different issues. Missing/empty lines in the call stack, registers disappeared from the registers pane up to complete crash of eclipse. You could try another IDE as a workaround, for example our own IDE Embedded Studio. It is available free of charge for non-profit educational purposes, supports Windows, Linux and Mac OSX and has an interface for viewing threads, too. Best regards, Arne

Hi, good to hear that is working now. I have also experienced lots of trouble with building the call stack in eclipse while developing the plug-ins. Unfortunately there is nothing I can do, because this is completely done inside eclipse and the GDB server only sees some "read memory" instructions while eclipse is building the call stack. Best regards, Arne

Hi, there was a problem within the build process causing both plug-ins to be identical in the linux and OSX builds. This will be fixed in the next release. I assume, you are using linux, right? Please find attached the correctly build plug-in. Best regards, Arne

Hi, it is the last received symbol "uxTopUsedPriority", return value NULL means it is not found. I already have changed the error message in the console to a more informative one. If your console output (starting with the first "Received symbol") is different, please post it here. Best regards Arne

Hi Jiri, thanks for your interest in the SDK. We are still doing some final work on the SDK, it probably will be available in about a week. Best regards, Arne

Most probably the plugin does not find all the required symbols. There was a change in FreeRTOS, that eliminated a mandatory symbol. In this case, you should see something like this in your console: Source Code (12 lines) You can use the same patch as for OpenOCD to reintroduce the missing symbol: github.com/gnuarmeclipse/openo…elpers/FreeRTOS-openocd.c

Hi Elm, here is a preview beta version with the bugfix for you. Best regards, Arne

Hi Elm, thanks for your feedback. We will fix the bug in our next release. Best regards, Arne