Porting header fixes

iriark01 · iriark01 · commit 4f3f38da4a69 · 2020-04-23T08:42:29.000+01:00
diff --git a/docs/porting/porting_full_process/built_in_tests.md b/docs/porting/porting_full_process/built_in_tests.md
@@ -9,9 +9,9 @@ It's important to test your port at the end of each module porting, rather than
 
 Read the following page to understand how tests are structured:
 
-# Prerequisites
+## Prerequisites
 
-## Minimum HAL module support
+### Minimum HAL module support
 
 To run the Mbed OS built-in tests, you need to have ported and verified at least these HAL modules:
 
@@ -23,7 +23,7 @@ To run the Mbed OS built-in tests, you need to have ported and verified at least
 You'll also need to have ported DAPLink or compatible interface firmware to your interface chip.
     <span class="notes">If DAPLink is still under development, you can still [run tests manually](../porting/manual-testing.html).</span>
 
-## mbedls
+### mbedls
 
 The platform under test needs to be supported in mbedls for automated tests to work.
 
@@ -47,7 +47,7 @@ If an updated mbedls pip package including support for your platform hasn't been
 
     Where `"33000000e062afa300000000000000000000000097969902"` is the correct target id.
 
-# Compiling and running tests
+## Compiling and running tests
 
 1. Compile the tests:
     - To compile all tests, run `mbed test --compile`.
@@ -115,7 +115,7 @@ mbedgt: test case results: 12 OK
 mbedgt: completed in 20.24 sec
 ```
 
-# Manual testing
+## Manual testing
 
 You may want to run tests manually, for example if DAPLink is still under development. You will need to export your tests from Greentea and import them to your IDE. For example:
 
@@ -157,7 +157,7 @@ You may want to run tests manually, for example if DAPLink is still under develo
     Customize the serial port path and baudrate as needed.
 
 
-# Mbed OS built-in tests - detailed procedure
+## Mbed OS built-in tests - detailed procedure
 
 Whether you're using Greentea or performing manual tests, the procedure for using the built-in Mbed OS tests is the same.
 
diff --git a/docs/porting/porting_full_process/demo_testing.md b/docs/porting/porting_full_process/demo_testing.md
@@ -5,7 +5,7 @@ You can use two applications to test your port:
 1. When you've ported GPIO (and all preceeding modules), use `mbed-os-example-blinky`.
 1. When you've ported all mandatory modules, use `mbed-cloud-client-example` (the Device Management Client runs on top of Mbed OS, and you don't need to manually port it). This test includes a reference bootloader for firmware update testing.
 
-# mbed-os-example-blinky
+## mbed-os-example-blinky
 
 1. Application repository: [https://github.com/ARMmbed/mbed-os-example-blinky](https://github.com/ARMmbed/mbed-os-example-blinky).
 1. Import the repo, if you haven't done this already while porting:
@@ -30,7 +30,7 @@ You can use two applications to test your port:
 1. Verify the designated LED flashes every 0.5 second. You can use an oscilloscope for accurate measurement.
 
 
-# mbed-cloud-client-example
+## mbed-cloud-client-example
 
 Start with building the bootloader, which you will need for the firmware update portion of this test:
 
diff --git a/docs/porting/porting_full_process/integration-tests.md b/docs/porting/porting_full_process/integration-tests.md
@@ -2,7 +2,7 @@
 
 Mbed OS provides a set of integration tests to help you identify integration issues around storage devices and connectivity devices. If you're using a custom board, these tests can also help you verify your board works well in your environment.
 
-# Test suites
+## Test suites
 
 | **Test suite** | **Description** |
 | ------------- | ------------- |
@@ -12,36 +12,36 @@ Mbed OS provides a set of integration tests to help you identify integration iss
 | `net-multi` | Network multithreaded test for 1, 2 and 3 download threads with 1kb receive buffer size. |
 | `stress-net-fs` | Network and file system single and multithreaded tests:<ul><li>memory allocation - 10k, 20k, 40k, 60k</li><li>1 thread (sequential) - 1 download (1kb buffer), 1 file thread (1kb buffer)</li><li>2 parallel threads - 1 download, 1 file thread (1kb buffer)</li><li>3 parallel threads - 1 download, 2 file (256 bytes, 1 kb buffer)</li><li>4 parallel threads - 1 download, 3 file (1 byte, 256 bytes, 1kb buffer)</li></ul> |
 
-# Execute tests
+## Execute tests
 
 The integration test requires you to configure both the connectivity and storage devices.
 
-If a platform has both of them enabled by default (in `targets.json`), then you can compile the tests and run them from inside the `mbed-os` directory: 
+If a platform has both of them enabled by default (in `targets.json`), then you can compile the tests and run them from inside the `mbed-os` directory:
 
     ```
     $ mbed test -t <toolchain> -m <platform> -n *integration-* -DINTEGRATION_TESTS -v
     ```
-    
+
 If a board doesn't have default connectivity and storage, it requires an extra shield to run the integration test. In this case, you can pass a `target_extended.json` file in the command-line to configure the target:
 
    ```
    $ mbed test -t <toolchain> -m <platform> -n *integration-* -DINTEGRATION_TESTS --app-config TESTS\integration\COMMON\target_extended.json -v
    ```
-   
+
 A preconfiguration file is defined in the COMMON folder, and that file covers some of the platform connectivity and storage combinations. However, this preconfiguration file might contain some compoments drivers not included in `mbed-os` (for example, `WIFI_WIZFI310` and `NUSD`). You must add those drivers manually. If you have your own platform or want to define your own configuration, please follow the [configuration guide](#tests-configuration).
 
-# Tests configuration
+## Tests configuration
 
 If required, edit the `target_extended.json` file, and create a new entry under `target_overrides` with the target name for your device:
 
 - **Connectivity** - Specify the default connectivity type for your target. It's essential with targets that lack default connectivity set in `targets.json` or for targets that support multiple connectivity options. For example:
-  
+
    ```
             "target.network-default-interface-type" : "ETHERNET",
    ```
-   
+
    The possible options are `ETHERNET`, `WIFI` and `CELLULAR`.
-   
+
    Depending on connectivity type, you might have to specify more configuration options. For an example, please see the defined `CELLULAR` targets in `mbed_app.json`.
 
 - **Storage** - Specify the storage block device type, which dynamically adds the block device driver you specified at compile time. For example:
@@ -53,13 +53,12 @@ If required, edit the `target_extended.json` file, and create a new entry under
    Valid options are `SD`, `SPIF` and `QSPIF`. For more available options, please see the [block device components](https://github.com/ARMmbed/mbed-os/tree/master/components/storage/blockdevice).
 
    You also have to specify the block device pin configuration, which may vary from one block device type to another. Here's an example for `SD`:
-   
+
    ```
             "sd.SPI_MOSI"                      : "PE_6",
             "sd.SPI_MISO"                      : "PE_5",
             "sd.SPI_CLK"                       : "PE_2",
             "sd.SPI_CS"                        : "PE_4",
    ```
-   
+
    If you are using SPI or QSPI flash, please make sure you have specified the correct SPI frequency by configuring `spif-driver.SPI_FREQ`. If it is not configured, 40Mhz is applied by default.
-   
diff --git a/docs/porting/porting_full_process/porting.md b/docs/porting/porting_full_process/porting.md
@@ -1,6 +1,6 @@
 # Getting a working baseline
 
-# Create forks
+## Create forks
 
 Please fork or branch the following repositories:
 
@@ -12,7 +12,7 @@ Please fork or branch the following repositories:
 - [Blinky](https://github.com/armmbed/mbed-os-example-blinky).
 - [Device Management Cloud Client example](https://github.com/armmbed/mbed-cloud-client-example).
 
-# Get the Mbed OS source code
+## Get the Mbed OS source code
 
 The following Mbed CLI commands retrieve and fork the `mbed-os-example-blinky` code, and redirect `mbed-os` to point to the newly forked `mbed-os` repository:
 
@@ -37,7 +37,7 @@ git remote add upstream https://github.com/ARMmbed/mbed-os
 git checkout -b <branch_name>
 ```
 
-# Build the Blinky program for an existing target
+## Build the Blinky program for an existing target
 
 To verify that you have a working fork, please build Blinky to a supported target:
 
@@ -55,7 +55,7 @@ You now have a working baseline and are ready to add a new target.
 
 # Adding a new target
 
-# Add a new target to FlashAlgo
+## Add a new target to FlashAlgo
 
 DAPlink requires FlashAlgo to program a target. You need to either write FlashAlgo source code yourself, or use the one provided with your MCU.
 
@@ -76,7 +76,7 @@ Repo: [https://github.com/mbedmicro/flashalgo](https://github.com/mbedmicro/flas
 
 1. In Keil MDK, open the project file for your target in `\projectfiles\uvision<target>`, and build it. The build directory of a successful build will have the files `c_blob.c` and `c_blob_mbed.c`; save both files. You will use them in the next step (`c_blob.c` in `flash_blob.c`, and `c_blob_mbed.c` in Flash API).
 
-# Add your new target to DAPLink
+## Add your new target to DAPLink
 
 <span class="notes">This step requires a Windows PC.</span>
 
@@ -91,7 +91,7 @@ Repo: [https://github.com/armmbed/daplink](https://github.com/armmbed/daplink).
     - One PR against the DAPLink repository.
     - One PR against the FlashAlgo repository.
 
-# Add your new target to pyOCD
+## Add your new target to pyOCD
 
 To be able to debug your port:
 
@@ -104,7 +104,7 @@ Wait for your target support to be merged into pyOCD's master branch and release
 # Setting up to debug Mbed OS programs
 
 
-# Update DAPLink interface firmware
+## Update DAPLink interface firmware
 
 You need to update the new DAPLink interface firmware, which includes the new target support, on your interface MCU.
 
@@ -118,7 +118,7 @@ To include the new target support:
     1. Plug the USB cable to the host.
     1. Drag-n-drop the interface firmware.
 
-# Create GDB pyOCD debug configuration
+## Create GDB pyOCD debug configuration
 
 1. Install pyOCD. You need the version with the new target support. If you contributed to PyOCD and an updated version hasn't been released yet, you can invoke the local copy:
 
@@ -152,7 +152,7 @@ To include the new target support:
 
 # Porting HAL modules
 
-# Recommended porting order
+## Recommended porting order
 
 Based on criticality and dependency of Mbed OS software stack, we recommend the following order:
 
@@ -173,13 +173,13 @@ Based on criticality and dependency of Mbed OS software stack, we recommend the
 
 Detailed instructions for porting each module are given in the module-specific sections of this documentation.
 
-# Create the bare metal mbed-os-example-blinky
+## Create the bare metal mbed-os-example-blinky
 
 The official `mbed-os-example-blinky` uses the RTOS, a DigitalOut object and timers. The bare metal version of the example doesn't rely on RTOS, GPIO and timers; LED toggling is done directly by accessing hardware registers. Modify the Blinky program you checked out earlier to not use the timer and DigitalOut object:
 
 [![View code](https://www.mbed.com/embed/?url=https://github.com/ARMmbed/mbed-os-examples-docs_only/blob/master/Porting_process/Direct-Register-Blinky)](https://github.com/ARMmbed/mbed-os-examples-docs_only/blob/master/Porting_process/Direct-Register-Blinky/main.cpp)
 
-# Bootstrap and entry point
+## Bootstrap and entry point
 
 [Bootstrap porting instructions](../reference/bootstrap.html).
 
@@ -215,13 +215,13 @@ mbed compile --target <target_name> --toolchain ARM
 mbed compile --target <target_name> --toolchain IAR
 ```
 
-# Serial Port (synchronous transfer)
+## Serial Port (synchronous transfer)
 
 [Serial port porting instructions](../porting/serial-port.html).
 
 Serial port porting can be done in two stages: synchronous UART and asynchronous UART. We recommend porting synchronous UART as early as possible, because the HAL Greentea tests require it, and because `printf()` is a powerful debugging tool.
 
-# Low power ticker
+## Low power ticker
 
 <span class="notes">**Note**: Low power ticker is mandatory for any platform that supports it.</span>
 
@@ -235,39 +235,39 @@ When you finish porting low power ticker:
 The [Mbed OS doxygen describes LowPowerTicker tests](https://os.mbed.com/docs/latest/mbed-os-api-doxy/group__hal__lp__ticker__tests.html).
 
 
-# Microsecond Ticker
+## Microsecond Ticker
 
 [Microsecond ticker porting instructions](../porting/microsecond-ticker.html).
 
 When you finish porting the microsecond ticker, the `wait` API should work, and the intervals should be exact. You can verify this with `printf`.
 
-# GPIO (write and read) and IRQ
+## GPIO (write and read) and IRQ
 
 [GPIO porting instructions](../porting/gpio.html).
 
 The vanilla Blinky program uses GPIO, which is a great tool for debugging with an oscilloscope or logic analyzer. It's a good idea to port GPIO before any other peripherals.
 
 You can now try [using the normal Blinky application](../porting/testing-with-the-demo-applications.html).
 
-# RTC
+## RTC
 
 [RTC porting instructions](../porting/rtc-port.html).
 
 RTC is a dependency of SPI (master) tests.
 
 On some targets, RTC is shared with low power ticker and you can only use one of them. On these targets, you must use low power ticker instead of RTC.
 
-# SPI (master)
+## SPI (master)
 
 SPI (master) is used to communicate with storage devices that have an SPI interface, such as SD cards. The CI test shield supports an SD card as a slave device, so you can use it to test SPI (master) implementations on evaluation boards that don't have an SPI slave.
 
-# TRNG
+## TRNG
 
 [True random number generator entropy source (TRNG) porting instructions](../porting/entropy-sources.html).
 
 If the hardware supports TRNG, you must port it before running Device Management Client, because the client uses TLS, which in turn requires an entropy source.
 
-# Connectivity
+## Connectivity
 
 [Porting instructions for all connectivity options](../porting/porting-connectivity.html).
 
@@ -279,24 +279,24 @@ You can now try running the example applications for your connectivity methods.
 - [https://github.com/ARMmbed/mbed-os-example-cellular](https://github.com/ARMmbed/mbed-os-example-cellular).
 - [https://github.com/ARMmbed/mbed-os-example-sockets](https://github.com/ARMmbed/mbed-os-example-sockets).
 
-# Flash
+## Flash
 
 [Flash porting instructions](../porting/flash.html).
 
 Flash drivers are required by Device Management Client.
 
 There are two ways to implement flash API: using CMSIS flash algorithms or vanilla C source code. We recommend using vanilla C source code, because it's easier to maintain and upgrade. It's also more portable across different platforms.
 
-# Bootloader
+## Bootloader
 
 [Bootloader porting instructions](../porting/bootloader.html).
 
 The bootloader is a separate application, which needs to be created and integrated into Device Management Client to allow firmware updates.
 
-# Device Management Client
+## Device Management Client
 
 You do not need to manually port Device Management Client; when the above modules are ported, you should be ready to [demo the Connect and Update functionalities of the Device Management Client](https://cloud.mbed.com/guides/connect-device-to-pelion).
 
-# Other HAL modules (Optional)
+## Other HAL modules (Optional)
 
 You are now ready to port any other HAL modules that your use case and MCU require. These modules are covered in the rest of this document, with the exception of [Mbed Cordio, which has its own porting documentation](https://os.mbed.com/docs/mbed-cordio/latest/porting-pal/index.html).
diff --git a/docs/porting/porting_full_process/porting_reqs.md b/docs/porting/porting_full_process/porting_reqs.md
@@ -1,6 +1,6 @@
 # Setting up
 
-# Hardware setup
+## Hardware setup
 
 Porting Mbed OS requires the following hardware:
 
@@ -23,14 +23,14 @@ The following items might help you test SPI, I2C and pins:
 
 <span class="tips">Check the user guide of the evaluation board to see if anything needs to be done prior to using a debug probe and running Mbed OS programs.</span>
 
-# Software setup
+## Software setup
 
 Please install the following:
 
 - [Python](https://www.python.org/downloads).
 - [Git](https://git-scm.com/downloads).
 - [Mbed CLI](../tools/installation-and-setup.html).
-- Choose an IDE and debugger. The three commonly used IDEs are [Eclipse](https://www.eclipse.org/ide/), [IAR Embedded Workbench](https://www.iar.com/iar-embedded-workbench/) and [Keil MDK](http://www.keil.com/). 
+- Choose an IDE and debugger. The three commonly used IDEs are [Eclipse](https://www.eclipse.org/ide/), [IAR Embedded Workbench](https://www.iar.com/iar-embedded-workbench/) and [Keil MDK](http://www.keil.com/).
 
     Limitations:
 
diff --git a/docs/porting/porting_full_process/porting_start.md b/docs/porting/porting_full_process/porting_start.md
@@ -8,7 +8,7 @@ This document provides guidelines for adding a new MCU target to Mbed OS and the
 
 These guidelines use pyOCD, our debugger, and DAPLink, our interface firmware, in the porting process because they are free and open source. Please note that you can use other debuggers and interface firmware, but that is outside the scope of this document.
 
-# Scope and milestones
+## Scope and milestones
 
 You will usually need to go through all of these steps to port Mbed OS:
 
