[K32W1] Fix misspell

Signed-off-by: Marius Tache <[email protected]>

examples/contact-sensor-app/nxp/k32w/k32w1/README.md

@@ -112,7 +112,7 @@ NOTE:
 **RGB LED** shows the state of the simulated contact sensor. when the LED is lit,
 the sensor is contacted, when not lit, the sensor is non-contacted.
 
-**Button SW2** can be used to start BLE adevertising. A SHORT press of the buttton 
+**Button SW2** can be used to start BLE advertising. A SHORT press of the button 
 will enable Bluetooth LE advertising for a predefined period of time. A LONG Press
 Button SW2 initiates a factory reset. After an initial period of 3 seconds, LED 2
 and RGB LED will flash in unison to signal the pending reset. After 6 seconds will
@@ -154,19 +154,19 @@ After a successful build, the `elf` and `srec` files are found in `out/debug/` -
 
 ## Flashing
 
-Two images must be written to the board: one for the host (CM33) and one for the NBU (CM3).
+Two images must be written to the board: one for the host (CM33) and one for the `NBU` (CM3).
 
-The image needed on the host side is the one generated in `out/debug/` while the one needed on the NBU side can be found in the downloaded NXP-SDK package at path -	`middleware\wireless\ieee-802.15.4\bin\k32w1\k32w1_nbu_ble_15_4_dyn_matter_$version.sb3`.
+The image needed on the host side is the one generated in `out/debug/` while the one needed on the `NBU` side can be found in the downloaded NXP-SDK package at path -	`middleware\wireless\ieee-802.15.4\bin\k32w1\k32w1_nbu_ble_15_4_dyn_matter_$version.sb3`.
 
 <a name="flashing-the-nbu-image"></a>
 
 ### Flashing the NBU image
 
-NBU image should be written only when a new NXP-SDK is released.
+`NBU` image should be written only when a new NXP-SDK is released.
 
-[K32W148 board quick start guide](https://www.nxp.com/document/guide/getting-started-with-the-k32w148-development-platform:GS-K32W148EVK) can be used for updating the NBU/radio core:
-- Section 2.4 – Get Software – install SPSDK (Secure Provisioning Command Line Tool)
-- Section 3.3 – Updating NBU for Wireless examples - use the corresponding .sb3 file found in the SDK package at path `middleware\wireless\ieee-802.15.4\bin\k32w1\`
+[K32W148 board quick start guide](https://www.nxp.com/document/guide/getting-started-with-the-k32w148-development-platform:GS-K32W148EVK) can be used for updating the `NBU/radio` core:
+- Section 2.4 – Get Software – install `SPSDK` (Secure Provisioning Command Line Tool)
+- Section 3.3 – Updating `NBU` for Wireless examples - use the corresponding `.sb3` file found in the SDK package at path `middleware\wireless\ieee-802.15.4\bin\k32w1\`
 
 <a name="flashing-the-host-image"></a>
 
@@ -249,10 +249,10 @@ Run -> Debug Configurations... -> C/C++ Application
 
 The OTA image files must be encrypted using Over The Air Programming Tool ([OTAP](https://www.nxp.com/design/microcontrollers-developer-resources/connectivity-tool-suite:CONNECTIVITY-TOOL-SUITE?#downloads)). Bootloader will load the new OTA image only if it detects that the file was encrypted with the OTAP correct keys. 
 
-.srec file is input for Over The air Programming (OTAP) application (unencrypted) and it's converted to .sb3 format (encrypted).
+`.srec` file is input for Over The air Programming (`OTAP`) application (unencrypted) and it's converted to `.sb3` format (encrypted).
 
 In OTAP application
-- select OTA protocol => OTAP Matter
+- select OTA protocol => `OTAP` Matter
 - Browse File 
 - follow default options (KW45/K32W148, Preserve NVM) 
 - image information: will update "Application Core (MCU)" - this will generate the image only for the CM33 core

examples/contact-sensor-app/nxp/k32w/k32w1/main/AppTask.cpp

@@ -154,7 +154,7 @@ CHIP_ERROR AppTask::Init()
 
     UpdateDeviceState();
 
-    /* intialize the Keyboard and button press calback */
+    /* intialize the Keyboard and button press callback */
     BUTTON_InstallCallback((button_handle_t)g_buttonHandle[0], KBD_Callback, (void*)BLE_BUTTON);
     BUTTON_InstallCallback((button_handle_t)g_buttonHandle[1], KBD_Callback, (void*)CONTACT_SENSOR_BUTTON);
 

examples/lighting-app/nxp/k32w/k32w1/README.md

@@ -107,14 +107,14 @@ states are depicted:
 
 NOTE:
     LED2 will be disabled when CHIP_DEVICE_CONFIG_ENABLE_OTA_REQUESTOR is enabled.
-    On K32W1 EVK board, PTB0 is wired to LED2 also is wired to CS (Chip Select) 
+    On K32W1 EVK board, `PTB0` is wired to LED2 also is wired to CS (Chip Select) 
     External Flash Memory. OTA image is stored in external memory because of it's size.
     If LED2 is enabled then it will affect External Memory CS and OTA will not work.
 
 **RGB LED** shows the state of the simulated light bulb. When the LED is lit the
 light bulb is on; when not lit, the light bulb is off.
 
-**Button SW2** can be used to start BLE adevertising. A SHORT press of the buttton 
+**Button SW2** can be used to start BLE advertising. A SHORT press of the button 
 will enable Bluetooth LE advertising for a predefined period of time. A LONG Press
 Button SW2 initiates a factory reset. After an initial period of 3 seconds, LED 2
 and RGB LED will flash in unison to signal the pending reset. After 6 seconds will
@@ -151,7 +151,7 @@ user@ubuntu:~/Desktop/git/connectedhomeip/examples/lighting-app/nxp/k32w/k32w1$
 user@ubuntu:~/Desktop/git/connectedhomeip/examples/lighting-app/nxp/k32w/k32w1$ ninja -C out/debug
 ```
 
-In case that Openthread CLI is needed, chip_with_ot_cli build argument must be
+In case that Openthread CLI is needed, `chip_with_ot_cli` build argument must be
 set to 1.
 
 After a successful build, the `elf` and `srec` files are found in `out/debug/` - see the files prefixed with `chip-k32w1-light-example`.
@@ -160,33 +160,33 @@ After a successful build, the `elf` and `srec` files are found in `out/debug/` -
 
 ### SMU2 Memory
 
-Some Matter instances and global variables can be placed in the NBU's SMU2 memory. When compiling with OpenThread FTD support (`chip_openthread_ftd=true`) and with `use_smu2_as_system_memory=true`, the following components are placed in SMU2 memory:
-* `gImageProcessor` from OTAImageProcessorImpl.cpp.
-* `gApplicationProcessor` from OTAHooks.cpp.
-* `Server::sServer` from Server.cpp.
-* `ThreadStackManagerImpl::sInstance` from ThreadStackManagerImpl.cpp.
+Some Matter instances and global variables can be placed in the `NBU` `SMU2` memory. When compiling with OpenThread FTD support (`chip_openthread_ftd=true`) and with `use_smu2_as_system_memory=true`, the following components are placed in `SMU2` memory:
+* `gImageProcessor` from `OTAImageProcessorImpl.cpp`.
+* `gApplicationProcessor` from `OTAHooks.cpp`.
+* `Server::sServer` from `Server.cpp`.
+* `ThreadStackManagerImpl::sInstance` from `ThreadStackManagerImpl.cpp`.
 
-These instances and global variables are placed in SMU2 memory through name matching in the application linker script. They should not be changed or, if changed, the names must be updated in `k32w1_app.ld`. See [k32w1_app.ld](../../../../platform/nxp/k32w/k32w1/app/ldscripts/k32w1_app.ld) for names and SMU2 memory range size.
+These instances and global variables are placed in `SMU2` memory through name matching in the application linker script. They should not be changed or, if changed, the names must be updated in `k32w1_app.ld`. See [k32w1_app.ld](../../../../platform/nxp/k32w/k32w1/app/ldscripts/k32w1_app.ld) for names and `SMU2` memory range size.
 
-To use the SMU2 Memory an optimized NBU binary is also needed. See [Flashing the NBU image](#flashing-the-nbu-image).
+To use the `SMU2` Memory an optimized `NBU` binary is also needed. See [Flashing the NBU image](#flashing-the-nbu-image).
 
 <a name="flashing"></a>
 
 ## Flashing
 
-Two images must be written to the board: one for the host (CM33) and one for the NBU (CM3).
+Two images must be written to the board: one for the host (CM33) and one for the `NBU` (CM3).
 
-The image needed on the host side is the one generated in `out/debug/` while the one needed on the NBU side can be found in the downloaded NXP-SDK package at path -	`middleware\wireless\ieee-802.15.4\bin\k32w1\k32w1_nbu_ble_15_4_dyn_matter_$version.sb3`.
+The image needed on the host side is the one generated in `out/debug/` while the one needed on the `NBU` side can be found in the downloaded NXP-SDK package at path -	`middleware\wireless\ieee-802.15.4\bin\k32w1\k32w1_nbu_ble_15_4_dyn_matter_$version.sb3`.
 
 <a name="flashing-the-nbu-image"></a>
 
 ### Flashing the NBU image
 
-NBU image should be written only when a new NXP-SDK is released.
+`NBU` image should be written only when a new NXP-SDK is released.
 
-[K32W148 board quick start guide](https://www.nxp.com/document/guide/getting-started-with-the-k32w148-development-platform:GS-K32W148EVK) can be used for updating the NBU/radio core:
-- Section 2.4 – Get Software – install SPSDK (Secure Provisioning Command Line Tool)
-- Section 3.3 – Updating NBU for Wireless examples - use the corresponding .sb3 file found in the SDK package at path `middleware\wireless\ieee-802.15.4\bin\k32w1\`
+[K32W148 board quick start guide](https://www.nxp.com/document/guide/getting-started-with-the-k32w148-development-platform:GS-K32W148EVK) can be used for updating the `NBU/radio` core:
+- Section 2.4 – Get Software – install `SPSDK` (Secure Provisioning Command Line Tool)
+- Section 3.3 – Updating `NBU` for Wireless examples - use the corresponding .sb3 file found in the SDK package at path `middleware\wireless\ieee-802.15.4\bin\k32w1\`
 
 <a name="flashing-the-host-image"></a>
 
@@ -267,12 +267,12 @@ Run -> Debug Configurations... -> C/C++ Application
 
 ### Convert srec into sb3 file
 
-The OTA image files must be encrypted using Over The Air Programming Tool ([OTAP](https://www.nxp.com/design/microcontrollers-developer-resources/connectivity-tool-suite:CONNECTIVITY-TOOL-SUITE?#downloads)). Bootloader will load the new OTA image only if it detects that the file was encrypted with the OTAP correct keys. 
+The OTA image files must be encrypted using Over The Air Programming Tool ([OTAP](https://www.nxp.com/design/microcontrollers-developer-resources/connectivity-tool-suite:CONNECTIVITY-TOOL-SUITE?#downloads)). Bootloader will load the new OTA image only if it detects that the file was encrypted with the `OTAP` correct keys. 
 
-.srec file is input for Over The air Programming (OTAP) application (unencrypted) and it's converted to .sb3 format (encrypted).
+`.srec` file is input for Over The air Programming (`OTAP`) application (unencrypted) and it's converted to `.sb3` format (encrypted).
 
-In OTAP application
-- select OTA protocol => OTAP Matter
+In `OTAP` application
+- select OTA protocol => `OTAP` Matter
 - Browse File 
 - follow default options (KW45/K32W148, Preserve NVM) 
 - image information: will update "Application Core (MCU)" - this will generate the image only for the CM33 core
@@ -415,4 +415,3 @@ user@computer1:~/connectedhomeip$ sudo ifconfig eth0 -multicast
 
 -   If Wi-Fi is used on a RPI4, then a 5Ghz network should be selected.
     Otherwise, issues related to BLE-WiFi combo may appear.
-

examples/lighting-app/nxp/k32w/k32w1/main/AppTask.cpp

@@ -156,7 +156,7 @@ CHIP_ERROR AppTask::Init()
     sLightLED.Init(LIGHT_STATE_LED, false);
     UpdateDeviceState();
 
-    /* intialize the Keyboard and button press calback */
+    /* intialize the Keyboard and button press callback */
     BUTTON_InstallCallback((button_handle_t)g_buttonHandle[0], KBD_Callback, (void*)BLE_BUTTON);
     BUTTON_InstallCallback((button_handle_t)g_buttonHandle[1], KBD_Callback, (void*)LIGHT_BUTTON);
 

src/platform/nxp/k32w/common/K32W_OTA_README.md

@@ -1,11 +1,11 @@
-# K32Wx OTA
+# K32W OTA
 
 The OTA processing is now delegated to instances of `OTATlvProcessor` derived classes.
 These instances are registered with the `OTAImageProcessorImpl` instance, which manages the selection of processors that should process the next blocks, until a full TLV block was transferred.
 
 The application is able to define its own processors, thus extending the default OTA functionality. The application can also opt to disable the default processors (application, SSBL and factory data).
 
-Please note that if an OTA image containing multiple TLVs is transferred, then the action for each TLV is applied sequentially,
+Please note that if an OTA image containing multiple TLV is transferred, then the action for each TLV is applied sequentially,
 If one of the actions fails, the remaining actions will not be applied and OTA abort is called.
 TBD: should all actions be applied only if there is no error? Or should each action be applied separately?
 
@@ -15,7 +15,7 @@ The default processors for K32W0 are already implemented in:
 * `OTAFactoryDataProcessor` for factory data update. Disabled by default, user has to specify `chip_ota_enable_factory_data_processor=1` in the build args.
 
 Some SDK OTA module flags are defined to support additional features:
-- `gOTAAllowCustomStartAddress=1` - enable EEPROM offset value. Used internally by SDK OTA module.
+- `gOTAAllowCustomStartAddress=1` - enable `EEPROM` offset value. Used internally by SDK OTA module.
 - `gOTAUseCustomOtaEntry=1` - support custom OTA entry for multi-image.
 - `gOTACustomOtaEntryMemory=1` - K32W0 uses `OTACustomStorage_ExtFlash` (1) by default.
 
@@ -53,7 +53,7 @@ This is a wrapper over `ProcessInternal`, which can return `CHIP_OTA_CHANGE_PROC
 * `ProcessInternal` should return:
     * `CHIP_NO_ERROR` if block was processed successfully.
     * `CHIP_ERROR_BUFFER_TOO_SMALL` if current block doesn't contain all necessary data.
-This can happen when a TLV's value field has a header, but it is split across two blocks.
+This can happen when a TLV value field has a header, but it is split across two blocks.
     * `CHIP_OTA_FETCH_ALREADY_SCHEDULED` if block was processed successfully and the fetching is already scheduled by the processor.
 This happens in the default application processor, because the next data fetching is scheduled through a callback (called when enough external flash was erased).
 

src/platform/nxp/k32w/k32w1/BLEManagerImpl.cpp

@@ -64,7 +64,7 @@ CHIP_ERROR BLEManagerImpl::InitHostController(ble_generic_cb_fp cb_fp)
     /* BLE Host Stack Init */
     VerifyOrExit(Ble_HostInitialize(cb_fp, Hcit_SendPacket) == gBleSuccess_c, err = CHIP_ERROR_INCORRECT_STATE);
 
-    /* configure tx power to use in NBU specfic to BLE */
+    /* configure tx power to use in NBU specific to BLE */
     Controller_SetTxPowerLevelDbm(mAdvertisingDefaultTxPower_c, gAdvTxChannel_c);
     Controller_SetTxPowerLevelDbm(mConnectionDefaultTxPower_c, gConnTxChannel_c);
     Controller_ConfigureInvalidPduHandling(gLlInvalidPduHandlingType_c);

src/platform/nxp/k32w/k32w1/CHIPCryptoPalK32W1.cpp

@@ -578,7 +578,7 @@ CHIP_ERROR P256PublicKey::ECDSA_validate_hash_signature(const uint8_t * hash, co
 
     if (bFreeAsyncCtx)
     {
-        /* Need to be very carefull, if we try to free something that is not initialized with success we will get an hw fault */
+        /* Need to be very careful, if we try to free something that is not initialized with success we will get an hw fault */
         (void)sss_sscp_asymmetric_context_free(&asyc);
     }
     (void)SSS_KEY_OBJ_FREE(&ecdsaPublic);
@@ -638,7 +638,7 @@ CHIP_ERROR P256Keypair::ECDH_derive_secret(const P256PublicKey & remote_public_k
 exit:
     (void)SSS_KEY_OBJ_FREE(&pEcdhPubKey);
 
-    /* Need to be very carefull, if we try to free something that is not initialized with success we will get a hw fault */
+    /* Need to be very careful, if we try to free something that is not initialized with success we will get a hw fault */
     if (bFreeSharedSecret)
         (void)SSS_KEY_OBJ_FREE(&sharedSecret);
     if (bFreeDeriveContex)

src/platform/nxp/k32w/k32w1/ram_storage.h

@@ -96,7 +96,7 @@ rsError ramStorageSet(ramBufferDescriptor *pBuffer, uint16_t aKey, const uint8_t
 rsError ramStorageAdd(ramBufferDescriptor *pBuffer, uint16_t aKey, const uint8_t *aValue, uint16_t aValueLength);
 
 /* search RAM Buffer for aKey (with aIndex) and delete it:
- * - if aIndex is -1 then all the  occurences of aKey are deleted
+ * - if aIndex is -1 then all the  occurrences of aKey are deleted
  */
 rsError ramStorageDelete(ramBufferDescriptor *pBuffer, uint16_t aKey, int aIndex);