I got a question related to best practices to configure a GPIO if the pin is not used. To make it short, the recommendation is to leave the GPIO floating on the PCB and leave the GPIO in its "Default" state as shown in the Signal Multiplexing table in the Reference Manual. The Default state is either “Disabled” or an analog function.   Some Kinetis devices have analog only pins (PGAx/ADCx) while most have GPIO pins with analog functions (PTx/ADCx) or digital GPIO pins   Unused pins, whether analog only or GPIO, should be left floating. Analog only pins do not have input buffers that will cause shoot-through currents when the input floats. GPIO pins with analog functions default to analog functions, which disables the digital input buffer – no shoot-through current.   The digital GPIO pins default to "Disabled", which disables the input buffers - no shoot-through currents with floating inputs.   Finally, unused pins shall not be tied to VDD or VSS. Hence, when designing your board and there are some unused pins, leave them floating on the PCB and then make sure that the software leaves the GPIO in its Default state in the MUX register. 

This post explains the implementation to operate the KW36 MCU on VLPR when the clocking mode is BLPE or BLPI. It's also included the explanation on how to configure clocks for BLPE and BLPI modes. For this example, the beacon demo from the wireless examples of the FRDM-KW36 is used. FRDM-KW36 SDK can be downloaded from MCUXpresso webpage. A recommended option to configure clock modes is "Config Tools" from MCUXpresso. Config Tools is embedded to MCUXpresso IDE, or you can download Config Tools from this LINK if you are using other supported IDE for this tool. MCUXpresso IDE is used in this example. Configure BLPE or BLPI clocking modes Select your proyect on MCUXpresso IDE, then open the clocks configuration window from Config Tools by clicking the arrow next to Config Tools icon from your MCUXpresso IDE, and then select "Open Clocks" as shown in Figure 1. Figure 1. Open Clocks from Config Tools using MCUXpresso IDE. A clocks diagram window will be opened. To configure the clock modes just select your option "BLPI" or "BLPE" on MCG Mode as shown in Figure 2. Clock will be automatically configured. Figure 2. MCG Mode selection. Now let's configure the appropiate clocks for Core clock and Bus clock to run in VLPR. Figure 3 taken from KW36 Reference Manual shows achievables frequencies when MCU is on VLPR.  Figure 3. VLPR clocks. Core clock should be 4MHz for BLPE and BLPI clocking modes, and Bus clock should be 1MHz for BLPE and 800kHz for BLPI.  Figure 4 shows clocks distribution for BLPE and Figure 5 for BLPI to operate with discussed frequencies. Figure 4. Clock distribution - VLPR and BLPE. Figure 5. Clock distribution - VLPR and BLPI. Press "Update Project" (Figure 6) to apply your new clock configuration to your firmware, then change perspective to "Develop" icon on right corner up to go to your project (See Figure 7). Compile your project to apply the changes. Figure 6. Update Project button. Figure 7. Develop button. At this point your project is ready to work with BLPE or BLPI clocks modes. Now, let's configure MCU to go to VLPR power mode. Configure VLPR mode VLPR mode can be configured using Config Tools too, but you may have an error trying to configure it when BLPE mode, this is because CLKDIV1 register cannot be written when the device is on VLPR mode. For this example, let's configure MCU into VLPR mode by firmware. Follow next steps to configure KW36 into VLPR power mode: 1. Configure RF Ref Oscillator to operate in VLPR mode. By default, the RF Ref Osc it's configured to operate into RUN mode. To change it to operate on VLPR mode just change the bits RF_OSC_EN from Radio System Control from 1 (RUN) to 7 (VLPR). Figure 8 taken from KW36 Reference Manual shows RF_OSC_EN value options from Radio System Control.    Figure 8. RF_OSC_EN bits from Radio System Control register. Go to clock_config.c file in your MCUXpresso project and search for "BOARD_RfOscInit" function. Change the code line as shown in Figure 9 to configure RF Ref Osc to work into VLPR mode. You may see a window asking if you want to make writable the read-only file, click Yes. Figure 9. Code line to configure RF Ref Osc to work into VLPR mode Be aware that code line shown in Figure 9 may change with updates done in clocks using Config Tools. Note 2. Configure DCDC in continuous mode. According to KW36 Reference Manual, the use of BLPE in VLPR mode is only feasible when the DCDC is configured for continuous mode. First, let's define gDCDC_Enabled_d flag to 1 on preprocesor. With this implementation, the use of DCDC_Init function will be enabled, and it's where we going to add the code line to enable continuous mode. Right click on your project, select Properties, go to Settings under C/C++ Build, then Preprocessor under MCU C Compiler (Figure 10).   Figure 10. MCUXpresso Preprocessor   Click on add button from Defined symbols, write gDCDC_Enabled_d=1 and click OK to finish (Figure 11).  Re-compile your project. Figure 11. MCUXpresso Defined symbols   Now let's set VLPR_VLPW_CONFIG_DCDC_HP bits to 1 from DCDC_REG0 register. Figure 12 was taken from KW36 Reference Manual. Figure 12. VLPR_VLPW_CONFIG_DCDC_HP values. Go to DCDC_Init  function and add the next code line to enable continuous mode on DCDC: DCDC->REG0 |= DCDC_REG0_VLPR_VLPW_CONFIG_DCDC_HP_MASK; Figure 13 shows the previous code line implemented in firmware project inside of DCDC_Init function. Figure 13. Continuous mode for DCDC enabled. 3. Configure MCU into VLPR mode To finish, let's write the code to configure MCU into VLPR power mode. Copy and paste next code just after doing implementation described on step 1 and 2: #if (defined(FSL_FEATURE_SMC_HAS_LPWUI) && FSL_FEATURE_SMC_HAS_LPWUI) SMC_SetPowerModeVlpr(SMC, false); #else SMC_SetPowerModeVlpr(SMC); #endif while (kSMC_PowerStateVlpr != SMC_GetPowerModeState(SMC)) { } It may be needed to add the SMC library: #include "fsl_smc.h" The code is configuring MCU into VLPR mode with bits RUNM from SMC_PMCTRL register (Figure 14) and then check if it was correctly configured by reading status bits PMSTAT from SMC_PMSTAT register (Figure 15) Figure 14. RUNM bits from SMC_PMCTRL register. Figure 15. PMSTAT bits from  SMC_PMSTAT register. KW36 is ready to operate and BLPE or BLPI clocking modes with VLPR power mode.

FRDM-KW36 Software Development Kit (SDK) includes drivers and examples of FlexCAN module for KW36 which can be easily configured for a custom communication. For example, if user want to change the default baud rate from FlexCAN driver demo examples then the only needed change is the default value on "config->baudRate" and "config->baudRateFD" from "FLEXCAN_GetDefaultConfig" function (See Figure 1). Segments within a bit time will be automatically configured to obtain the desired baud rate. By default, demos are configured to work with CAN FD communication. Figure 1. FRDM-KW36's default baudrate from flexcan_interrupt_transfer driver example Even so, there are cases where segments within a bit time are not well configured and it's necessary that user configure segments manually. An example occurs by setting the maximum FD baud rate "3.2MHz" using the 32MHz xtal or "2.6MHz" using a 26MHz xtal where demo reports an error. See Figure 2. Figure 2. Error by setting maximum baud rate When this error occurs, the fix is on setting the timing config parameters correctly by including the definition of SET_CAN_QUANTUM on application source file (see Figure 3) and then declare and initialize the timing config parameters shown in Figure 4. Figure 3. SET_CAN_QUANTUM define Figure 4. Custom timing config parameters For this example we are going to show how to calculate timing config parameters in an scenario where a CAN FD communication is used with baud rate of 500kHz on nominal phase and 3.2MHz on FD phase. See Figure 5.  To do it, we need to calculate Time Quanta and value of segments within the bit time.    Figure 5. Custom CAN FD baudrate KW36 Reference Manual in chapter "37.4.8.7 Protocol timing" shows the segments within a bit time for CAN nominal phase configured in "CAN_CTRL1" register (see Figure 6), and segments for FD phase configured in CAN_FDCBT register (see Figure 7). Figure 6. Segment within a bit time for CAN nominal phase Figure 7. Segment within a bit time for CAN FD phase Before calculating the value of segments, first we need to calculate the Time Quanta which is the atomic number of time handled by the CAN engine. The formula to calculate Time Quanta is shown in Figure 8 taken from KW36 Reference Manual. Figure 8. Time Quanta Formula CANCLK can be selected by CLKSRC bits on CAN_CTRL1 register as shown in Figure 9, where the options are Peripheral clock=20MHz or Oscillator clock (16MHz if using 32MHz xtal or 13MHz if using 26MHz xtal). The recomiendation is to use the Oscillator clock due to peripheral clock can have jitter that affect communication.  Figure 9. CAN clocks To select the Oscillator clock, search for flexcanConfig.clkSrc definition and set it to kFLEXCAN_ClkSrcOsc as shown in Figure 10. Figure 10. CANCLK selection Next step is selecting the PRESDIV value for nominal phase and FPRESDIV for FD phase. You have to select the right value to achieve the TQ needed to obtain the configured baudrate. For this example, let's set FPRESDIV value to 0 and PRESDIV value to 3. TQ calculation for nominal phase: TQ = (PRESDIV + 1) / CANCLK = (3 + 1) / 16000000 = 0.00000025 TQ calculation for FD phase: TQ = (FPRESDIV + 1) / CANCLK = (0 + 1) / 16000000 = 0.0000000625 The bit rate, which defines the rate of CAN message is given by formula shown in Figure 11 taken from KW36 Reference Manual. Figure 11. CAN Bit Time and Bit Rate Formulas With this info and with our TQ calculated, we can deduce that we need: For Nominal phase: 8 = Number of Time Quanta in 1 bit time For FD phase: 5 = Number of Time Quanta in 1 bit time Now, let's define the value of segments. For nominal phase: Bit Time =  (number of Tq in 1 bit time) x Tq CAN Bit Time = (1 + (PROPSEG + PSEG1 + 2) + (PSEG2 + 1) ) x Tq CAN Bit Time = (1 + (1 + 2  + 2) + (1 + 1) ) x Tq = 8 x 0.00000025 =  Baud rate = 1/ CAN Bit Time = 500KHz For FD phase: CAN Bit Time = (number of Tq in 1 bit time) x Tq CAN Bit Time = (1 + (FPROPSEG + FPSEG1 + 1) + (FPSEG2 + 1) ) x Tq CAN Bit Time = (1 + (0 + 1 + 1) + (1 + 1) ) x Tq = 5 x Tq =  0.0000003125 Bit Rate = 1/CAN Bit Time = 1 / 0.0000003125 =  3.2MHz To finish, just update the calculated values on your firmware on flexcanConfig.timingConfig structure.  Notes: FRDM-KW36 Software Development Kit (SDK) can be downloaded from MCUXpresso webpage. FlexCAN driver examples are located in path: "SDK_2.2.0_FRDM-KW36\boards\frdmkw36\driver_examples" from your downloaded FRDM-KW36 SDK. Take in consideration that not all the baud rates are achievables and will depend on the flexcan clock and segment values used.

By default, FRDM-KW36 board includes a 32MHz XTAL (YI) as shown in Figure 1 but there are cases where a 26MHz XTAL is needed instead of 32MHz XTAL for FRDM-KW36 or a custom KW36 board.   Figure 1. 32MHz XTAL from FRDM-KW36 schematics Wireless connectivity demos from FRDM-KW36 Sofware Development Kit are configured to run with a 32MHz XTAL by default, but it's very easy to modify the software to operate with a 26MHz XTAL. Follow next steps to configure a FRDM-KW36 wireless connectivity demo to operate with a 26MHz XTAL: 1. In clock_config.h file, change BOARD_XTAL0_CLK_HZ define from 32000000U to 26000000U as shown in Figure 2.   Figure 2. BOARD_XTAL0_CLK_HZ define in clock_config.h 2. Add RF_OSC_26MHZ=1 line in preprocessor: If using IAR IDE: Right click on your project, then click options (Figure 3). Figure 3. IAR project options Go to C/C++ Compiler tab, then Preprocessor, and add RF_OSC_26MHZ=1 line in defined symbols window (Figure 4). Figure 4. IAR Preprocessor If using MCUXpresso IDE: Right click on your project, select Properties, go to Settings under C/C++ Build, then Preprocessor under MCU C Compiler (Figure 5). Figure 5. MCUXpresso Preprocessor Click on add button from Defined symbols, write RF_OSC_26MHZ=1 and click OK to finish (Figure 6). Figure 6. MCUXpresso Defined symbols To finish, re-compile your project and it will be ready to operate with a 26MHz XTAL. FRDM-KW36 SDK can be downloaded from the MCUXpresso webpage.

General summary MCUBOOT, fsci_bootloader and otap_bootloader are 3 different bootloader applications that can be used depending on the use case. The MCU Flashloader is a separate implementation but it's also mentioned to avoid misunderstanding.   MCUBOOT The MCU bootloader provides support for multiple communication protocols (UART, SPI, I2C, CAN) and multiple applications to interface with it. Summary: - It's a configurable flash programming utility that operates over a serial connection on several Kinetis MCUs. - Host-side command line (blhost) and GUI tools are available to communicate with the bootloader.  -  By default, application starts at address 0xa000. - MCU Bootloader|NXP website - MCU Bootloader Reference Manual - MCU Bootloader Demo Application User's Guide   fsci_bootloader Framework Serial Connectivity Interface (FSCI) is an NXP propietary protocol that allows interfacing the Kinetis protocol stack with a host system or PC tool using a serial communication interface. The FSCI bootloader enables the FSCI module to communicate with the PC and transfer the image using the FSCI protocol. Summary: - It relies on the FSCI protocol to transfer the binary from a PC connected via UART, using a python and C applications. - To enter into bootloader mode (in FRDM-KW41Z), hold SW1 (Reset) and press SW4, then release SW1 first and SW4 second. Please refer to demo user's guide to get the specific steps for your platform. - By default, application starts at 0x4000. - FSCI Bootloader Manual   otap_bootloader The Connectivity SDK contains Over-the-Air firmware upgrade examples. The OTAP bootloader loads an image obtained from wireless communication, the OTAP bootloader only enters after an image was successfully transferred to the client device (internal or external flash). Summary: - It's used by over the air programmed devices. - The bootloader mode only enters if a flag is set after reset triggered by a successful reception of an image over the air. - By default, application starts at 0x4000. - Kinetis Thread Stack Over-the-Air (OTA) Firmware Update User’s Guide   mcu_flashloader The MCU flashloader is a specific implementation of the MCU bootloader. For the flashloader implementation, the MCU bootloader command interface is packaged as an executable that is loaded from flash and executed from RAM. This configuration allows the user application to be placed at the beginning of the on-chip flash where it is automatically launched upon boot from flash. Using the MCU flashloader to program a user application to the beginning of the flash makes this implementation of the bootloader a one-time programming aid. The MCU flashloader doesn't allow to jump to a different section after a timeout or button press like the other bootloaders, it's main purpose is to flash an application without the need of an external debugger, mainly used for factory programming. Summary: - It is pre-programmed into many Kinetis flash devices during manufacturing and enables flash programming without the need for a debugger. - After the user application is programmed into flash memory, the Kinetis flashloader is no longer available. - Documentation: Getting Started with the MCU Flashloader   You can select from the MCU Bootloader, FSCI_Bootloader and OTAP Bootloader, depending on your needs. JC

QTool is a PC software tool that works with QN9080 USB dongle to assist in the development of BLE projects with the QN9080. You control the dongle via the QTool software, which issues and receives FSCI (Framework Serial Communication Interface) formatted commands over a virtual COM port. The dongle can then act either as a master or a slave to a QN9080DK board over BLE.  Before using the BLE dongle with QTool though, the firmware on the QN9080 Dongle must be updated. The updated firmware can be found inside the QTool installation directory, and you will need to put the dongle into bootloader mode to drag-and-drop new firmware on it. Updating the Firmware on the QN9080 Dongle. 1. Install QTool: https://www.nxp.com/webapp/sps/download/license.jsp?colCode=Connectivity-QTool-Setup   2. Plug the QN9080 Dongle into a USB port on your computer 3. Using a wire, connect TP5 to ground. You can use either TP4 or the USB shield for GND. 4. While that wire is connected, press the reset button on the dongle. This will now put the dongle into bootloader mode. 5. A drive will enumerate on your computer named “CRP_DISABLD”     6. You can now remove the wire 7. Delete the firmware.bin file found in that drive 8. Drag-and-drop the firmware.bin file found in C:\NXP\Connectivity QTool\bin files into that enumerated drive. 9. Once done copying, unplug and replug in the USB Dongle, and the new firmware will now be running.  Installing the QN9080 Dongle Driver The dongle will enumerate as a USB CDC COM device. If the CDC driver is not automatically detected, you will need to manually install the driver. 1. Right-click Computer and choose Properties, the System Management window appears. 2. Click Device Manager and navigate to MCU VIRTUAL COM DEMO      3. Right-click the device MCU VIRTUAL COM DEMO and choose Update Driver Software 4. Click the  Browse my computer for driver software option in the window. 5. Click Browse button to go to the folder  C:\NXP\Connectivity QTool\drivers 6. Click the Next button at the bottom to install the driver.  7. After the driver is installed you will see the Virtual Com Port device under the Ports category    Using QTool: Now that the QN9080 dongle has the updated firmware and has the correct driver installed, you can follow the instructions in the QTool documentation found at C:\NXP\Connectivity QTool\UM11085.pdf Related documentation: QN908x Quick Start Guide QN908x DK User's Guide

The attached PDF file contains two A3 format "posters". The first one summarize the contents of the SMP Pairing Request and SMP Pairing Response packets (BLE 4.2). It shows how are the sub-fields of these packets set and what do they represent. The second one contains a diagram which summarizes how the pairing method and it's properties are determined during the SMP Pairing procedure for both BLE Legacy Pairing (BLE4.0 and BLE 4.1) and BLE Secure Connections Pairing with ECDH (BLE 4.2). Some of the tables in the diagram are taken from the BLE Specification. If you find any errors or have any suggestions of improvement please leave a comment or send me a message. Preview:

This patch fixes some minor issues with the Connectivity Software v1.0.2 when working with the Kinetis BLE Toolbox application for smartphones. Following issues are fixed. BLE OTAP Application: Fixes application failing to download the new image when the previous image upload has been interrupted due a disconnection. BLE Wireless UART: Fixes MTU exchange issue causing some characters not bein shown in the smartphone application in iOS and Android. Hybrid BLE + Thread console: Fixes MTU exchange issue causing some characters not bein shown in the smartphone application console in iOS and Android. Make sure the Connectivity Software version 1.0.2 is installed in your computer before proceeding to install this application.

The KW41Z has support for an external 26 MHz or 32 MHz reference oscillator. This oscillator is used, among other things, as the clock for the RF operation. This means that the oscillator plays an important role in the RF operation and must be tuned properly to meet wireless protocol standards. The KW41Z has adjustable internal load capacitors to support crystals with different load capacitance needs. For proper oscillator function, it is important that these load capacitors be adjusted such that the oscillator frequency is as close to the center frequency of the connected crystal (either 26 MHz or 32 MHz in this case). The load capacitance is adjusted via the BB_XTAL_TRIM bit field in the ANA_TRIM register of the Radio block. The KW41Z comes preprogrammed with a default load capacitance value. However, since there is variance in devices due to device tolerances, the correct load capacitance should be verified by verifying that the optimal central frequency is attained.  You will need a spectrum analyzer to verify the central frequency. To find the most accurate value for the load capacitance, it is recommended to use the Connectivity Test demo application. This post is aimed at showing you just how to do that.   In this case, the Agilent Technologies N9020A MXA Signal Analyzer was used to measure, configured with the following parameters: FREQ (central frequency): 2405 MHz (test will be conducted on channel 11) SPAN (x-axis): 100 KHz AMPTD (amplitude, y-axis): 5 dBm To perform the test, program the KW41Z with the Connectivity Test application. The project, for both IAR and KDS, for this demo application can be found in the following folder: <KW41Z_connSw_1.0.2_install_dir>\boards\frdmkw41z\wireless_examples\smac\connectivity_test\FreeRTOS NOTE:  If you need help programming this application onto your board, consult your Getting Started material for the SMAC applications.  For the FRDM-KW41Z, it is located here. Once the device is programmed, make sure the device is connected to a terminal application in your PC. When you start the application, you're greeted by this screen: Press 'ENTER' to start the application. Press '1' to select the continuous tests mode. Press '4' to start a continuous unmodulated transmission. Once the test is running, you should be able to see the unmodulated signal in the spectrum analyzer. Press 'd' and 'f' to change the XTAL trim value, thus changing the central frequency. Now, considering the test in this example is being performed in 802.15.4 channel 11, the central frequency should be centered exactly in 2.405 GHz, but on this board, it is slightly above (2.4050259 GHz) by default. In order to fix this, the XTAL trim value was adjusted to a value that moves the frequency to where it should be centered. Once the adequate XTAL trim value is found, it can be programmed to be used by default. This other post explains how to do this process.

This article will describe in detailed steps how to generate, build and test a Bluetooth low energy Heart Rate Sensor project on the FRDM-KW41Z evaluation board by using the Bluetooth Developer Studio (BDS) and the NXP Kinetis BDS Plug-in. Getting Started To use this plug-in and test its output, the following programs are required:  - Bluetooth Developer Studio v1.1.306 or newer: Bluetooth Developer Studio & Plugins | Bluetooth Technology Website   - NXP Semiconductors Kinetis Plug-in v1.0.0: Link  - Kinetis SDK 2.0 with support for MKW41Z and Bluetooth Stack version 1.2.2: Link  - Kinetis SDK 2.0 add-on for BDS (found in the same package as the plug-in)  - Kinetis BLE Toolbox Android or iOS mobile application To enable the NXP Kinetis BDS Plug-in in the Bluetooth Developer Studio, follow please the installation details in the readme.txt document included in the downloaded plug-in archive. Creating the project with BDS Create a new project by clicking FILE-> NEW PROJECT. Add project location, name and namespace as detailed below: Drag and drop an adopted Heart Rate Profile from the right hand side list. Your device should import the following services:   Next step will be to configure the GAP layer. Click on the GAP button. First tab will be the Advertising Data. Enter desired values and check which AD types you want to include in the advertising packets. A bar below will show you how much bytes your data uses. Make sure you do not use more than the 32 bytes available. Next step is to configure the GAP properties. Make sure you check at least one advertising channel and a reasonable advertising interval range, as presented below:     Click TOOLS->GENERATE CODE. Select Server as GATT side to be generated and NXP Semiconductors Kinetis v1.0.0 as the plug-in. BDS will prompt you to enter a location for the exported files. After generating the files, another window with the results log will appear. If no error messages appear, the generation is successful. Check the “Open output location when finished” box and hit the “Finish” button. A folder with the following content will open: Using the generated code Copy the contents inside the following folder:  "<SDK 2.0 installation folder>\middleware\wireless\bluetooth_1.2.2\examples\bds_template_app". To generate the “bds_template_app” embedded project and test it, follow the instructions detailed in the Bluetooth Quick Start Guide document from the SDK. Seeing the application in action Before compiling the application add the following code snippet in app.c inside BleApp_HandleKeys:         case gKBD_EventPressPB2_c:         {             mUserData.cRrIntervals = 0;             mUserData.expendedEnergy = 100;             Hrs_RecordHeartRateMeasurement(service_heart_rate, 120, &mUserData);             break;         } This will allow the board to send heart rate data of 120 bpm while in a connection and when pressing button SW3 on the FRDM-KW41Z board. The value can be seen when using Kinetis BLE Toolbox, as shown below:

The KW40Z connectivity software stack has several demo application available, and one of them is the OTAP client. This application allows the user to reprogram the device in a wireless fashion. This can be done by both using another device with an OTAP server application, or with the Kinetis BLE Toolbox mobile application, using the OTAP tool. To create a binary file for the KW40Z, follow these next steps: Using IAR Embedded Workbench, open the application you want to send through OTAP. Right click the main project, and open the Options... menu.                                                                                                                                              In the options menu, go to the Output Converter submenu. In the Output Converter submenu, check the "Generate additional output" box, and choose Motorola as the Output format.                                                                                                                                                                            In the options menu, go to the Linker submenu. Now, in the Config tab, replace the symbols in the Configuration file symbol definitions box with these: gUseNVMLink_d=1 gUseBootloaderLink_d=1 gUseInternalStorageLink_d=0 __ram_vector_table__=1                                                                                                                                                                                              In the Linker submenu, go to the Input tab. In the Keep symbols box, add the symbol 'bootloader' (without the quotes). In the Input tab, in the Raw binary image box, in the File option, add the following path: $PROJ_DIR$\..\..\..\..\..\..\..\framework\Bootloader\Bin\BootloaderOTAP_KW40Z4.bin In the Raw binary image box, add the following options to the Symbol, Section and Align boxes: Symbol: bootloader Section: .bootloader Align: 4                                                                                                                                                                                                                         Press OK. Compile the project. The output file (*.srec) should be in the main project folder, inside the debug folder.                                                      You can now use this binary file to reprogram your device with OTAP.

Our customer, who is considering MKW40, is asking NXP regarding max input voltage of PSWITCH and DCDC_CFG pins. Especially they plan to use buck mode with input voltage 4.2[v] as shown below. Would you comment if max voltage of PSWITCH and DCDC_CFG pins is 4.2[v] as well as DCDC_IN pin? Regards, Koichi

Our customer is evaluating RF characteristics using FRDM-MKW24. Regarding Tx max power, they have one question. The spec of max tx power is +8dBm and I could verify the power using TWR-KW24d512 before. They observed tx power with tx un-modulated cnt transmission and informed that the power was about +2dBm. That is to say, "Power 31" in Connectivity_Test means to +2dBm. I feel that it is small... Would you comment regarding the spec of the max tx power on FRDM-MKW24? Regards, Koichi

Hello community, This time I bring to you a document which explains how easy is to add a new endpoint and a new cluster to a ZigBee device in the BeeStack in BeeKit. This document is based in the MC1323x MCUs but the procedure applies to the Kinetis devices. Before to start you need to install the BeeKit Wireless Connectivity Toolkit​. If you are interested about what an endpoint is, the document ZigBee Endpoints Reserved could be useful for you. I hope you find this guide useful. Enjoy this guide, enjoy ZigBee! Any feedback is welcome. Best regards, Earl Orlando Ramírez-Sánchez Technical Support Engineer NXP Semiconductors

What is a BLE Beacon? A BLE Beacon is a hardware including a MCU, a BLE radio, an antenna and a power source. Things like Freescale Beacon, iBeacon, AltBeacon or Eddystone are software protocols with their own characteristics. How it works? A BLE Beacon is a non-connectable device that uses Bluetooth Low Energy (BLE or Bluetooth Smart) to broadcast packets that include identifying information and each packet receives the name of Advertising Packet. The packet structure and the information broadcasted by a Beacon depend on the protocol, but, the basic structure is conformed by: UUID. This is a unique identifier that allows identifying a beacon or a group of beacons from other ones. Major number. Used to identify a group of beacons that share a UUID. Minor number. Used to identify a specific beacon that share UUID and Major number. Example UUID Major Minor AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA 1 1 These Beacons share the same UUID and Major number, and are differentiated by Minor number. AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA 1 2 AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA 2 1 This Beacon shares the same UUID as the previous ones, but has a different Major number, so it belongs to a different group. BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB 1 1 This Beacon is completely different from the previous ones, since it doesn’t share the same UUID. These packets need to be translated or interpreted in order to provide the beacon a utility. There are applications that can interact with beacons, usually developed to be used with smartphones and/or tablets. These applications require being compliant with the protocol used by the beacon in order to be able to perform an action when a beacon is found. Use Cases Beacons can be used on different places to display different content or perform different actions, like: Restaurants, Coffee Shops, Bars Virtual Menu Detailed information Food source Suggested wine pairings Museums Contextual information. Analytics Venue check-in (entry tickets) Self-guided tours. Educational excursions Event Management and Trade Shows Frictionless Registration Improved Networking Sponsorship Navigation and Heat Mapping Content Delivery Auto Check-in Stadiums Seat finding and seat upgrading Knowing the crowded locations Promotions, offers and loyalty programs Sell Merchandise Future implementations Retail and Malls Shopping with digital treasure hunts Gather digital up-votes and down-votes from visitors Allow retailers to join forces when it comes to geo-targeted offers Use time-sensitive deal to entice new shoppers to walk in Help in navigation Engage your customers with a unified mall experience.

Commissioner Authentication server for new Thread devices and the authorizer for providing the network credentials they require to join the network. A device capable of being elected as a Commissioner is called a Commissioner Candidate. Devices without Thread interfaces may perform this role, but those that have them may combine this role with all other roles except the Joiner. This device may be, for example, a cell phone or a server in the cloud, and typically provides the interface by which a human administrator manages joining a new device to the Thread Network. Commissioner Candidate A device that is capable of becoming the Commissioner, and either intends or is currently petitioning the Leader to become the Commissioner, but has not yet been formally assigned the role of Commissioner. Commissioner Credential A human-scaled passphrase for use in authenticating that a device may petition to become the commissioner of the network. This credential can be thought of as the network administrator password for a Thread Network. The first device in a network, typically the initial Leader, MUST be out-of-band commissioned to inject the correct user generated Commissioning Credential into the Thread Network, or provide a known default Commissioning Credential to be changed later. Joiner A device to be added by a human administrator to a commissioned Thread Network. This role requires a Thread interface to perform and cannot be combined with another role in one device. The Joiner does not have network credentials. Joiner Router An existing Thread router or REED (Router-Eligible End Device) on the secure Thread Network that is one radio hop away from the Joiner. The Joiner Router requires a Thread interface to operate, and may be combined in any device with other roles except the Joiner role. Information extracted from the Thread Whitepapers available at threadgroup.org

The connectivity software is an add-on of the Kinetis SDK, therefore the demos are referenced to a KSDK path variable named "KSDK_PATH" in IAR. The KSDK_PATH variable contains the path of the installation folder for the KSDK version in your PC. Taking as an example the MRB-KW01 SMAC Connectivity Software, we can realize that this variable is used to reference for libraries. In particular, this SMAC software for the MRB-KW01 works with KSDK 1.2, that is why you could have troubles if the variable is referenced to another KSDK version (for example KSDK 1.1). Follow the next steps to modify the KSDK_PATH variable in your computer: 1. Right click on "computer", then click "properties" 2. A Control Panel window will be opened. Click on "Advanced system settings" 3. A system Properties windows will be opened. Select the "Advanced" tab, then click "Environment Variables". 4. Select the KSDK_PATH variable and assure that it stores the correct path needed for your project. In case that you need to modify the variable, then click "Edit" 5. Finally click "Ok" to close all tabs and you will be able to run your connectivity software without problems. Best regards, Luis Burgos.

Certification is the process of testing radio hardware to demonstrate that it meets the stated regulations in the country that it will operate in. A certification is needed generally when electronic hardware will be sold in a country, the certification requirements of that country must be met. If you require changes in your certificated hardware that will affects your RF performance, then you need to re-certificate the device. Most common regions and certification's institutes are (it applies for 2.4GHz & SubGHz): FCC for USA IC for Canada ETSI (CE) for Europe ARIB for Japan Other countries generally follow FCC or ETSI standars. The institute in charge of certifications depends on the region. It's the same institute to certificate your device in 2.4GHz or SubGHz in a certain region, the only difference are the articles of each institute to operate in the different frequencies. For operating in the 2.4GHZ band (worldwide): - In the U.S, CFR 47 FCC Part 15 203, 15.209 and 15.247 - In Canada, IC RSS-210 which closely follows FCC Part 15 - In EU, ETSI EN 300, 301 - In Japan, ARIB STD-T66 For SubGHz depends on the frequency you want to operate in. Taking Japan as an example: In Japan you can operate in the 920MHz band or in the 400MHz band for SubGHz. For both frequencies, ARIB is the institute in charge of the certifications but to operate in the 400MHz band the article that you will need is the ARIB STD-T67, and to operate in the 920MHz you will need to certificate your hardware with ARIB STD-T108 article. Freescale's MRB-KW019032 is certificated to operate in the following SubGHz ISM bands: The firmware used to certificate our KW products is the Radio Utility or the Connectivity Test, it allows the user in changing some RF parameters needed to pass the certification process. If you are thinking in certificate a product, contact an expert! There are Telecommunication Certification Body (TCB) companies which can give you guidance in the processes you need to follow to achieve a certification. To know more about FCC certification requirements and processes, refer to the reference manual “Freescale IEEE 802.15.4 / ZigBee Node RF Evaluation and Test Guidelines” in the Freescale's website. Best regards, Burgos. This document was generated from the following discussion: Certifications

Thread is a secure, wireless, simplified IPv6-based mesh networking protocol developed by industry leading technology companies, including Freescale, for connecting devices to each other, to the internet and to the cloud. Before starting a Thread Network implementation, users should be familiar with some concepts and how they are related to Thread protocol. IPv6 Addressing Devices in the Thread stack support IPv6 addressing IPv6 addresses are 128-bit identifiers (IPv4 is only 32-bit) for interfaces and sets of interfaces.  Thread supports the following types of addresses: Unicast:  An identifier for a single interface.  A packet sent to a unicast address is delivered to the interface identified by that address. Multicast: An identifier for a set of interfaces (typically belonging to different nodes).  A packet sent to a multicast address is delivered to all interfaces identified by that address. NOTES There are no broadcast addresses in IPv6, their function being superseded by multicast addresses. Each device joining the Thread Network is also assigned a 16-bit short address as specified in IEEE 802.15.4. 6LoWPAN All Thread devices use 6LoWPAN 6LoWPAN stands for “IPv6 over Low Power Wireless Personal Networks”. 6LoWPAN is a set of standards defined by the Internet Engineering Task Force (IETF), which enables the efficient use of IPv6 over low-power, low-rate wireless networks on simple embedded devices through an adaptation layer and the optimization of related protocols. Its main goal is to send/receive IPv6 packets over 802.15.4 links. Next figure compares IP and 6LoWPAN protocol stacks: The following concepts would explain the transport layer. ICMP Thread devices support the ICMPv6 (Internet Control Message Protocol version 6) protocol and ICMPv6 error messages, as well as the echo request and echo reply messages. The Internet Control Message Protocol (ICMP) is an error reporting and diagnostic utility and is considered a required part of any IP implementation. ICMPs are used by routers, intermediary devices, or hosts to communicate updates or error information to other routers, intermediary devices, or hosts. For instance, ICMPv6 is used by IPv6 nodes to report errors encountered in processing packets, and to perform other internet-layer functions, such as diagnostics. ICMP differs from transport protocols such as TCP and UDP in that it is not typically used to exchange data between systems, nor is it regularly employed by end-user network applications.  The ICMPv6 messages have the following general format: The type field indicates the type of the message.  Its value determines the format of the remaining data. The code field depends on the message type.  It is used to create an additional level of message granularity. The checksum field is used to detect data corruption in the ICMPv6 message and parts of the IPv6 header. ICMPv6 messages are grouped into two classes: error messages and informational messages.  Error messages are identified as such by a zero in the high-order bit of their message Type field values.  Thus,   error messages have message types from 0 to 127; informational messages have message types from 128 to 255. UDP The Thread stack supports UDP for messaging between devices. This User Datagram Protocol  (UDP)  is defined  to  make available  a datagram   mode of  packet-switched   computer communication  in  the environment  of an  interconnected  set  of  computer  networks, assuming that the Internet  Protocol (IP) is used as the underlying protocol. With UDP, applications can send data messages to other hosts on an IP network without prior communications to set up special transmission channels or data paths. UDP is suitable for purposes where error checking and correction is either not necessary or is performed in the application, avoiding the overhead of such processing at the network interface level. The UDP format is as follows: Source Port is an optional field, when meaningful, it indicates the port of the sending  process,  and may be assumed  to be the port  to which a reply should be addressed  in the absence of any other information.  If not used, a value of zero is inserted. Destination Port has a meaning within the context of a particular internet destination address. Length is the length in octets of this user datagram including this header and the data.   (This means the minimum value of the length is eight.) Checksum is the 16-bit one's complement of the one's complement sum of a pseudo header of information from the IP header, the UDP header, and the data, padded  with zero octets at the end (if  necessary)  to  make  a multiple of two octets. References White papers available at http://threadgroup.org/ “6LoWPAN: The Wireless Embedded Internet” by Zach Shelby and Carsten Bromann RFC 4291, RFC 4944, RFC 4443 and RFC 768 from https://www.ietf.org

The image below shows the different types of devices in a Thread Network. Router Routers provide routing services to network devices. Routers also provide joining and security services for devices trying to join the network. Routers are not designed to sleep. Routers can downgrade their functionality and become REEDs (Router-eligible End Devices). A Router can become a Leader and start a Thread network. Border Router A Border Router is a type of Router that provides connectivity from the 802.15.4 network to adjacent networks on other physical layers (for example, Wi-Fi and Ethernet). Border Routers provide services for devices within the 802.15.4 network, including routing services for off-network operations. There may be one or more Border Routers in a Thread Network. The Border Router also serves as an interface point for the Commissioner when the Commissioner is on a non-Thread Network; it requires a Thread interface and may be combined in any device with other Thread roles except the Joiner. Leader A Router or Border Router can assume a Leader role for certain functions in the Thread Network. This Leader is required to make decisions within the network. For example, the Leader assigns Router addresses and allows new Router requests. The Leader role is elected and if the Leader fails, another Router or Border Router assumes the Leader role. It is this autonomous operation that ensures there is no single point of failure. Router-eligible End Device REEDs have the capability to become Routers but due to the network topology or conditions these devices are not acting as Routers. These devices do not generally forward messages or provide joining or security services for other devices in the Thread Network. The Thread Network manages REEDs becoming Routers if necessary without user interaction. Sleepy End Device Sleepy end devices are host devices. They communicate only through their Parent Router and cannot forward messages for other devices References: Thread Whitepapers available at http://threadgroup.org