[rtl872x] fix openocd FreeRTOS thread view

[scott-brust]

Problem

Openocd experiences an error when attempting to retrieve the Freertos symbols needed to debug on RTL872X platforms.
The error is related to the uxTopUsedPriority definition. This definition is used by openocd to determine how many lists of threads exist. Openocd will search for threads beyond the number of existing thread lists, return an error when trying to parse a random memory location and abandon using FreeRTOS symbols at all.

I dont know why the NRF platforms do not have this issue, since they should also be "off by 1" with the number of tasks/priorities.

Solution

Decrement uxTopUsedPriority to not search beyond the list of valid threads

Steps to Test

Flash device os from this branch, attach debugger, run info threads command. All FreeRTOS threads should be enumerated.

Example App

any

References

Openocd section 20.6

---

Completeness

• User is totes amazing for contributing!
• Contributor has signed CLA (Info here)
• Problem and Solution clearly stated
• Run unit/integration/application tests on device
• Added documentation
• Added to CHANGELOG.md after merging (add links to docs and issues)

[YutingYou]

🎉🎉🎉

I dont know why the NRF platforms do not have this issue, since they should also be "off by 1" with the number of tasks/priorities.

Probably due to dual-core architecture.

I previously found the OpenOCD is trying to access some dirty address.

Debug: 3293 1025513 FreeRTOS.c:307 FreeRTOS_update_threads(): FreeRTOS: Read thread count for list 10 at 0x10018b98, value 1
Debug: 3294 1025515 target.c:2589 target_read_u32(): address: 0x10018ba8, value: 0x10018ba0
Debug: 3295 1025515 FreeRTOS.c:324 FreeRTOS_update_threads(): FreeRTOS: Read first item for list 10 at 0x10018ba8, value 0x10018ba0
Debug: 3296 1025517 target.c:2589 target_read_u32(): address: 0x10018bac, value: 0x00000003
Debug: 3297 1025517 FreeRTOS.c:342 FreeRTOS_update_threads(): FreeRTOS: Read Thread ID at 0x10018bac, value 0x3
Debug: 3298 1025517 target.c:2442 target_read_buffer(): reading buffer of 200 byte at 0x00000037

For single core, the flash usually starts at 0x00000000, it's fine for debugger to access this address.

For RTL872x, it is dual-core, we debug KM4 via AP2 while debug KM0 via AP1. The memory address 0x00000000 belongs to KM0's ROM, which means the debugger trys to access KM0's data from KM4 side, this might cause a BUS Fault and then OpenOCD stops to parse thread context.

[scott-brust]

🎉🎉🎉

I dont know why the NRF platforms do not have this issue, since they should also be "off by 1" with the number of tasks/priorities.

Probably due to dual-core architecture.

I previously found the OpenOCD is trying to access some dirty address.

Debug: 3293 1025513 FreeRTOS.c:307 FreeRTOS_update_threads(): FreeRTOS: Read thread count for list 10 at 0x10018b98, value 1
Debug: 3294 1025515 target.c:2589 target_read_u32(): address: 0x10018ba8, value: 0x10018ba0
Debug: 3295 1025515 FreeRTOS.c:324 FreeRTOS_update_threads(): FreeRTOS: Read first item for list 10 at 0x10018ba8, value 0x10018ba0
Debug: 3296 1025517 target.c:2589 target_read_u32(): address: 0x10018bac, value: 0x00000003
Debug: 3297 1025517 FreeRTOS.c:342 FreeRTOS_update_threads(): FreeRTOS: Read Thread ID at 0x10018bac, value 0x3
Debug: 3298 1025517 target.c:2442 target_read_buffer(): reading buffer of 200 byte at 0x00000037

For single core, the flash usually starts at 0x00000000, it's fine for debugger to access this address.

For RTL872x, it is dual-core, we debug KM4 via AP2 while debug KM0 via AP1. The memory address 0x00000000 belongs to KM0's ROM, which means the debugger trys to access KM0's data from KM4 side, this might cause a BUS Fault and then OpenOCD stops to parse thread context.

👍 that all makes sense and explains what im seeing.

Debug: 3298 1025517 target.c:2442 target_read_buffer(): reading buffer of 200 byte at 0x00000037

I think this is the problem addressed in this PR. You can try applying this change to NRF concurrent_hal.cpp and see if it goes away. In fact, I think we should apply this change to the NRF HAL regardless. I will test it tomorrow

[YutingYou]

Approve this PR becasue the recommended usage for uxTopUsedPriority is configMAX_PRIORITIES - 1
see: https://github.com/openocd-org/openocd/blob/v0.12.0/contrib/rtos-helpers/FreeRTOS-openocd.c#L22

It appears that OpenOCD aims to add one for compatibility.

/* uxTopUsedPriority was defined as configMAX_PRIORITIES - 1
 * in old FreeRTOS versions (before V7.5.3)
 * Use contrib/rtos-helpers/FreeRTOS-openocd.c to get compatible symbol
 * in newer FreeRTOS versions.
 * Here we restore the original configMAX_PRIORITIES value */
unsigned int config_max_priorities = top_used_priority + 1;

see:
https://github.com/openocd-org/openocd/blob/v0.12.0/src/rtos/FreeRTOS.c#L271

[YutingYou]

Again, thanks for the effort to figure out this annoyed issue! This can greatly help to improve debugging efficiency.