A simple example of working with GDB is shown here. The debugging process itself is too complex to learn it step-by-step, it requires existing knowledge and experience in software development.

To become more familiar with GDB you can search for other guides on the web, for example Debugging with GDB. 

For the debugger to work correctly, the firmware on the device should match the firmware files on your computer. To accomplish that you may need to flash the Flipper Zero. You can learn more on how to compile or acquire the needed firmware files on the First start page.

To upload the firmware to the Flipper Zero, run the load command:

Run the compare-sections command to verify that the data was written correctly.

If the sector data doesn't match, the MIS-MATCHED! message will appear. In that case, you'll need to re-upload the firmware to your device by following the steps above.

After finishing the upload, the firmware execution will be paused at the very beginning. The display will be blank and the LED won't be lit up. To run the execution of your program and for the device to boot, run the continue command, or just c.

Let's look at how one would debug an app on the device, for example, the Music Player app. It is located in the Plugins → Music Player menu.

We'll start by halting the app at the very beginning of the execution. To do this, you'll need to place a breakpoint, which will stop the code execution once reached, and will allow you to observe the code state and inner workings. After that, you'll launch the Music Player through the device menu.

Run the list command to find the line number at which the music_player_app function is defined. The command will show the 5 lines before and after the function definition:

The function is located at line 293, let's set a breakpoint by running the break 293 command:

Now continue the program execution with the c command

Now, pick up your Flipper Zero, open the app menu, and navigate to Plugins → Music Player. The breakpoint will trigger. The program will automatically halt, and the device will stop responding to any input.

You can run the code line-by-line with the next (n) command, and see the order in which the code is run:

You can use the info locals command to look at the local variables' state to see the changes happening in the device's memory:

To finish working with GDB, run the quit command:

continue, c — continues the code execution

next, n — executes the next line of the program

backtrace,bt — shows the functions that have lead to the current state

info threads — shows the threads that are currently running

info locals — shows the local variables

stop — halts the firmware execution

info breakpoints — shows all set breakpoints