{"id":3178,"date":"2017-09-07T11:47:18","date_gmt":"2017-09-07T18:47:18","guid":{"rendered":"https:\/\/visualgdb.com\/w\/?p=3178"},"modified":"2020-06-26T10:08:09","modified_gmt":"2020-06-26T17:08:09","slug":"attaching-to-embedded-code-to-diagnose-delayed-problems","status":"publish","type":"post","link":"https:\/\/visualgdb.com\/tutorials\/arm\/attach\/","title":{"rendered":"Attaching to Embedded Code to Diagnose Delayed Problems"},"content":{"rendered":"

This tutorial shows how to use the “Attach to Running Embedded Firmware” feature of VisualGDB to diagnose rarely occurring problems in your code that don’t get easily triggered. We will create a simple program causing the “division by zero” error with a 1\/1000 chance, run it without debugger and one the problem happens, will attach VisualGDB and show how to diagnose it.<\/p>\n

Before you begin, install VisualGDB 5.3 or later.<\/p>\n

    \n
  1. Start Visual Studio and open VisualGDB Embedded Project Wizard:\"01-prjname\"<\/a><\/li>\n
  2. Proceed with the default selection on the first page:\"02-newmsb\"<\/a><\/li>\n
  3. Select your toolchain and the device. In this tutorial we will use the Nucleo-F410RB board featuring the STM32F410RB device:\"03-device\"<\/a><\/li>\n
  4. We will use the UART_Printf example from ST SDK as a starting point for our demonstration. Select “Show STM32CubeMX Samples” and find the UART_Printf example for your board. VisualGDB will automatically filter the examples based on the selected MCU type:\"03a-printf\"<\/a><\/li>\n
  5. Connect your board via USB and VisualGDB will automatically recognize it and select the best debug method:\u00a0 \"04-debug\"<\/a><\/li>\n
  6. Press “Finish” to create the project. Now we will modify the sample program to trigger the error. First, disable the UART parity bit:\n
    \u00a0\u00a0\u00a0 UartHandle.Init.Parity\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 = UART_PARITY_NONE;<\/pre>\n
    Then replace the main loop in main() with this:<\/p>\n
      \u00a0 SCB->CCR |= SCB_CCR_DIV_0_TRP_Msk;\r\n\u00a0\u00a0\u00a0 for (int i = 0;;i++)\r\n\u00a0\u00a0\u00a0 {\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 int value = rand();\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 int divided = INT32_MAX \/ (value % 1000);\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 printf(\"%d => %d\\r\\n\", i, divided);\r\n\u00a0\u00a0\u00a0 }<\/pre>\n
    Finally add an implementation of _write() that will direct printf() output to HAL_UART_Transmit():<\/p>\n
    int _write(int fd, char *pBuffer, int size)\r\n{\r\n\u00a0\u00a0\u00a0 HAL_UART_Transmit(&UartHandle, (uint8_t *)pBuffer, size, 0xFFFF); \r\n\u00a0\u00a0\u00a0 return size;\r\n}<\/pre>\n
    Note that if it is defined in a C++ file (not Plain C), it would need to be declared with extern “C” so that the linker can use it to replace the default implementation.
    \nFinally build the project:    \"05-build\"<\/a><\/li>\n
  7. Connect a terminal program (e.g. SmarTTY<\/a>) to the ST-Link COM port and select Debug->Program and Start Without Debugging in Visual Studio:\"06-program\"<\/a><\/li>\n
  8. Look in the terminal. It will show several lines of output and will eventually hang:\"07-crash\"<\/a>You can try unplugging\/re-plugging the board to the USB or resetting the microcontroller to ensure the problem is always reproduced. As long as the MCU is running the same build of the firmware that the project contains, the steps described below will work.<\/li>\n
  9. Now we will attach to the hanging microcontroller and diagnose its state. Select Debug->Attach to Running Embedded Firmware:\"08-attach\"<\/a><\/li>\n
  10. VisualGDB will attach to it and show that it’s stuck in HardFault_Handler():\"09-fault\"<\/a>The “Attach to Running Embedded Firmware” command is supported for ARM, ESP8266 and ESP32 devices and it automatically suppresses FLASH reprogramming and device resetting so that you can see the exact state of the processor the moment you attached to it.<\/li>\n
  11. Hard fault could be triggered by several different causes, so you can use the CFSR register in Hardware Registers to see what exactly caused it. In this example the DIVBYZERO field indicates that the error was triggered by attempting to divide by zero:\"10-divbyzero\"<\/a>Note that normally it would not cause an exception. We had to explicitly enable the exception in the code by setting DIV_0_TRP <\/strong>in SCB_CCR<\/strong>.<\/li>\n
  12. Click in the “main()” entry in Call Stack to go to the location of the error. Hover the mouse over ‘value’ to see the value that triggered the error:\"11-value\"<\/a><\/li>\n
  13. Press Shift-F5 to stop debugging and rewrite the code to fix the problem:\n
    \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 int value = rand();\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 int divisor = value % 1000;\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 if (!divisor)\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 continue;\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 int divided = INT32_MAX \/ divisor;<\/pre>\n
    Build the program again, but don’t program it:\"12-fix\"<\/a><\/li>\n
  14. Attach to the running firmware again without reprogramming it. See how now VisualGDB displays that the program is stopped in NMI_Handler() that should normally just immediately return:\"13-nmi\"<\/a>This happens because the debugger is using the new build of the program to interpret the contents of the device memory that has the old build. As we have added extra checking code in main(), its size got increased and several other functions got shifted, so the old address of HardFault_Handler() matches the new address of NMI_Handler().<\/li>\n
  15. VisualGDB provides a convenient way to diagnose this type of errors. Click “Verify FLASH memory contents”:\"14-verify\"<\/a><\/li>\n
  16. VisualGDB will read the FLASH memory on the device, compare it with the current build and will display a detailed list of differences if there are any:\"15-diffs\"<\/a>The pattern of differences could explain the reason behind the mismatch. E.g. having the FLASH memory filled with 0xFFs would mean that the memory was erased, but not programmed; having zero bits in place of one bits (as if contents of the FLASH was bitwise ANDed with something else) would indicate that FLASH erase was not performed; multiple random differences all across the code typically mean that a wrong version was programmed.<\/li>\n
  17. Simply re-program the new firmware to the device to ensure the FLASH memory is updated and it will run without any exceptions:\"16-run\"<\/a><\/li>\n
  18. Starting from VisualGDB 5.5, you can distinguish between starting a new embedded debug session and attaching to running firmware via the $(DebugMode)<\/strong> variable. VisualGDB will set it to “Attach” when attaching and to “NewInstance” otherwise. You can use it to run different sets of startup commands, depending on the way the debug session is started. E.g. you can add the following line to VisualGDB Project Properties -> Additional GDB Commands:\n
    source $(ProjectDir.forwardslashes)\/Startup-$(DebugMode).gdb<\/pre>\n
    It will run commands from Startup-NewInstance.gdb<\/strong> file when starting a regular debug session, and commands from Startup-Attach.gdb<\/strong> otherwise.<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"
    This tutorial shows how to use the “Attach to Running Embedded Firmware” feature of VisualGDB to diagnose rarely occurring problems<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[27],"tags":[53],"_links":{"self":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts\/3178"}],"collection":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/comments?post=3178"}],"version-history":[{"count":4,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts\/3178\/revisions"}],"predecessor-version":[{"id":6383,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts\/3178\/revisions\/6383"}],"wp:attachment":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/media?parent=3178"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/categories?post=3178"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/tags?post=3178"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}