Hello everybody, I have the following problem. The scenario first: * Custom board (fully tested) with Kinetis K10 MCU * Kinetis Design Studio 3.0.0 * Pemicro Multilink Universal debugger * FreeRTOS 9.0.0 (I’m using the GCC / Cortex M3 port) * I’m not using Processor Expert The problem: when debugging a program with FreeRTOS, I can set breakpoints and step through code, but when I try to return from a function by stepping on its last instruction (i.e. closing curly bracket), gdb crashes. In the console I get the following errors: Unable to go into background mode. Error communicating to target processor – try a RESET. PE-ERROR: TARGET IS RUNNING The same program works as expected if I let it run without debugging. Please note that when I debug a program that doesn’t use FreeRTOS everything works like a charm. In assembler, the offending instruction that causes the crash to happen is ‘mov sp,r7’. I noticed that at this point the PSP is used instead of MSP. After stepping on this instruction the crash occurs and the disassembly window shows: -__isr_vector followed by rows of
Also, in FreeRTOSConfig.h, I have defined configTASKRETURNADDRESS 0 /* return address of task is zero */ as suggested in some posts.
Thank you in advance for your help, which would be greatly appreciated.
Hi Alex, I have not seen anything like this. But I would recommend that you check if you have the latest P&E plugins installed. Use the Eclipse menu Help > Install New Software and use the follwing upate site: http://www.pemicro.com/eclipse/updates I hope this helps, Erich
Hi Erich, Thank you for your quick reply. I actually tried with two different PC’s, one with the latest P&E plugins installed. Unfortunately in both cases GDB crashes … (also, on the PC with the latest plugins, sometimes the disassembly window doesn’t show any code (just a series of dots ….); closing this window and reopening it with Window – Show View – Disassembly doesn’t work either). I really don’t know what’s going on. Any ideas ? Would you rule out a HW problem (although it seems very unlikely to me) ? Thank you Alex
Hi Alex, I don’t have a K10, but I don’t think it is a hardware problem or like that. If you have access to a Segger J-Link, then you could try a different debug connection. The message ‘unable to go into background mode’ indicates that the debugger is not able to talk anymore to the target. This typically happens with low voltage (power supply problem). Erich
Hi Erich, Thank you for your reply. Unfortunately I don’t have a Segger J-Link to try another connection. To me it looks like a GDB problem. Here is what I get in the GDB console after the crash: 129,750 =thread-group-exited,id=”i1″ 129,750 ~”/home/build/work/GCC-4-8-build/src/gdb/gdb/thread.c:72: internal-error: inferiorthread: Assertion tp failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? ” 129,750 ~”(y or n) [answered Y; input not from terminal]” 129,750 ~”/home/build/work/GCC-4-8-build/src/gdb/gdb/thread.c:72: internal-error: inferiorthread: Assertion tp failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? ” 129,750 ~”(y or n) [answered Y; input not from terminal]” 129,785 63-gdb-exit Does the above give you any indication about what may be wrong ? Thanks again for your help Alex
Hi Alex, no, this does not tell me what the problem is. You might try with a later version of GDB, maybe this helps. Erich
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.