The person best fitted to answer this is out of office at the moment. But I found some other links that may be helpful:
https://devzone.nordicsemi.com/f/nordic-q-a/69475/how-do-i-debug-free-rtos
https://devzone.nordicsemi.com/search?q=freertos%20systemview#serpgroup=17
Are they still out of office? I have already looked at these links and tried out to no avail
I couldn't find any of your project attachment in this thread. But the project attachment you did on another thread "smartwatch", I couldn't compile that at all because of my own C++ compiler issues. But the point is that this should work. Just some minor technicalities that you need to patch i guess.
SmartWatch 3.ziphere it is.
uncommenting out #include "SEGGER_SYSVIEW_FreeRTOS.h" in FreeRTOSConfig.h file results in a bunch of errors:
`ulTaskNotifyTake': 1> /Users/user/Projects/BLE/nRF5_SDK_17.0.2_d674dde/external/freertos/source/tasks.c:4481: undefined reference to `SEGGER_SYSVIEW_RecordU32x2' 1> /Applications/SEGGER Embedded Studio for ARM 5.42/gcc/arm-none-eabi/bin/ld: Output/Release/Obj/Init template - FreeRTOS/tasks.o: in function `vTaskNotifyGiveFromISR': 1> /Users/userhu/Projects/BLE/nRF5_SDK_17.0.2_d674dde/external/freertos/source/tasks.c:4859: undefined reference to `SEGGER_SYSVIEW_ShrinkId'
e....
it looks to me certain segger files aren't recognized hence the complaint about undefined references to the APIs. And as mentioned, the segger files are already included in the project via preprocessor. You can confirm by looking at the attached project
You have hardcoded path in your project to the project

I could try to fix those paths, but then that would ruin the purpose of testing your project as it is. You should always use relative paths in the project file.
Sorry, aren't these paths hardcoded in the preprocessor anyways? If so, the existing nordic projects in the SDK follow the same approach.
And I'm not sure how Segger IDE deals with it but I assumed if I send you my project and put it into SDK/examples/<Your-Folder>/<Another-Folder>, it would work the same for you as it does for me. And I just realized I sent you the entire solution instead of just the project itself which I'm yet to figure out how to save it.
But you can take a look at Init template - FreeRTOS
I am not really sure why we are seeing the difference. Mostly we are using different SES versions and/or you are using Mac and I am testing this on Windows.. I still get this after trying to patch few things in the folder naming.

The SES version I am using is this one
I am not really sure why we are seeing the difference. Mostly we are using different SES versions and/or you are using Mac and I am testing this on Windows.. I still get this after trying to patch few things in the folder naming.

The SES version I am using is this one
Your error says the project is already loaded. That's what you see after building it? You're making sure it's a clean project? For me, all I have to do is just add the existing project into my solution, set it as an active project and build it.
I'm not very great at Segger yet and there's a lot of things that still annoy me about it and i'm getting used to it
And yes i'm using a mac and there's minor differences in the versions but I don't think that should be a problem.

Yes, this is clean project just unzipped into a folder name Susheel1_ble_app_hrs_freertos instead of SmartWatch as it seems like there are some files added into your project which has the folder name Susheel1_ble_app_hrs_freertos hardcoded.
The error 'solution is already loaded' seems to be a bit confusing. The solution is not loaded anywhere else. There is no other SES instance on my PC other than this one which is reporting an error. After I click OK, then it loads the previous project I was debugging which is ble_app_beacon.
This is very strange because I cannot find any other thread which has similar issues on devzone. Seems like a project compatibility issue from Segger side within OS versions.
Can we try this one? It may not make a difference but I just tested it again on my machine, and it works ok. At least I'm able to open the solution and build it fine.
You could try the existing NRF's programs (ble_uart etc) but I'm mostly concerned about my own project regarding integrating SystemView.
The problem was caused for me from this changes in your .emProject file
<configuration Name="Common" gcc_cplusplus_language_standard="c++11" /> <import file_name="../../../../../peripheral/uart/pca10056/blank/ses/uart_pca10056.emProject" /> <import file_name="../../../../../peripheral/twi_sensor/pca10056/blank/ses/twi_sensor_pca10056.emProject" /> <import file_name="../../../../Susheel1_ble_app_hrs_freertos/pca10056/s140/ses/ble_app_hrs_freertos_pca10056_s140.emProject" /> <import file_name="../../../../../ble_peripheral/ble_app_uart/pca10056/s140/ses/ble_app_uart_pca10056_s140.emProject" /> <import file_name="../../../../../peripheral/blinky_freertos/pca10056/blank/ses/blinky_FreeRTOS_pca10056.emProject" />
I am now able to open the project but after that I have not managed to compile your cpp/hpp files with the project settings you sent. There must be some other dependency that is resolved in your system that makes SES resolve cpp linkage.
Good to know you can at least open the project.
Do you think it's too much an effort to investigate the main issue regarding now being able to get the program to compile after integrating the patch? I have also opened a ticket for Segger but so far no response.