New Crowdin translations - uk (#24853)

Co-authored-by: Crowdin Bot <support+bot@crowdin.com>

docs/uk/debug/gdb_debugging.md

@@ -54,6 +54,30 @@ To avoid having to type all commands to connect in GDB each time, you can write
 - [MCU Eclipse/J-Link Debugging for PX4](eclipse_jlink.md).
 - [Visual Studio Code IDE (VSCode)](../dev_setup/vscode.md).
 
+## Відео
+
+The following video provides an overview of the tooling available for advanced debugging of PX4 via GDB.
+It was presented at the PX4 Developer Conference 2023.
+
+<lite-youtube videoid="1c4TqEn3MZ0" title="Debugging PX4 - Niklas Hauser, Auterion AG"/>
+
+**Overview:** The inspection tools built into PX4 via Mavlink Shell (NSH) as well as interpretation of the PX4 uLog after a flight require PX4 to still be functioning. However, the most problematic bugs often manifest themselves in a (partially) hanging or crashed system. Therefore, we present the open-source Embedded Debug Tools project, which manages and configures probe, debugging and analysis tools for PX4 and NuttX:
+
+- Debug interfaces (SWD) and the associated debug probes (J-Link, STLink) and libraries (JLinkGDBServer, OpenOCD).
+- How to install and configure `arm-none-eabi-gdb(-py3)` for debugging your ELF.
+- Commonly used GDB commands and scripts.
+- Advanced GDB scripting via its Python API.
+- Inspection of NuttX RTOS component internals: tasks, semaphores, scheduler.
+- Inspecting peripheral state with CMSIS-SVD files and custom visualizations.
+- Coredumping for post-mortem debugging via CrashDebug.
+- Hardfault analysis in a live system and via the hardfault log.
+- Remote GDB scripting via the Machine Interface.
+- Automated HiL testing of PX4 via combined GDB and NSH scripting.
+- ITM profiling over SWO pin using Orbuculum.
+- Thread/IRQ/Workqueue/Heap visualization and latency analysis using perfetto.
+- High-bandwidth ETM tracing over TRACE pins: J-Trace and ORBtrace mini.
+- We conclude with an overview of interesting related project and an outlook on the future of PX4 debugging.
+
 ## Вбудовані інструменти налагодження
 
 The [Embedded Debug Tools](https://pypi.org/project/emdbg/) connect several software and hardware debugging tools together in a user friendly Python package to more easily enable advanced use cases for ARM Cortex-M microcontrollers and related devices.

docs/uk/debug/gdb_hardfault.md

@@ -10,14 +10,21 @@
 
 <lite-youtube videoid="KZkAM_PVOi0" title="Hardfault debugging on PX4"/>
 
-## Відлагодження важких відмов в NuttX
+---
 
-Типовий сценарій, який може спричинити важку помилку, - це коли процесор перезаписує стек, а потім процесор повертається до недійсної адреси зі стеку.
-Це може бути спричинено помилкою в коді, де дикий вказівник порушує стек, або інша задача перезаписує стек цієї задачі.
+The following video provides an overview of the tooling available for advanced debugging of PX4 via GDB (including hard fault debugging).
+It was presented at the PX4 Developer Conference 2023.
 
-- NuttX підтримує два стеки: стек IRQ для обробки переривань та стек користувача
-- Стек зростає вниз.
-  Таким чином, найвища адреса в наведеному нижче прикладі - 0x20021060, розмір - 0x11f4 (4596 байтів), і, відповідно, найнижча адреса - 0x2001fe6c.
+<lite-youtube videoid="1c4TqEn3MZ0" title="Debugging PX4 - Niklas Hauser, Auterion AG"/>
+
+## Debugging Hard Faults in NuttX
+
+A typical scenario that can cause a hard fault is when the processor overwrites the stack and then the processor returns to an invalid address from the stack.
+This may be caused by a bug in code were a wild pointer corrupts the stack, or another task overwrites this task's stack.
+
+- NuttX maintains two stacks: The IRQ stack for interrupt processing and the user stack
+- The stack grows downward.
+  So the highest address in the example below is 0x20021060, the size is 0x11f4 (4596 bytes) and consequently the lowest address is 0x2001fe6c.
 
 ```sh
 Assertion failed at file:armv7-m/up_hardfault.c line: 184 task: ekf_att_pos_estimator
@@ -73,7 +80,7 @@ arm-none-eabi-gdb build/px4_fmu-v2_default/px4_fmu-v2_default.elf
 ```
 
 Then in the GDB prompt, start with the last instructions in R8, with the first address in flash (recognizable because it starts with `0x080`, the first is `0x0808439f`).
-Виконання здійснюється зліва направо. So one of the last steps before the hard fault was when `mavlink_log.c` tried to publish something,
+The execution is left to right. So one of the last steps before the hard fault was when `mavlink_log.c` tried to publish something,
 
 ```sh
 (gdb) info line *0x0808439f