Documentation fixes

Change-Id: I2036332cffee94f1a3b69b391586d0a2f6c9db55

5 files changed, 42 insertions, 27 deletions

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 @@ The next section of the documentation covers: [Testing and benchmarking](testing
 
 ## 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 @@ location of the platform library sources.
 > 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 @@ For example, if you changed the **img_class** model you would need to modify the
 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 @@ have definitions that describe the memory regions and the peripheral base addres
 
 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 @@ isram.bin       0x31000000  UNINIT ALIGN 16 0x00200000
     ...
 }
 ```
+
 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 @@ buffers is. These are:
 
 - 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 @@ vela \
 
 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).