diff --git a/docs/documentation.md b/docs/documentation.md
index 3555095..ca49575 100644
--- a/docs/documentation.md
+++ b/docs/documentation.md
@@ -124,11 +124,11 @@
 
 - `scripts`: Build and source generation scripts.
 
-- `scripts/cmake/platforms`: Platform build configuration scripts `build_configuration.cmake` are located here. 
+- `scripts/cmake/platforms`: Platform build configuration scripts `build_configuration.cmake` are located here.
    These scripts are adding platform sources into the application build stream. The script has 2 functions:
-   * `set_platform_global_defaults` - to set platform source locations and other build options.
-   * `platform_custom_post_build` - to execute specific post build steps. For example, MPS3 board related script adds
-                                    board specific `images.txt` file creation and calls bin generation command. 
+  - `set_platform_global_defaults` - to set platform source locations and other build options.
+  - `platform_custom_post_build` - to execute specific post build steps. For example, MPS3 board related script adds
+                                    board specific `images.txt` file creation and calls bin generation command.
                                     Native profile related script compiles unit-tests.
 
 - `source`: C/C++ sources for the platform and ML applications.
@@ -143,18 +143,18 @@
 
     - `tensorflow-lite-micro`: Contains abstraction around TensorFlow Lite Micro API. This abstraction implements common
       functions to initialize a neural network model, run an inference, and access inference results.
-  
+
   - `hal`: Contains Hardware Abstraction Layer (HAL) sources, providing a platform agnostic API to access hardware
     platform-specific functions.
 
   - `log`: Common to all code logging macros managing log levels.
-  
+
   - `math`: Math functions to be used in ML pipelines. Some of them use CMSIS DSP for optimized execution on Arm CPUs.
-     It is a separate CMake project that is built into a static library `libarm_math.a`.         
-  
+     It is a separate CMake project that is built into a static library `libarm_math.a`.
+
   - `profiler`: profiling utilities code to collect and output cycle counts and PMU information.
     It is a separate CMake project that is built into a static library `libprofiler.a`.
-        
+
   - `use_case`: Contains the ML use-case specific logic. Stored as a separate subfolder, it helps isolate the
     ML-specific application logic. With the assumption that the `application` performs the required setup for logic to
     run. It also makes it easier to add a new use-case block.
@@ -185,6 +185,7 @@
 ├── CMakeLists.txt
 └── hal.c
 ```
+
 HAL is built as a separate project into a static library `libhal.a`. It is linked with use-case executable.
 
 What these folders contain:
@@ -200,24 +201,24 @@
   It is a separate CMake project that is built into a static library `libcmsis_device.a`. It depends on a CMSIS repo
   through `CMSIS_SRC_PATH` variable.
   The static library is used by platform code.
-   
+
 - `components` directory contains drivers code for different devices used in platforms. Such as UART, LCD and others.
   A platform can include those as sources in a build to enable usage of corresponding HW devices. Most of the use-cases
-  use UART and LCD, thus if you want to run default ML use-cases on a custom platform, you will have to add 
+  use UART and LCD, thus if you want to run default ML use-cases on a custom platform, you will have to add
   implementation for your devices here (or re-use existing code if it is compatible with your platform).
 
 - `platform/mps3`\
   `platform/simple`:
-  These folders contain platform specific declaration and defines, such as, platform initialisation code, peripheral 
-  memory map, system registers, system specific timer implementation and other. 
+  These folders contain platform specific declaration and defines, such as, platform initialisation code, peripheral
+  memory map, system registers, system specific timer implementation and other.
   Platform is built from selected components and configured cmsis device. The platform could be used with different
   profiles. Profile is included into the platform build based on `PLATFORM_PROFILE` build parameter.
-  Platform code is a separate CMake project and it is built into a static library `libplatform-drivers.a`. It is linked 
+  Platform code is a separate CMake project and it is built into a static library `libplatform-drivers.a`. It is linked
   into HAL library.
 
 - `profiles/bare-metal`\
   `profiles/native`:
-  As mentioned before, profiles are added into platform build. Currently we support bare-metal and native profiles.    
+  As mentioned before, profiles are added into platform build. Currently we support bare-metal and native profiles.
   bare-metal contains the HAL support layer and platform initialization helpers. Function calls are routed
   to platform-specific logic at this level. For example, for data presentation, an `lcd` module has been used. This
   `lcd` module wraps the LCD driver calls for the actual hardware (for example, MPS3). Also "re-targets" the standard
@@ -255,7 +256,7 @@
 
 ## Building
 
-This section explains the build process and intra-project dependencies, describes how to build the code sample 
+This section explains the build process and intra-project dependencies, describes how to build the code sample
 applications from sources and includes illustrating the build options and the process.
 
 The following graph of source modules aims to explain better intra-project code and build execution dependencies.
@@ -278,7 +279,6 @@
       - [Using GNU Arm embedded toolchain](./sections/building.md#using-gnu-arm-embedded-toolchain)
       - [Using Arm Compiler](./sections/building.md#using-arm-compiler)
       - [Generating project for Arm Development Studio](./sections/building.md#generating-project-for-arm-development-studio)
-      - [Working with model debugger from Arm Fast Model Tools](./sections/building.md#working-with-model-debugger-from-arm-fast-model-tools)
       - [Configuring with custom TPIP dependencies](./sections/building.md#configuring-with-custom-tpip-dependencies)
     - [Configuring native unit-test build](./sections/building.md#configuring-native-unit_test-build)
     - [Configuring the build for simple-platform](./sections/building.md#configuring-the-build-for-simple_platform)
diff --git a/docs/sections/arm_virtual_hardware.md b/docs/sections/arm_virtual_hardware.md
index cb5ed48..a14f020 100644
--- a/docs/sections/arm_virtual_hardware.md
+++ b/docs/sections/arm_virtual_hardware.md
@@ -1,14 +1,16 @@
+# Arm Virtual Hardware
+
 - [Overview](./arm_virtual_hardware.md#overview)
   - [Getting started](./arm_virtual_hardware.md#getting-started)
 
-# Overview
+## Overview
 
 Arm® Virtual Hardware is an accurate representation of a physical System on Chip and runs as a simple application in a Linux environment for easy
 scalability in the cloud and removes dependency from silicon availability. Powered by Amazon Web Services (AWS), developers can launch Amazon Machine Image
 (AMI) running as a virtual server in the cloud. The Arm Virtual Hardware is configured with the Corstone™-300 MPS3 based Fixed Virtual Platform (FVP),
 compiler and other tools.
 
-## Getting started
+### Getting started
 
 To take advantage of Arm Virtual Hardware, you would need to have an AWS account and follow the steps below:
 
diff --git a/docs/sections/building.md b/docs/sections/building.md
index 5fdadb0..306dc69 100644
--- a/docs/sections/building.md
+++ b/docs/sections/building.md
@@ -14,7 +14,6 @@
       - [Using GNU Arm Embedded toolchain](./building.md#using-gnu-arm-embedded-toolchain)
       - [Using Arm Compiler](./building.md#using-arm-compiler)
       - [Generating project for Arm Development Studio](./building.md#generating-project-for-arm-development-studio)
-      - [Working with model debugger from Arm Fast Model Tools](./building.md#working-with-model-debugger-from-arm-fast-model-tools)
       - [Configuring with custom TPIP dependencies](./building.md#configuring-with-custom-tpip-dependencies)
     - [Configuring native unit-test build](./building.md#configuring-native-unit_test-build)
     - [Configuring the build for simple-platform](./building.md#configuring-the-build-for-simple_platform)
diff --git a/docs/sections/customizing.md b/docs/sections/customizing.md
index 17b8040..ef90e5e 100644
--- a/docs/sections/customizing.md
+++ b/docs/sections/customizing.md
@@ -733,16 +733,19 @@
 
 ## Adding custom platform support
 
-Platform build configuration script `build_configuration.cmake` is the main build entry point for platform sources. 
+Platform build configuration script `build_configuration.cmake` is the main build entry point for platform sources.
 It is used by top level CMakeLists.txt script to add a platform into the public build stream.
 Platform build configuration script must have 2 functions:
- * `set_platform_global_defaults` - to set platform source locations and other build options.
- * `platform_custom_post_build` - to execute specific post build steps.
- 
+
+- `set_platform_global_defaults` - to set platform source locations and other build options.
+- `platform_custom_post_build` - to execute specific post build steps.
+
 The function `set_platform_global_defaults` must set `PLATFORM_DRIVERS_DIR` variable
-```
+
+```cmake
     set(PLATFORM_DRIVERS_DIR "${HAL_PLATFORM_DIR}/mps3" PARENT_SCOPE)
 ```
+
 location of the platform library sources.
 
 > **Convention:**  The default search path for platform build configuration scripts is in `scripts/cmake/platforms`.
@@ -750,49 +753,55 @@
 > build option. For example:
 > `scripts/cmake/platforms/my_platform` results in having `my_platform` as a `TARGET_PLATFORM` option for the build.
 
-The function `platform_custom_post_build` could be used to add platform specific post use-case application build steps. 
+The function `platform_custom_post_build` could be used to add platform specific post use-case application build steps.
 
-Repository's root level CMakeLists.txt calls common utility function `add_platform_build_configuration(TARGET_PLATFORM ${TARGET_PLATFORM})` 
-to add given target platform to the build stream. The function finds the script and includes 
-`build_configuration.cmake` file. After that public build can invoke
-* `set_platform_global_defaults`
-* `platform_custom_post_build`
+Repository's root level CMakeLists.txt calls common utility function `add_platform_build_configuration(TARGET_PLATFORM ${TARGET_PLATFORM})`
+to add given target platform to the build stream. The function finds the script and includes
+`build_configuration.cmake` file. After that public build can invoke:
+
+- `set_platform_global_defaults`
+- `platform_custom_post_build`
+
 for a specified platform.
 
-New platform sources, that are pointed to by `PLATFORM_DRIVERS_DIR` variable, could be placed anywhere, conventional location 
+New platform sources, that are pointed to by `PLATFORM_DRIVERS_DIR` variable, could be placed anywhere, conventional location
 is `source/hal/platform`. Platform must be a separate CMake project with CMakeLists.txt script and build into a static
 library `libplatform-drivers.a`.
 HAL expects platform to have `platfrom_drivers.h`  header file with required interfaces for included peripherals.
 
 If the new platform uses existing cmsis device project then it should be linked with it like this:
-```
+
+```cmake
     target_link_libraries(${PLATFORM_DRIVERS_TARGET} PUBLIC cmsis_device)
 ```
+
 Cmsis device exposes an entry point `--entry Reset_Handler` as a link interface.
 
 If the new platform defines custom cmsis device and has custom application entry point,
 it must tell linker about it like this:
-```
+
+```cmake
     target_link_options(${PLATFORM_DRIVERS_TARGET} INTERFACE --entry <custom handler name>)
 ```
 
 Most of the ML use-case applications use UART and LCD, thus it is a hard requirement to implement at least stubs for
-those. UART driver must implement functions from `uart_stdout.h` header. LCD driver must provide implementation for 
+those. UART driver must implement functions from `uart_stdout.h` header. LCD driver must provide implementation for
 functions declared in `glcd_mps3.h` header. For stubs examples, please, see simple platform sources.
 
-If the new platform does not use UART, it is possible to run application with semi-hosting enabled - printf 
-statements will be shown in the host machine console. Please, comment out all content of the 
+If the new platform does not use UART, it is possible to run application with semi-hosting enabled - printf
+statements will be shown in the host machine console. Please, comment out all content of the
 `source/hal/profiles/bare-metal/bsp/retarget.c` file in this case.
 
 Examples of the UART and LCD drivers implementation could be found here: `source/hal/components`.
 
-Linker scripts for armclang and GCC should be added. The location of the files is on your discretion. The new 
+Linker scripts for armclang and GCC should be added. The location of the files is on your discretion. The new
 platform build configuration script must add it in the `platform_custom_post_build` function like this:
-```
+
+```cmake
     add_linker_script(
             ${PARSED_TARGET_NAME}                  # Target
             ${CMAKE_SCRIPTS_DIR}/platforms/mps3    # linker scripts directory path
             ${LINKER_SCRIPT_NAME})                 # Name of the file without suffix
 ```
 
-Please see existing platforms sources and build scripts for more details. 
\ No newline at end of file
+Please see existing platforms sources and build scripts for more details.
diff --git a/docs/sections/faq.md b/docs/sections/faq.md
index 5578ead..0ffd0bd 100644
--- a/docs/sections/faq.md
+++ b/docs/sections/faq.md
@@ -55,4 +55,4 @@
 function in *source/use_case/img_class/src/MobileNetModel.cc* to enlist any new operators in the model.
 
 Don't forget to also increment the **ms_maxOpCnt** variable in the corresponding header file
-(e.g. *source/use_case/img_class/include/MobileNetModel.hpp* if we are changing **img_class**).
\ No newline at end of file
+(e.g. *source/use_case/img_class/include/MobileNetModel.hpp* if we are changing **img_class**).
diff --git a/docs/sections/memory_considerations.md b/docs/sections/memory_considerations.md
index 3472f2f..b67bbc5 100644
--- a/docs/sections/memory_considerations.md
+++ b/docs/sections/memory_considerations.md
@@ -40,20 +40,21 @@
 
 See the example for Arm® *Corstone™-300* description file [corstone-sse-300.cmake](../../scripts/cmake/subsystem-profiles/corstone-sse-300.cmake). For the discussion on this page, it is useful to note the following definitions:
 
-```
+```cmake
 set(ISRAM0_SIZE           "0x00100000" CACHE STRING "ISRAM0 size:       1 MiB")
 set(ISRAM1_SIZE           "0x00100000" CACHE STRING "ISRAM1 size:       1 MiB")
 ...
 # SRAM size reserved for activation buffers
 math(EXPR ACTIVATION_BUF_SRAM_SZ "${ISRAM0_SIZE} + ${ISRAM1_SIZE}" OUTPUT_FORMAT HEXADECIMAL)
 ```
+
 This will set `ACTIVATION_BUF_SRAM_SZ` to be **2 MiB** for Arm® *Corstone™-300* target platform.
 As mentioned in the comments within the file, this size is directly linked to the size mentioned
 in the linker scripts, and therefore, it should not be changed without corresponding changes
 in the linker script too. For example, a snippet from the scatter file for Arm® *Corstone™-300*
 shows:
 
-```
+```log
 ;-----------------------------------------------------
 ; FPGA internal SRAM of 2MiB - reserved for activation
 ; buffers.
@@ -65,6 +66,7 @@
     ...
 }
 ```
+
 If the usable size of the internal SRAM was to be increased/decreased, the change should be
 made in both the linker script as well as the `corstone-300.cmake` definition.
 
@@ -76,10 +78,12 @@
 
 - The file [set_up_default_resources.py](../../set_up_default_resources.py) contains a
   parameter called `mps3_max_sram_sz`:
-  ```
+
+  ```python
   # The internal SRAM size for Corstone-300 implementation on MPS3 specified by AN552
   mps3_max_sram_sz = 2 * 1024 * 1024 # 2 MiB (2 banks of 1 MiB each)
   ```
+
   This size of **2 MiB** here is provided here to allow the default vela optimisation process to
   use this size as a hint for the available SRAM size for use by the CPU and the NPU.
 
@@ -162,6 +166,7 @@
 
 Info: Changing const_mem_area from Sram to OnChipFlash. This will use the same characteristics as Sram.
 ```
+
 This means that the  neural network model is always placed in the flash region. In this case, timing adapters for the
 AXI buses are set the same values to mimic both bandwidth and latency characteristics of a SRAM memory device.
 See [Ethos-U55 NPU timing adapter default configuration](../../scripts/cmake/timing_adapter/ta_config_u55_high_end.cmake).
diff --git a/docs/use_cases/ad.md b/docs/use_cases/ad.md
index 553e3b8..6ab085e 100644
--- a/docs/use_cases/ad.md
+++ b/docs/use_cases/ad.md
@@ -133,7 +133,6 @@
 - [Configuring with custom TPIP dependencies](../sections/building.md#configuring-with-custom-tpip-dependencies)
 - [Using Arm Compiler](../sections/building.md#using-arm-compiler)
 - [Configuring the build for simple-platform](../sections/building.md#configuring-the-build-for-simple_platform)
-- [Working with model debugger from Arm Fast Model Tools](../sections/building.md#working-with-model-debugger-from-arm-fast-model-tools)
 - [Building for different Ethos-U NPU variants](../sections/building.md#building-for-different-ethos_u-npu-variants)
 
 > **Note:** If re-building with changed parameters values, we recommend that you clean the build directory and then
diff --git a/docs/use_cases/asr.md b/docs/use_cases/asr.md
index bbcde92..46ef584 100644
--- a/docs/use_cases/asr.md
+++ b/docs/use_cases/asr.md
@@ -180,7 +180,6 @@
 - [Configuring with custom TPIP dependencies](../sections/building.md#configuring-with-custom-tpip-dependencies)
 - [Using Arm Compiler](../sections/building.md#using-arm-compiler)
 - [Configuring the build for simple-platform](../sections/building.md#configuring-the-build-for-simple_platform)
-- [Working with model debugger from Arm Fast Model Tools](../sections/building.md#working-with-model-debugger-from-arm-fast-model-tools)
 - [Building for different Ethos-U NPU variants](../sections/building.md#building-for-different-ethos_u-npu-variants)
 
 > **Note:** If re-building with changed parameters values, we recommend that you clean the build directory and re-run
diff --git a/docs/use_cases/img_class.md b/docs/use_cases/img_class.md
index e2df09d..494ec61 100644
--- a/docs/use_cases/img_class.md
+++ b/docs/use_cases/img_class.md
@@ -99,7 +99,6 @@
 - [Configuring with custom TPIP dependencies](../sections/building.md#configuring-with-custom-tpip-dependencies)
 - [Using Arm Compiler](../sections/building.md#using-arm-compiler)
 - [Configuring the build for simple-platform](../sections/building.md#configuring-the-build-for-simple_platform)
-- [Working with model debugger from Arm Fast Model Tools](../sections/building.md#working-with-model-debugger-from-arm-fast-model-tools)
 - [Building for different Ethos-U NPU variants](../sections/building.md#building-for-different-ethos_u-npu-variants)
 
 > **Note:** If re-building with changed parameters values, we recommend that you clean the build directory and re-run
diff --git a/docs/use_cases/inference_runner.md b/docs/use_cases/inference_runner.md
index d6e2681..0aa671a 100644
--- a/docs/use_cases/inference_runner.md
+++ b/docs/use_cases/inference_runner.md
@@ -95,7 +95,6 @@
 - [Configuring with custom TPIP dependencies](../sections/building.md#configuring-with-custom-tpip-dependencies)
 - [Using Arm Compiler](../sections/building.md#using-arm-compiler)
 - [Configuring the build for simple-platform](../sections/building.md#configuring-the-build-for-simple_platform)
-- [Working with model debugger from Arm Fast Model Tools](../sections/building.md#working-with-model-debugger-from-arm-fast-model-tools)
 - [Building for different Ethos-U NPU variants](../sections/building.md#building-for-different-ethos_u-npu-variants)
 
 > **Note:** If re-building with changed parameters values, we recommend that you clean the build directory and re-run
diff --git a/docs/use_cases/kws.md b/docs/use_cases/kws.md
index 0c50fe5..d07dff2 100644
--- a/docs/use_cases/kws.md
+++ b/docs/use_cases/kws.md
@@ -148,7 +148,6 @@
 - [Configuring with custom TPIP dependencies](../sections/building.md#configuring-with-custom-tpip-dependencies)
 - [Using Arm Compiler](../sections/building.md#using-arm-compiler)
 - [Configuring the build for simple-platform](../sections/building.md#configuring-the-build-for-simple_platform)
-- [Working with model debugger from Arm Fast Model Tools](../sections/building.md#working-with-model-debugger-from-arm-fast-model-tools)
 - [Building for different Ethos-U NPU variants](../sections/building.md#building-for-different-ethos_u-npu-variants)
 
 > **Note:** If re-building with changed parameters values, we recommend that you clean the build directory and re-run
diff --git a/docs/use_cases/kws_asr.md b/docs/use_cases/kws_asr.md
index 22f1e9d..8013634 100644
--- a/docs/use_cases/kws_asr.md
+++ b/docs/use_cases/kws_asr.md
@@ -241,7 +241,6 @@
 - [Configuring with custom TPIP dependencies](../sections/building.md#configuring-with-custom-tpip-dependencies)
 - [Using Arm Compiler](../sections/building.md#using-arm-compiler)
 - [Configuring the build for simple-platform](../sections/building.md#configuring-the-build-for-simple_platform)
-- [Working with model debugger from Arm Fast Model Tools](../sections/building.md#working-with-model-debugger-from-arm-fast-model-tools)
 - [Building for different Ethos-U NPU variants](../sections/building.md#building-for-different-ethos_u-npu-variants)
 
 > **Note:** If re-building with changed parameters values, we recommend that you clean the build directory and re-run
@@ -478,7 +477,7 @@
     INFO - Activation buffer (a.k.a tensor arena) size used: 127068
     INFO - Number of operators: 1
     INFO -  Operator 0: ethos-u
-   
+
     INFO - Model INPUT tensors:
     INFO -  tensor type is INT8
     INFO -  tensor occupies 11544 bytes with dimensions
@@ -574,5 +573,3 @@
 
 - For FPGA platforms, a CPU cycle count can also be enabled. However, do not use cycle counters for FVP, as the CPU
   model is not cycle-approximate or cycle-accurate.
-
-
diff --git a/docs/use_cases/noise_reduction.md b/docs/use_cases/noise_reduction.md
index cd89091..b015492 100644
--- a/docs/use_cases/noise_reduction.md
+++ b/docs/use_cases/noise_reduction.md
@@ -59,7 +59,7 @@
 These output gain values can then be applied to each corresponding window of the noisy audio clip,
 producing a cleaner output.
 
-For more information please refer to the original paper: 
+For more information please refer to the original paper:
 [A Hybrid DSP/Deep Learning Approach to Real-Time Full-Band Speech Enhancement](https://arxiv.org/pdf/1709.08243.pdf)
 
 ## Post-processing
@@ -95,7 +95,7 @@
 ### Dumping post-processed results for all inferences
 
 The Noise Reduction application uses the memory address specified by
-`noise_reduction_MEM_DUMP_BASE_ADDR` as a buffer to store post-processed results from all inferences. 
+`noise_reduction_MEM_DUMP_BASE_ADDR` as a buffer to store post-processed results from all inferences.
 The maximum size of this buffer is set by the parameter
 `noise_reduction_MEM_DUMP_LEN` which defaults to 1 MiB.
 
@@ -114,7 +114,7 @@
 ```
 
 In the preceding output we can see that it starts at the default address of
-`0x80000000` where some header information is dumped. Then, after the first inference 960 bytes 
+`0x80000000` where some header information is dumped. Then, after the first inference 960 bytes
 (480 INT16 values) are written to the first address after the dumped header `0x80000014`.
 Each inference afterward will then write another 960 bytes to the next address and so on until all inferences
 are complete.
@@ -153,15 +153,15 @@
   WAV file, to be used in the application. The default value points to the
   `resources/noise_reduction/samples` folder containing the delivered set of audio clips.
 
-- `noise_reduction_AUDIO_RATE`: The input data sampling rate. Each audio file from `noise_reduction_FILE_PATH` is 
+- `noise_reduction_AUDIO_RATE`: The input data sampling rate. Each audio file from `noise_reduction_FILE_PATH` is
   preprocessed during the build to match the NN model input requirements. The default value is `48000`.
 
 - `noise_reduction_AUDIO_MONO`: If set to `ON`, then the audio data is converted to mono. The default value is `ON`.
 
-- `noise_reduction_AUDIO_OFFSET`: Begins loading audio data and starts from this specified offset, defined in seconds. 
+- `noise_reduction_AUDIO_OFFSET`: Begins loading audio data and starts from this specified offset, defined in seconds.
   The default value is set to `0`.
 
-- `noise_reduction_AUDIO_DURATION`: The length of the audio data to be used in the application in seconds. 
+- `noise_reduction_AUDIO_DURATION`: The length of the audio data to be used in the application in seconds.
   The default is `0`, meaning that the whole audio file is used.
 
 - `noise_reduction_AUDIO_MIN_SAMPLES`: Minimum number of samples required by the network model. If the audio clip is shorter than
@@ -208,7 +208,6 @@
 - [Configuring with custom TPIP dependencies](../sections/building.md#configuring-with-custom-tpip-dependencies)
 - [Using Arm Compiler](../sections/building.md#using-arm-compiler)
 - [Configuring the build for simple-platform](../sections/building.md#configuring-the-build-for-simple_platform)
-- [Working with model debugger from Arm Fast Model Tools](../sections/building.md#working-with-model-debugger-from-arm-fast-model-tools)
 - [Building for different Ethos-U variants](../sections/building.md#building-for-different-ethos_u-npu-variants)
 
 > **Note:** If you are rebuilding with changed parameters values, it is highly advised that you
@@ -255,7 +254,7 @@
 ### Add custom input
 
 To run with inputs different to the ones supplied, the parameter `noise_reduction_FILE_PATH` can be
-pointed to a WAV file, or a directory containing WAV files. Once you have a directory with WAV files, 
+pointed to a WAV file, or a directory containing WAV files. Once you have a directory with WAV files,
 run the following command:
 
 ```commandline
@@ -285,7 +284,7 @@
 > **Note** Changing the neural network model often also requires the pre-processing implementation
 > to be changed. Please refer to:
 > [How the default neural network model works](./noise_reduction.md#how-the-default-neural-network-model-works).
-
+>
 > **Note:** Before re-running the CMake command, clean the build directory.
 
 The `.tflite` model file, which is pointed to by `noise_reduction_MODEL_TFLITE_PATH`, is converted
@@ -380,7 +379,7 @@
     > **Note:** Select the index in the range of supplied WAVs during application build. By default,
     the pre-built application has three files and indexes from 0-2.
 
-3. “Run noise reduction on all WAVs”: Triggers sequential processing and inference executions on 
+3. “Run noise reduction on all WAVs”: Triggers sequential processing and inference executions on
    all baked-in WAV files.
 
 4. “Show NN model info”: Prints information about the model data type, including the input and
@@ -418,7 +417,7 @@
     INFO - Quant dimension: 0
     INFO - Scale[0] = 0.007843
     INFO - ZeroPoint[0] = -1
-    INFO - Model OUTPUT tensors: 
+    INFO - Model OUTPUT tensors:
     INFO -  tensor type is INT8
     INFO -  tensor occupies 96 bytes with dimensions
     INFO -          0:   1
@@ -493,7 +492,7 @@
 INFO - Output memory dump of 130580 bytes written at address 0x80000000
 INFO - Final results:
 INFO - Profile for Inference:
-INFO - NPU AXI0_RD_DATA_BEAT_RECEIVED beats: 530 
+INFO - NPU AXI0_RD_DATA_BEAT_RECEIVED beats: 530
 INFO - NPU AXI0_WR_DATA_BEAT_WRITTEN beats: 376
 INFO - NPU AXI1_RD_DATA_BEAT_RECEIVED beats: 13911
 INFO - NPU ACTIVE cycles: 103870
@@ -503,7 +502,7 @@
 
 > **Note:** When running Fast Model, each inference can take several seconds on most systems.
 
-Each inference dumps the post processed output to memory. For further information, please refer to: 
+Each inference dumps the post processed output to memory. For further information, please refer to:
 [Dumping post processed results for all inferences](./noise_reduction.md#dumping-post_processed-results-for-all-inferences).
 
 The profiling section of the log shows that for this inference:
diff --git a/docs/use_cases/object_detection.md b/docs/use_cases/object_detection.md
index 1b74cf1..e946c1b 100644
--- a/docs/use_cases/object_detection.md
+++ b/docs/use_cases/object_detection.md
@@ -14,13 +14,14 @@
     - [Running Object Detection](./object_detection.md#running-object-detection)
 
 ## Introduction
+
 This document describes the process of setting up and running the Arm® *Ethos™-U* NPU Object Detection example.
 Object Detection is a classical computer vision use case in which specific objects need to be identified and located
 within a full frame. In this specific example the model was trained for face detection. The ML sample was developed
 using the *YOLO Fastest* model.  To adopt the model for low power / low memory systems the input images to the model
 are monochrome images. The model was trained on the *Wider* dataset (after conversion from RGB to monochrome)
-and on *Emza Visual-Sense* dataset [www.emza-vs.com](www.emza-vs.com).
-The model makes detection faces in size of 20x20 pixels and above. 
+and on *Emza Visual-Sense* dataset <www.emza-vs.com>.
+The model makes detection faces in size of 20x20 pixels and above.
 
 Use-case code could be found in the following directory:[source/use_case/object_detection](../../source/use_case/object_detection).
 
@@ -99,7 +100,6 @@
 - [Configuring with custom TPIP dependencies](../sections/building.md#configuring-with-custom-tpip-dependencies)
 - [Using Arm Compiler](../sections/building.md#using-arm-compiler)
 - [Configuring the build for simple-platform](../sections/building.md#configuring-the-build-for-simple_platform)
-- [Working with model debugger from Arm Fast Model Tools](../sections/building.md#working-with-model-debugger-from-arm-fast-model-tools)
 - [Building for different Ethos-U NPU variants](../sections/building.md#building-for-different-ethos_u-npu-variants)
 
 > **Note:** If re-building with changed parameters values, we recommend that you clean the build directory and re-run
diff --git a/docs/use_cases/visual_wake_word.md b/docs/use_cases/visual_wake_word.md
index 918402d..a6f6130 100644
--- a/docs/use_cases/visual_wake_word.md
+++ b/docs/use_cases/visual_wake_word.md
@@ -88,7 +88,6 @@
 - [Configuring with custom TPIP dependencies](../sections/building.md#configuring-with-custom-tpip-dependencies)
 - [Using Arm Compiler](../sections/building.md#using-arm-compiler)
 - [Configuring the build for simple-platform](../sections/building.md#configuring-the-build-for-simple_platform)
-- [Working with model debugger from Arm Fast Model Tools](../sections/building.md#working-with-model-debugger-from-arm-fast-model-tools)
 - [Building for different Ethos-U NPU variants](../sections/building.md#building-for-different-ethos-u-npu-variants)
 
 > **Note:** If re-building with changed parameters values, it is highly advised to clean the build directory and re-run
@@ -301,7 +300,7 @@
     INFO - Added ethos-u support to op resolver
     INFO - Creating allocator using tensor arena in SRAM
     INFO - Allocating tensors
-    INFO - Model INPUT tensors: 
+    INFO - Model INPUT tensors:
     INFO -  tensor type is INT8
     INFO -  tensor occupies 16384 bytes with dimensions
     INFO -          0:   1
@@ -311,7 +310,7 @@
     INFO - Quant dimension: 0
     INFO - Scale[0] = 0.008138
     INFO - ZeroPoint[0] = -70
-    INFO - Model OUTPUT tensors: 
+    INFO - Model OUTPUT tensors:
     INFO -  tensor type is INT8
     INFO -  tensor occupies 2 bytes with dimensions
     INFO -          0:   1