Hello all,
I've been developing some application for quite a while and I now went into a weird error.
Description of the development:
It was all working correctly until I added some more code (yes, I know it probably have something to do with it, nevertheless this behavior is not expected), I could add breakpoints throughout the code, execute instructions step by step wherever I wanted. After adding this piece of code, I can step into the code until the first xTaskCreate. To be more specific, the exact point where things go wrong is inside the function prvAddNewTaskToReadyList(), instruction pxCurrentTCB = pxNewTCB;. If I step into this function (should stop at the next instruction), the firmware starts executing as if I pressed Resume, I can still pause the software and it kind of works. If I add any breakpoints to try to stop the FW after the mentioned instruction, the debug section breaks and I get the following messages on the terminal "[GDB SEGGER J-Link Debugging] JLinkGDBServerCL":
I tried the same process using the j-Trace Pro and got the same results.
Any ideas?
Best regards,
Bruno
I've been developing some application for quite a while and I now went into a weird error.
Description of the development:
- MK22FN512VLH12 (custom board)
- FreeRTOS 9.0.0, custom heap from here: nadler.com/embedded/newlibAndFreeRTOS.html
- newlib (no semihosting)
- SEGGER RTT
- Debuger "Other Options" contains: "-s -rtos GDBServer/RTOSPlugin_FreeRTOS" (everything else is pretty standard)
- J-Link Plus Debug tool
- J-Link Software version 6.30e
- IDE KDS 3.2.0
- GCC toolchain version 6 Q2 2017
- The exact same problem happened with a FRDM-K82F dev board, another FreeRTOS 9.0.0 based firmware, using MCUXpresso 10.1.1 and some older version of the J-Link software
It was all working correctly until I added some more code (yes, I know it probably have something to do with it, nevertheless this behavior is not expected), I could add breakpoints throughout the code, execute instructions step by step wherever I wanted. After adding this piece of code, I can step into the code until the first xTaskCreate. To be more specific, the exact point where things go wrong is inside the function prvAddNewTaskToReadyList(), instruction pxCurrentTCB = pxNewTCB;. If I step into this function (should stop at the next instruction), the firmware starts executing as if I pressed Resume, I can still pause the software and it kind of works. If I add any breakpoints to try to stop the FW after the mentioned instruction, the debug section breaks and I get the following messages on the terminal "[GDB SEGGER J-Link Debugging] JLinkGDBServerCL":
The last 4 lines keep repeating forever and I can't pause the debugger. If I click Stop, it takes a long time and gives me an error message "Connection Shut Down" (but eventually stops)....Breakpoint reached @ address 0x00015290 ///----------------------------------------that's the breakpoint on the start of main()
Reading all registers
Read 4 bytes @ address 0x00015290 (Data = 0xFA63F00B)
Removing breakpoint @ address 0x00015290, Size = 2
Removing breakpoint @ address 0x0001989C, Size = 2
Removing breakpoint @ address 0x000198C6, Size = 2
Setting breakpoint @ address 0x0001989C, Size = 2, BPHandle = 0x0004
Setting breakpoint @ address 0x000198C6, Size = 2, BPHandle = 0x0005
Performing single step...
...Breakpoint reached @ address 0x0002075A
Reading all registers
Read 4 bytes @ address 0x0002075A (Data = 0xAF00B580)
Setting breakpoint @ address 0x00015290, Size = 2, BPHandle = 0x0006
Starting target CPU...
...Breakpoint reached @ address 0x0001989C
Reading all registers
Read 4 bytes @ address 0x00000000 (Data = 0x1FFFD1A0)
Starting target CPU...
...Breakpoint reached @ address 0x0001989C
Reading all registers
Read 4 bytes @ address 0x00000000 (Data = 0x1FFFD1A0)
Starting target CPU...
...Breakpoint reached @ address 0x0001989C
Reading all registers
Read 4 bytes @ address 0x00000000 (Data = 0x1FFFD1A0)
Starting target CPU...
I tried the same process using the j-Trace Pro and got the same results.
Any ideas?
Best regards,
Bruno