[SOLVED] SetRTTSearchRanges command not working

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] SetRTTSearchRanges command not working

    Greetings,
    Problem is that RTT buffer cannot be automatically located. The only way I can get it to work is if I specify it explicitly through
    SetRTTAddr. In my case the command would be:
    SetRTTAddr 0x700679c0
    Obviously there is shortcoming using SetRTTAddr because this address is likely to change often when new data is added to code. It seems that the SetRTTSearchRanges command does not work at all. For example if I use either of the commands below they will fail to find the buffer
    SetRTTSearchRanges 0x70060000 0x10000
    SetRTTSearchRanges 0x700679c0 0x100
    You can see that the second example points to the exact address with a range and so should easily find it although it does not. Can you pleaseverify that this command works? When does JLink do search for RTT buffer?
    Thanks,
    Man
  • Hi Man,


    we are currently not aware of any issues regarding SetRTTSearchRanges.
    Which target device are you using?
    Could you provide us with a reproducer?


    Best regards,
    Niklas
    Would you like to be added to the J-Link software update notification list, so you get informed automatically when a new version becomes available?
    Just write me a PM or in case you want to subscribe to it yourself, please use this link: Link
    Notification for J-Link, J-Link Debugger, SystemView & J-Scope: Link
    Notification for Embedded Studio: Link
  • Niklas,
    I am developing on Microsemi A2f200 which has Cortex-M3 core. I am using JLink Plus with v620 JLinkGDBServer. Code is debugged and developed on Ubuntu linux in Eclipse Neon.3

    I manually type the SetRTTSearchRanges command in Debugger Console in eclipse after loading and running to main() but prior to running application.
    The command I issue in Debugger console is:

    monitor exec SetRTTSearchRanges XXXX XXXX

    As mentioned before, entering SetRTTAddr command in Debugger console works.

    The application calls SEGGER_RTT_Init () followed by SEGGER_RTT_ConfigUpBuffer(...) prior to any other RTT API calls to output.

    All code and initialized data is loaded in RAM external to processor.

    When does JLinkDebugger search for RTT buffer? As soon as application runs? When RTT client connects? Constantly?

    Thanks,
    Man
  • Hi,

    I just set up a sample project for a A2F200M3F and autodetection worked fine.
    I used the internal RAM for RTT (@ 0x20000000). What Memory do you use @ 0x700679c0 ?
    Could you provide a reproducer application?

    Best regards,
    Niklas
    Would you like to be added to the J-Link software update notification list, so you get informed automatically when a new version becomes available?
    Just write me a PM or in case you want to subscribe to it yourself, please use this link: Link
    Notification for J-Link, J-Link Debugger, SystemView & J-Scope: Link
    Notification for Embedded Studio: Link
  • Niklas,
    Memory located starting at 0x70000000 is PSRAM in external memory controller address space.

    If I locate RTT buffer in processor RAM (0x20000000) RTT buffer is always automatically found.
    I did not see anywhere in RTT documentation that indicates RTT buffer must be located in processor
    memory space as opposed to external RAM. Perhaps it is something I overlooked if this is so.

    I do however have another problem that I avoided mentioning until now. RTT crashes our application.
    This did not start when I moved RTT buffer to processor RAM, the problem existed when I had the buffer
    in external RAM. If I start our application in debugger when JLinkRTTClient is not running it will run normally.
    As soon as I start JLinkRTTClient some output will be displayed in client but application crashes on hardware fault.
    I am not able to trace.


    A2f200 uses 5 bits for interrupt priority. I set...

    #define SEGGER_RTT_MAX_INTERRUPT_PRIORITY (1 << (32-5))

    I am working on building reproducer application.

    Any other suggestions until then are appreciated.

    Thanks,
    Man
  • Niklas,
    Minimum FreeRTOS project that will exhibit crash on Microsemi A2F200 is the code below.

    This code runs fine on Freescale MK10DX256xxx7. On A2F200 it will output anywhere from a few lines to
    to several pages before hardfault. Cortex Hard Fault Status Register value (0x40000000) indicates the reason for fault is "hardfault triggered by debug event".

    For A2F200
    #define SEGGER_RTT_MAX_INTERRUPT_PRIORITY (1 << (32 - 5))

    For MK10DX256xxx7
    #define SEGGER_RTT_MAX_INTERRUPT_PRIORITY (0x20)


    C Source Code

    1. #include "FreeRTOS.h"
    2. #include "task.h"
    3. #include "SEGGER_RTT.h"
    4. static void rtt_print_test(void) {
    5. static unsigned _Cnt;
    6. SEGGER_RTT_WriteString(0, "SEGGER Real-Time-Terminal Sample\r\n\r\n");
    7. SEGGER_RTT_WriteString(0, "###### Testing SEGGER_printf() ######\r\n");
    8. SEGGER_RTT_printf(0, "printf Test: %%c, 'S' : %c.\r\n", 'S');
    9. SEGGER_RTT_printf(0, "printf Test: %%5c, 'E' : %5c.\r\n", 'E');
    10. SEGGER_RTT_printf(0, "printf Test: %%-5c, 'G' : %-5c.\r\n", 'G');
    11. SEGGER_RTT_printf(0, "printf Test: %%5.3c, 'G' : %-5c.\r\n", 'G');
    12. SEGGER_RTT_printf(0, "printf Test: %%.3c, 'E' : %-5c.\r\n", 'E');
    13. SEGGER_RTT_printf(0, "printf Test: %%c, 'R' : %c.\r\n", 'R');
    14. SEGGER_RTT_printf(0, "printf Test: %%s, \"RTT\" : %s.\r\n", "RTT");
    15. SEGGER_RTT_printf(0, "printf Test: %%s, \"RTT\\r\\nRocks.\" : %s.\r\n", "RTT\r\nRocks.");
    16. SEGGER_RTT_printf(0, "printf Test: %%u, 12345 : %u.\r\n", 12345);
    17. SEGGER_RTT_printf(0, "printf Test: %%+u, 12345 : %+u.\r\n", 12345);
    18. SEGGER_RTT_printf(0, "printf Test: %%.3u, 12345 : %.3u.\r\n", 12345);
    19. SEGGER_RTT_printf(0, "printf Test: %%.6u, 12345 : %.6u.\r\n", 12345);
    20. SEGGER_RTT_printf(0, "printf Test: %%6.3u, 12345 : %6.3u.\r\n", 12345);
    21. SEGGER_RTT_printf(0, "printf Test: %%8.6u, 12345 : %8.6u.\r\n", 12345);
    22. SEGGER_RTT_printf(0, "printf Test: %%08u, 12345 : %08u.\r\n", 12345);
    23. SEGGER_RTT_printf(0, "printf Test: %%08.6u, 12345 : %08.6u.\r\n", 12345);
    24. SEGGER_RTT_printf(0, "printf Test: %%0u, 12345 : %0u.\r\n", 12345);
    25. SEGGER_RTT_printf(0, "printf Test: %%-.6u, 12345 : %-.6u.\r\n", 12345);
    26. SEGGER_RTT_printf(0, "printf Test: %%-6.3u, 12345 : %-6.3u.\r\n", 12345);
    27. SEGGER_RTT_printf(0, "printf Test: %%-8.6u, 12345 : %-8.6u.\r\n", 12345);
    28. SEGGER_RTT_printf(0, "printf Test: %%-08u, 12345 : %-08u.\r\n", 12345);
    29. SEGGER_RTT_printf(0, "printf Test: %%-08.6u, 12345 : %-08.6u.\r\n", 12345);
    30. SEGGER_RTT_printf(0, "printf Test: %%-0u, 12345 : %-0u.\r\n", 12345);
    31. SEGGER_RTT_printf(0, "printf Test: %%u, -12345 : %u.\r\n", -12345);
    32. SEGGER_RTT_printf(0, "printf Test: %%+u, -12345 : %+u.\r\n", -12345);
    33. SEGGER_RTT_printf(0, "printf Test: %%.3u, -12345 : %.3u.\r\n", -12345);
    34. SEGGER_RTT_printf(0, "printf Test: %%.6u, -12345 : %.6u.\r\n", -12345);
    35. SEGGER_RTT_printf(0, "printf Test: %%6.3u, -12345 : %6.3u.\r\n", -12345);
    36. SEGGER_RTT_printf(0, "printf Test: %%8.6u, -12345 : %8.6u.\r\n", -12345);
    37. SEGGER_RTT_printf(0, "printf Test: %%08u, -12345 : %08u.\r\n", -12345);
    38. SEGGER_RTT_printf(0, "printf Test: %%08.6u, -12345 : %08.6u.\r\n", -12345);
    39. SEGGER_RTT_printf(0, "printf Test: %%0u, -12345 : %0u.\r\n", -12345);
    40. SEGGER_RTT_printf(0, "printf Test: %%-.6u, -12345 : %-.6u.\r\n", -12345);
    41. SEGGER_RTT_printf(0, "printf Test: %%-6.3u, -12345 : %-6.3u.\r\n", -12345);
    42. SEGGER_RTT_printf(0, "printf Test: %%-8.6u, -12345 : %-8.6u.\r\n", -12345);
    43. SEGGER_RTT_printf(0, "printf Test: %%-08u, -12345 : %-08u.\r\n", -12345);
    44. SEGGER_RTT_printf(0, "printf Test: %%-08.6u, -12345 : %-08.6u.\r\n", -12345);
    45. SEGGER_RTT_printf(0, "printf Test: %%-0u, -12345 : %-0u.\r\n", -12345);
    46. SEGGER_RTT_printf(0, "printf Test: %%d, -12345 : %d.\r\n", -12345);
    47. SEGGER_RTT_printf(0, "printf Test: %%+d, -12345 : %+d.\r\n", -12345);
    48. SEGGER_RTT_printf(0, "printf Test: %%.3d, -12345 : %.3d.\r\n", -12345);
    49. SEGGER_RTT_printf(0, "printf Test: %%.6d, -12345 : %.6d.\r\n", -12345);
    50. SEGGER_RTT_printf(0, "printf Test: %%6.3d, -12345 : %6.3d.\r\n", -12345);
    51. SEGGER_RTT_printf(0, "printf Test: %%8.6d, -12345 : %8.6d.\r\n", -12345);
    52. SEGGER_RTT_printf(0, "printf Test: %%08d, -12345 : %08d.\r\n", -12345);
    53. SEGGER_RTT_printf(0, "printf Test: %%08.6d, -12345 : %08.6d.\r\n", -12345);
    54. SEGGER_RTT_printf(0, "printf Test: %%0d, -12345 : %0d.\r\n", -12345);
    55. SEGGER_RTT_printf(0, "printf Test: %%-.6d, -12345 : %-.6d.\r\n", -12345);
    56. SEGGER_RTT_printf(0, "printf Test: %%-6.3d, -12345 : %-6.3d.\r\n", -12345);
    57. SEGGER_RTT_printf(0, "printf Test: %%-8.6d, -12345 : %-8.6d.\r\n", -12345);
    58. SEGGER_RTT_printf(0, "printf Test: %%-08d, -12345 : %-08d.\r\n", -12345);
    59. SEGGER_RTT_printf(0, "printf Test: %%-08.6d, -12345 : %-08.6d.\r\n", -12345);
    60. SEGGER_RTT_printf(0, "printf Test: %%-0d, -12345 : %-0d.\r\n", -12345);
    61. SEGGER_RTT_printf(0, "printf Test: %%x, 0x1234ABC : %x.\r\n", 0x1234ABC);
    62. SEGGER_RTT_printf(0, "printf Test: %%+x, 0x1234ABC : %+x.\r\n", 0x1234ABC);
    63. SEGGER_RTT_printf(0, "printf Test: %%.3x, 0x1234ABC : %.3x.\r\n", 0x1234ABC);
    64. SEGGER_RTT_printf(0, "printf Test: %%.6x, 0x1234ABC : %.6x.\r\n", 0x1234ABC);
    65. SEGGER_RTT_printf(0, "printf Test: %%6.3x, 0x1234ABC : %6.3x.\r\n", 0x1234ABC);
    66. SEGGER_RTT_printf(0, "printf Test: %%8.6x, 0x1234ABC : %8.6x.\r\n", 0x1234ABC);
    67. SEGGER_RTT_printf(0, "printf Test: %%08x, 0x1234ABC : %08x.\r\n", 0x1234ABC);
    68. SEGGER_RTT_printf(0, "printf Test: %%08.6x, 0x1234ABC : %08.6x.\r\n", 0x1234ABC);
    69. SEGGER_RTT_printf(0, "printf Test: %%0x, 0x1234ABC : %0x.\r\n", 0x1234ABC);
    70. SEGGER_RTT_printf(0, "printf Test: %%-.6x, 0x1234ABC : %-.6x.\r\n", 0x1234ABC);
    71. SEGGER_RTT_printf(0, "printf Test: %%-6.3x, 0x1234ABC : %-6.3x.\r\n", 0x1234ABC);
    72. SEGGER_RTT_printf(0, "printf Test: %%-8.6x, 0x1234ABC : %-8.6x.\r\n", 0x1234ABC);
    73. SEGGER_RTT_printf(0, "printf Test: %%-08x, 0x1234ABC : %-08x.\r\n", 0x1234ABC);
    74. SEGGER_RTT_printf(0, "printf Test: %%-08.6x, 0x1234ABC : %-08.6x.\r\n", 0x1234ABC);
    75. SEGGER_RTT_printf(0, "printf Test: %%-0x, 0x1234ABC : %-0x.\r\n", 0x1234ABC);
    76. SEGGER_RTT_printf(0, "printf Test: %%p, &_Cnt : %p.\r\n", &_Cnt);
    77. SEGGER_RTT_WriteString(0, "###### SEGGER_printf() Tests done. ######\r\n");
    78. }
    79. static void __InitialTask(void *param)
    80. {
    81. SEGGER_RTT_Init ();
    82. while(1)
    83. {
    84. rtt_print_test();
    85. }
    86. }
    87. int main()
    88. {
    89. xTaskCreate( &__InitialTask,
    90. (const signed char * const) "",
    91. configMINIMAL_STACK_SIZE,
    92. 0,
    93. 8,
    94. 0 );
    95. vTaskStartScheduler();
    96. return 0;
    97. }
    Display All

    The post was edited 1 time, last by Mantequilla ().

  • Hi,


    could please share the code you use the init the PSRAM?


    Best regards,
    Niklas
    Would you like to be added to the J-Link software update notification list, so you get informed automatically when a new version becomes available?
    Just write me a PM or in case you want to subscribe to it yourself, please use this link: Link
    Notification for J-Link, J-Link Debugger, SystemView & J-Scope: Link
    Notification for Embedded Studio: Link
  • Niklas,
    We use UBOOT to copy application from NOR flash to external PSRAM on startup however UBOOT does not do initialization for PSRAM.
    Initialization is done through FPGA fabric prior to jumping to UBOOT. Settings are as follows.

    Port Size..................................................................................Half Word
    Read Latency for First Access (HCLK cycles).........................6
    Read Latency for Remaining Accesses (HCLK Cycles)..........6
    Write Latency (HCLK Cycles)..................................................6
    Configure BYTEN Port as........................................................Byte Enable
    Interdevice Latency (HCLK cycles)..........................................1

    Processor clock is 72mhz.

    It may not have been clear from previous posts but hardfault occurs when using RTT regardless of whether RTT buffer is in PSRAM or
    on board processor RAM. The only difference is that RTT buffer is auto detected when located in processor RAM but not in external
    PSRAM. I am able to leave RTT buffer in processor RAM so detection issue is no longer a problem unless it is supposed to also
    work when in external RAM.

    Hope this helps.

    Man

    The post was edited 1 time, last by Mantequilla ().

  • Niklas,
    The values loaded into Microsemi A2F200M3F external memory controller registers are:

    EMC_MUX_CR = 0x00000001
    EMC_CS_0_CR = 0x0020B335 - PSRAM
    EMC_CS_1_CR = 0x0021D3BF - NOR Flash

    You mentioned in a previous post that you loaded a project into A2F200M3F and SetRTTSearchRanges worked. Can I assume that RTT also worked without issues?
    What demo board are you using? We have two different ones here and if one is same as you use I would like to test RTT on it.

    We are counting on using RTT for a test fixture for our product and hope you can offer suggestion on what we may look into to make it work.

    Any help is greatly appreciated!

    Thanks,

    Man
  • Hi Man,


    What demo board are you using?

    I am using an Actel eval board from ~2010 with a A2F200M3F device.
    The user guide is for a "SmartFusion Development Kit" / "A2F-DEV-KIT" and on the board itself it says "SFAD Board DVP-102-288-001 Rev B".

    EMC_MUX_CR = 0x00000001
    EMC_CS_0_CR = 0x0020B335 - PSRAM
    EMC_CS_1_CR = 0x0021D3BF - NOR Flash

    Does not work on the board.
    Please understand that I can not spend time on trying to figure out the init sequence of the PSRAM from the manual.


    If I understand correctly there are two separate issues:
    1)
    When placing the RTT buffer in the PSRAM @ 0x70000000, neither auto-detection nor SetRTTSearchRanges works. However, when specifying the RTT address, it works without any issues.

    2)
    When debugging an application based on FreeRTOS, the same code that works on a MK10DX256xxx7 produce a hard fault after some time on the Microsemi A2F200M3.

    Regarding 2)
    Why is the SEGGER_RTT_MAX_INTERRUPT_PRIORITY define different from the version running on the MK10DX256xxx7 ?
    We provide an Application Note (AN00016 Analyzing HardFaults on Cortex-M CPUs). It provides a .c file which can usually included in the project and is ready for use.
    Does this help to isolate the source which is causing the issue?


    Best regards,
    Niklas
    Would you like to be added to the J-Link software update notification list, so you get informed automatically when a new version becomes available?
    Just write me a PM or in case you want to subscribe to it yourself, please use this link: Link
    Notification for J-Link, J-Link Debugger, SystemView & J-Scope: Link
    Notification for Embedded Studio: Link
  • Niklas,
    Thank you for the suggestions.

    If I understand correctly there are two separate issues:

    Yes, there are two problems but first one is easy to overcome by locating RTT buffer in on board RAM.

    Why is the SEGGER_RTT_MAX_INTERRUPT_PRIORITY define different from the version running on the MK10DX256xxx7 ?

    I mis-printed the SEGGER_RTT_MAX_INTERRUPT_PRIORITY for Microsemi A2F200M3. It is the same as MK10DX256xxx7 and doesn't matter
    so much if using FreeRTOS with 1 task and no other hardware interrupt except systimer.

    Second problem cannot be resolved. RTT works fine on Microsemi A2F200M3 on simple program that continuously outputs test data to RTT console.
    Same test code running in FreeRTOS task with no other tasks does not work.

    I used Segger hardfault handler to look further. Hardfault is caused by access (not debug reason that I originally stated). Systick interrupt is always
    active when hardfault occurs. For reasons unknown it is not possible to step out of hardfault handler to determine code location that caused
    hardfault although it appears that it may be in FPGA fabric microcode.

    I conclude that RTT issue is isolated to Microsemi A2F200M3 for reasons that only Microsemi would be able to determine.

    We have found Microsemi A2F200M3 to be frustratingly idiosyncratic, Furthermore Microsemi lacks support that is common among virtually any other
    microprocessor manufacturer.

    Again, Thanks for suggestions.

    Man