fix: update detected broken links

Author: f-hollow

content/blog/2020/12/blink-led-on-esp32-with-rtos-nuttx/index.md

@@ -8,7 +8,7 @@ authors:
 tags:
   - Nuttx
   - Esp32
-summary: "This is a tutorial on how to blink an LED with NuttX after getting started." 
+summary: "This is a tutorial on how to blink an LED with NuttX after getting started."
 ---
 \
 {{< alert >}}
@@ -19,7 +19,7 @@ summary: "This is a tutorial on how to blink an LED with NuttX after getting sta
 
 This article is part of the “First Steps with ESP32 and NuttX” series. A series whose objective is to present an overview of the NuttX Operating System and to provide instructions for using NuttX on ESP32.
 
-The [first part](/blog/2020/11/getting-started-with-esp32-and-nuttx) of the series showed how to prepare the environment, compile and build the Operating System (NuttX) until uploading the firmware to the SoC (ESP32).
+The [first part](/blog/2020/11/nuttx-getting-started) of the series showed how to prepare the environment, compile and build the Operating System (NuttX) until uploading the firmware to the SoC (ESP32).
 
 This is the second part and will demonstrate how to run the famous “Hello World” from the Embedded Systems world, i.e., an application that blinks a LED. The evaluation board used here is a DevKit v1 and the built-in LED will be used for convenience. If your DevKit does not come with a built-in LED, just connect an LED to pin 2 in series with a resistor as it will be briefly discussed in the execution section.
 
@@ -54,7 +54,7 @@ Exit the menu via “Exit” and save the configuration.
 
 ## Building and Flashing
 
-If you did not add the paths for the cross compiler binaries and for the esptool to PATH permanently as suggested in the [Getting Started](/blog/2020/11/getting-started-with-esp32-and-nuttx), run the following commands to load these paths.
+If you did not add the paths for the cross compiler binaries and for the esptool to PATH permanently as suggested in the [Getting Started](/blog/2020/11/nuttx-getting-started), run the following commands to load these paths.
 
 ```
 export PATH=$PATH:/opt/xtensa/xtensa-esp32-elf/bin
@@ -70,7 +70,7 @@ make clean
 make download ESPTOOL_PORT=/dev/ttyUSB0
 ```
 
-NOTE: adjust the USB port according to your configuration. In case this is the first time you are downloading the binaries to ESP32, pass the bootloader and the partition table directory as an argument in the second comand as instructed in the [previous article](/blog/getting-started-with-esp32-and-nuttx) from this series.
+NOTE: adjust the USB port according to your configuration. In case this is the first time you are downloading the binaries to ESP32, pass the bootloader and the partition table directory as an argument in the second comand as instructed in the [previous article](/blog/2020/11/nuttx-getting-started) from this series.
 
 ## Example Execution
 
@@ -135,4 +135,4 @@ For help, doubts, bugs reports, and discussion regarding NuttX, you can send an
 
 ---
 
-The [original article](https://medium.com/the-esp-journal/blink-led-on-esp32-with-rtos-nuttx-d33c7dc62156) was published on Medium, on the [ESP Journal](https://medium.com/the-esp-journal). It has since been updated.
+The [original article](https://medium.com/the-esp-journal/blink-led-on-esp32-with-rtos-nuttx-d33c7dc62156) was published on Medium, on the [ESP Journal](https://medium.com/the-esp-journal). It has since been updated.

content/blog/2025/03/nuttx-python-esp32s3/index.md

@@ -39,7 +39,7 @@ Check the [ESP Product Selector](https://products.espressif.com/) to find suitab
 
 ### Software Requirements
 
-For those new to NuttX, we recommend reviewing the guide [Getting Started with NuttX and ESP32](../../../nuttx-getting-started) to configure your development environment for building NuttX applications.
+For those new to NuttX, we recommend reviewing the guide [Getting Started with NuttX and ESP32](/blog/2020/11/nuttx-getting-started) to configure your development environment for building NuttX applications.
 
 ### Compiling and Flashing
 

content/blog/2025/10/oop_with_c/index.md

@@ -67,7 +67,7 @@ An *opaque pointer* is a pointer to a type whose contents are hidden from the us
 {{< /alert >}}
 
 #### Error Handling
-Before looking deeper at how methods are structured in C, it’s important to touch on __error handling__. While not strictly part of object-oriented programming, it directly affects the design of function signatures in OOP-style APIs: many “methods” return status codes instead of the actual result, leaving the caller to check and handle errors explicitly. This convention is widely used in ESP-IDF and is key to understanding how its APIs are meant to be used. For a deeper dive, see the article [ESP-IDF tutorial series: Errors](../errors_and_logging/).
+Before looking deeper at how methods are structured in C, it’s important to touch on __error handling__. While not strictly part of object-oriented programming, it directly affects the design of function signatures in OOP-style APIs: many “methods” return status codes instead of the actual result, leaving the caller to check and handle errors explicitly. This convention is widely used in ESP-IDF and is key to understanding how its APIs are meant to be used. For a deeper dive, see the article [ESP-IDF tutorial series: Errors](/blog/2025/09/espressif_logging/).
 
 #### Implementation example
 

content/blog/securely-booting-user-application-in-esp-privilege-separation/index.md

@@ -12,7 +12,7 @@ tags:
   - Security
 
 ---
-In the [previous post](/blog/ota-firmware-updates-with-esp-privilege-separation-3b676b49459), we demonstrated the ability to independently update the user application in the ESP Privilege Separation framework. With the separation and isolation of the protected app and user app, it becomes convenient to decouple the ownership of each of these apps and their updates. This also potentially allows the possibility of having multiple user applications for a single protected application, somewhat like an “application store” for user app. As the functionality of these applications increases, the security of these apps becomes mandatory.
+In the [previous post](/blog/ota-firmware-updates-with-esp-privilege-separation), we demonstrated the ability to independently update the user application in the ESP Privilege Separation framework. With the separation and isolation of the protected app and user app, it becomes convenient to decouple the ownership of each of these apps and their updates. This also potentially allows the possibility of having multiple user applications for a single protected application, somewhat like an “application store” for user app. As the functionality of these applications increases, the security of these apps becomes mandatory.
 
 In this post, we will describe the secure boot mechanism implemented for the user application. This mechanism ensures that only the trusted and authorized user application can execute on the device.
 
@@ -51,9 +51,9 @@ In this scheme, the protected application is considered trusted and thus the pro
 
 Let’s look at the requisites for protected app and user app for this scheme
 
-__Protected app:__ 
+__Protected app:__
 
-__User app:__ 
+__User app:__
 
 ## Verification process