With the release of the Bluetooth LE core erratum 10734, two new Host test cases (SM/SLA/KDU/BI-01-C and SM/MAS/KDU/BI-01-C) were added to the Test Case Reference List (TCRL) and are active since 24-Jan-19. This has an impact on new product qualifications based on Component (Tested) QDIDs that used an older TCRL when the test cases for this erratum were not required. Products that rely on NXP HOST QDIDs have 2 options for covering the erratum 10734 in order to complete the qualification: NXP provides a new qualification/QDID that includes these 2 tests. This is scheduled for later this year for QN908x, KW35/36 and KW41/31 products. NXP provides the test evidence/logs for these 2 tests and the test house reviews them before completing the product qualification. Right now, option 2 can be followed using the test evidence/logs provided by NXP. Later in the year, option 1 can be followed with an updated QDID. To obtain the test evidence/logs, please submit a support request.

During last week I receive a question about identify a way to notice when the 32kHz oscillator is ready to be able to use it as clock source. In other words, when the 32kHz oscillator is stable to be used as reference clock for the MCG module. Then, system can switch over it. Kinetis devices starts up using its internal clock which is called FEI mode, then, the applications change to a different mode which require an external clock source (i.e. FEE mode). Normally, we have two options which are: Main reference clock. Talking specifically to KW devices, there is the 32MHz external crystal for the main reference clock. The 32kHz external crystal for the 32kHz oscillator which is driven through the RTC registers.  For the first option, there is a register which could be monitored to know when oscillator is ready (RSIM_CONTROL_RF_OSC_READY). So, it can be polled to notice when the oscillator is up and ready.  About the second option, there is no “OSCINIT” bit for the 32 kHz oscillator. However, there is a way to know when the 32kHz Oscillator is running, it is to simply enable the RTC OSC, and configure the RTC to count. After doing that immediately poll (read) the RTC_TPR register and check it until it is greater than 4096. It will roll over once it reaches 32767 so, it is important to the poll this register in a loop doing nothing else or the register could potentially be read when it is less than 4096 but had already rolled over. Once it is greater than 4096, it can be determined that oscillator is running well. If the RTC is not required, the counter can be disabled. Now that the 32kHz clock is available, the application can switch to FEE mode. So, in order to perform the above description, I modified the “CLOCK_CONFIG_EnableRtcOsc()” as shown next: static void CLOCK_CONFIG_EnableRtcOsc(uint32_t capLoad) {        rtc_config_t rtc_basic_config;        uint32_t u32cTPR_counter=0;        /* RTC clock gate enable */     CLOCK_EnableClock(kCLOCK_Rtc0);     if ((RTC->CR & RTC_CR_OSCE_MASK) == 0u)     {       /* Only if the Rtc oscillator is not already enabled */       /* Set the specified capacitor configuration for the RTC oscillator, "capLoad" parameter shall be set          to the value specific to the customer board requirement*/       RTC_SetOscCapLoad(RTC, capLoad);          /*Init the RTC with default configuration*/       RTC_GetDefaultConfig(&rtc_basic_config);       RTC_Init(RTC, &rtc_basic_config);       /* Enable the RTC 32KHz oscillator */       RTC->CR |= RTC_CR_OSCE_MASK;       /* Start the RTC time counter */       RTC_StartTimer(RTC);             /* Verify TPR register reaches 4096 counts */       while(u32cTPR_counter < 4096)       {          u32cTPR_counter= RTC->TPR;       }       /* 32kHz Oscillator is ready. Based on the application requirements, it can let the RTC enabled or disabled.           In this case, we can disable RTC since it is not needed by this application */       RTC_Deinit(RTC);     }     /* RTC clock gate disable  since RTC is not needed anymore*/     CLOCK_DisableClock(kCLOCK_Rtc0); }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Then, using the above function, it can be noticed when the 32kHz oscillator is ready to be used. Hope this helps....

OVERVIEW This document shows how to include the PowerLib to enable low power functionality in connectivity software projects that does not include it. It shows step by step instructions on how to import, configure and use this module. ADD POWER LIBRARY INTO A NEW PROJECT Once you have installed the “Connectivity Software” package, browse for the extracted files (typically located in C:\Freescale\KW40Z_Connectivity_Software_1.0.0). In this location search for the LowPower folder, then copy and paste it into your new project folder. Open your IAR project and create a new group called “Low Power”. Inside this group add two new groups called “Interface” and “Source”. In the Windows explorer, open the LowPower folder copied in the previous step. Drag and drop the contents of the "Interface" folder to the "Interface" group in IAR. Do the same for the "Source" folder. You can also use the option "Add Files" in the group menu to add the files. Note: Do not copy the “PWR_Platform.c” and “PWR_Platform.h” files. Once you have copied the files in their respective folders, you need to add the paths of these files in the project environment. Right click on the project name and select "Options". In Options go to “C/C++Compiler”, select “Preprocessor” and click on the red square. The next window will appear. Click on <Click to add>  to open the windows explorer. Navigate to the folder PowerLib/Interface in your project to add the "Interface" folder path. Repeat this step with the "Source" folder. HOW TO CONFIGURE LOW POWER To use low power in your project you need to define the following macros in the “app_preinclude.h” file: /* Enable/Disable PowerDown functionality in PwrLib */ #define cPWR_UsePowerDownMode           1 /* Enable/Disable BLE Link Layer DSM */ #define cPWR_BLE_LL_Enable              1 /* Default Deep Sleep Mode*/ #define cPWR_DeepSleepMode              4 cPWR_UsePowerDownMode enables the necessary functions to use low power in your project. cPWR_BLE_LL_Enable configures the link layer to work in doze mode when in low power, and cPWR-DeepSleepMode defines the deep sleep mode the MCU will enter when the low power function is executed. There are the six different modes that can be used.   Mode 1: MCU/Radio low power modes:         MCU in LLS3 mode.         BLE_LL in DSM.       Wakeup sources:       GPIO (push button) interrupt using LLWU module.        BLE_LL wake up interrupt(BLE_LL reference clock reaches wake up instance register)  using LLWU module.              - BTE_LL wakeup timeout: controlled by the BLE stack(SoC must be awake before next BLE action).              - BTE_LL reference clock source:   32Khz oscillator              - BTE_LL reference clock resolution:     625us                            Mode 2: MCU/Radio low power modes:         MCU in LLS3 mode.         BLE_LL in DSM.       Wakeup sources:         GPIO (push button) interrupt using LLWU module.         BLE_LL wake up interrupt(BLE_LL reference clock reaches wake up instance register)  using LLWU module.                - BTE_LL wakeup timeout: cPWR_DeepSleepDurationMs by default. Use PWR_SetDeepSleepTimeInMs  to change it at run time. Maximum timeout is 40959 ms. BLE suppose to be idle.                - BTE_LL reference clock source:   32Khz oscillator                - BTE_LL reference clock resolution:     625us   Mode  3: MCU/Radio low power modes:         MCU in LLS3 mode.         BLE_LL in idle.       Wakeup sources:        GPIO (push button) interrupt using LLWU module.        DCDC PowerSwitch - available in buck mode only.        LPTMR interrupt using LLWU module           - LPTMR wakeup timeout: cPWR_DeepSleepDurationMs by default. Use PWR_SetDeepSleepTimeInMs to change it at run time. Maximum timeout is 65535000 ms (18.2 h).           - LPTMR clock source:   32Khz oscillator           - LPTMR resolution:     modified at run time to meet timeout value. Mode 4: MCU/Radio low power modes:         MCU in VLLS0/1 mode(VLLS0 if DCDC bypassed/ VLLS1 otherwise ).        BLE_LL in idle.       Wakeup sources:        GPIO (push button) interrupt using LLWU module.         DCDC PowerSwitch - available in buck mode only. Mode 5: MCU/Radio low power modes:        MCU in VLLS2 (4k Ram retention (0x20000000- 0x20000fff)).        BLE_LL in idle.       Wakeup sources:         GPIO (push button) interrupt using LLWU module.         DCDC PowerSwitch - available in buck mode only.   Mode 6: MCU/Radio low power modes:         MCU in STOP.       Wakeup sources:         GPIO (push button) interrupt using LLWU module.         DCDC PowerSwitch - available in buck mode only.         LPTMR wakeup timeout: cPWR_DeepSleepDurationMs by default. Use PWR_SetDeepSleepTimeInMs to change it at run time. Maximum timeout is 65535000 ms (18.2 h).          - LPTMR clock source:   32Khz oscillator           - LPTMR resolution:     modified at run time to meet timeout value.           - LPTMR resolution:     modified at run time to meet timeout value.         Radio interrupt LL or 802.15.4         UART Configuring Wakeup Source The PowerLib software includes preconfigured wakeup methods for low power. These methods are described below and a couple of examples are included. From Reset: Comming from Reset From PSwitch_UART: Wakeup by UART interrupt From KeyBoard: Wakeup by TSI/Push button interrupt From LPTMR: Wakeup by LPTMR timer interrupt From Radio:  Wakeup by RTC timer interrupt From BLE_LLTimer:  Wakeup by BLE_LL Timer DeepSleepTimeout:  DeepSleep timer overflow. SleepTimeout: Sleep timer overflow. Configure Module Wakeup using LPTMR This example explains how to configure the third deep sleep mode using the LPTMR as wakeup source. The desired low power mode must be configured in the file app_preinclude.h. /* Default Deep Sleep Mode*/ #define cPWR_DeepSleepMode            3 On the same file, the macro cPWR_DeepSleepDurationMs macro must be added. It defines the time the MCU will be in low power mode before being waken by the low power timer. By default it it set to 10 seconds (10000 milliseconds). #define cPWR_DeepSleepDurationMs     10000 This defines the time that the device will remain asleep by default. The PWR_SetDeepSleepTimeInMs function can be used to change this period at run time. Consider that the maximum time period is 65535000 ms (18.2 hours). PWR_SetDeepSleepTimeInMs(10000); Also the deep sleep mode can be changed at run time with the following function. PWR_ChangeDeepSleepMode(3); For further power reduction, all the modules not in use must be turned off . To run in this mode, all the timers except the LPTMR must be turned off. The device enters in low power mode with the following code lines in the main application. PWR_SetDeepSleepTimeInMs(cPWR_DeepSleepDurationMs); PWR_ChangeDeepSleepMode(3); PWR_AllowDeviceToSleep(); Configure GPIO (Push Button) wakeup. In the “PWRLib.c” file, find the “PWRLib_Init” function. It contains the code to initialize the LLWU pins to be used for wakeup. Chip configuration Reference Manual chapter contains information on which LLWU pins are tied to GPIOs on the MCU. For this example LLWU pins 6 and 7 (which are tied to PTA18 and PTA19 in the MCU) are used.   LLWU_PE1 = 0x00;   LLWU_PE2 = LLWU_PE2_WUPE7(0x03) | LLWU_PE2_WUPE6(0x03);   LLWU_PE3 = 0x00;   LLWU_PE4 = 0x00; Since the LLWU pin sources work as GPIO interrupts, the propper ports in the MCU must be configured. Following code shows howthese pins are configured in the MCU.   /* PORTA_PCR18: ISF=0,MUX=1 */   PORTA_PCR18 = (uint32_t)((PORTA_PCR18 & (uint32_t)~(uint32_t)(                                                                 PORT_PCR_ISF_MASK |                                                                   PORT_PCR_MUX(0x06)                                                                     )) | (uint32_t)(                                                                                     PORT_PCR_MUX(0x01)                                                                                       ));   PORTA_PCR19 = (uint32_t)((PORTA_PCR19 & (uint32_t)~(uint32_t)(                                                                 PORT_PCR_ISF_MASK |                                                                   PORT_PCR_MUX(0x06)                                                                     )) | (uint32_t)(                                                                                     PORT_PCR_MUX(0x01)                                                                                       )); Once the pins have been defined, it is neccesary to configure them as Keyboard inputs for the Power Lib. Go to "PWRLib.h" and find the next define: #define  gPWRLib_LLWU_KeyboardFlagMask_c (gPWRLib_LLWU_WakeupPin_PTA18_c | gPWRLib_LLWU_WakeupPin_PTA19_c ) In this define you must place the pins that were configured previously as wakeup sources. Using Low Power in the Project When you define "cPWR_UsePowerDownMode"  in app_preinclude.h, it automatically creates a task in "ApplMain.c" called "App_Idle_Task". When executed by the OS scheduler, this task verifies if the device can go to sleep. This statement is always false unless the next function is called. PWR_AllowDeviceToSleep(); This function indicates the program that the device can enter in low power and will execute the neccesary code to enter in the power mode configured at that time. Note: Before you allow the device to sleep, disable all uneccessary modules and turn off all leds. When the device is ready to enter in low power (all the application layers allows it and the device is in an iddle state) function PWR_EnterLowPower() must be called. This function will enter the MCU into the selected low power mode. On the HID example this is done into the iddle task as shown below. #if (cPWR_UsePowerDownMode) static void App_Idle(void) {     PWRLib_WakeupReason_t wakeupReason;         if( PWR_CheckIfDeviceCanGoToSleep() )     {         /* Enter Low Power */         wakeupReason = PWR_EnterLowPower(); #if gFSCI_IncludeLpmCommands_c         /* Send Wake Up indication to FSCI */         FSCI_SendWakeUpIndication(); #endif #if gKeyBoardSupported_d              /* Woke up on Keyboard Press */         if(wakeupReason.Bits.FromKeyBoard)         {             KBD_SwitchPressedOnWakeUp();             PWR_DisallowDeviceToSleep();         } #endif                  if(wakeupReason.Bits.DeepSleepTimeout)         {           Led1On();           for(;;)           {}         }     } } #endif /* cPWR_UsePowerDownMode */ PWR_CheckIfDeviceCanGoToSleep() function checks that all the application layers are agree on entering in low power mode (checking that PWR_DisallowDeviceToSleep() function hasn't been called). If everything is ok, function PWR_EnterLowPower() enters the device in low power and waits for a wakeup event.

As know, FSK and OOK are the modulation types that can be configured in the radio by setting the bits 4-3 from the RegDataModul register, as shown in below picture taken from Reference Manual:                                                          A common inquire you could have is: what modulation should I use? Let's first understand how these modulations work. FSK: Frequency Shift Keying is a modulation type that uses two frequencies, for 0 and 1. In a spectrum analyzer we can see a spectrum similar to the next picture, where the frequency for 0's is separated from the central frequency with FDev, and same case for the frequency for the 1's: OOK: On Off Keying is a modulation type that represents a logic 1 with the presence of the carrier frequency and a logic 0 with the absence of it. In a spectrum analyzer we can see a spectrum similar to the next picture, where the central frequency represents a logic 1. We can not see a logic 0 in the spectrum due to it's represented as the absence of power. Then what modulation should I use? FSK is most commonly used because is more spectral efficient so has better sensitivity. In the other hand, OOK modulation is commonly used in applications where the frequency accuracy can not be guaranteed. It also helps in conserving battery power due to the power absence for the logic 0's. Regards, Luis Burgos.

This document describes the implementation of the Connected Home Gateway for the Internet of Things (IoT) and its controller implemented in a Smart device (tablet) running Android OS. The gateway is intended to serve as a communication bridge between WiFi/Ethernet and ZigBee Protocol, making every ZigBee-enabled device accessible and controllable from any smart device with Wi-Fi capabilities such as a smart phone or tablet. This will remove the need of having a ZigBee transceiver in every mobile device attempting to control the house appliances. In general, users will be able to: Remote control of Home Appliances using ZigBee protocol Any WiFi-enabled device could control the appliances without a ZigBee transceiver Achieve bi-directional communication between users and appliances Real system implementation would require a powerful MCU to manage all WiFi/Ethernet communication and a second MCU to manage all ZigBee communications. The Kinetis K60 and KW24 were selected among the different options available.

This video shows how to load the Open SDA software from PE micro to the TWR-KW2x in order to debug applications using USB port and without needing external JTAG debuggers. Required downloads: TWR-KW2x Board Support Package:Kinetis KW2x Tower System Modules|Freescale PE Micro - Open SDA: P&E Microcomputer Systems

This document describes the Persistent Data Manager (PDM) module which handles the storage of stack context data and application data in Non-Volatile Memory (NVM). For the KW41Z devices, this memory is internal Flash and this document will therefore refer to Flash. Tip: In this document, a cold start refers to either a first-time start or a re-start without memory (RAM) held. A warm start refers to a re-start with memory held (for example following sleep with memory held). 1.    Overview If the data needed for the operation of a network node is stored only in on-chip RAM, this data is maintained in memory only while the node is powered and will be lost during an interruption to the power supply (e.g. power failure or battery replacement). This data includes context data for the network stack and application data. In order for the node to recover from a power interruption with continuity of service, provision must be made for storing essential operational data in Non-Volatile Memory (NVM), such as Flash. This data can then be recovered during a re-boot following power loss, allowing the node to resume its role in the network. The storage and recovery of operational data in KW41Z Flash can be handled using the Persistent Data Manager (PDM) module, as described in the rest of this document, which covers the following topics: Initializing the PDM module - see Section 2 Managing data in Flash - see Section 3 PDM features like record searching by record ID – see Section 4 The PDM can be used with ZigBee PRO and IEEE802.15.4 wireless networking protocols. 2.    Initializing the PDM and Building a File System Using the Kinetis NVM framework requires that the user must register the necessary data sets for NVM writing. This is done by calling function NVM_RegisterDataSet(). This function registers the given data set to be written in the NVM_TABLE section from Flash. The PDM module must be initialized by the application following a cold or warm start, irrespective of the PDM functionality used (e.g. context data storage or counter implementation). PDM initialization is performed using the function PDM_eInitialise(). This function requires the following information to be specified: The number of Flash sectors to be used by PDM (a zero value means use all segments) Once the PDM_eInitialise() function has been called, the PDM module builds a file system in RAM containing information about the sectors that it manages in Flash. The PDM reads the header data from each Flash sector and builds the file system. Application records are grouped and initialized in function InitAplRecords(), while network stack records are grouped and initialized in function InitNwkRecords(). For ZigBee PRO, the PDM is used in its most general form, as described above. 3.    Managing Data in Flash This section describes use of the PDM module to persist data in Flash in order to provide continuity of service when the KW41Z device resumes operation after a cold start or a warm start without memory held. Data is stored in Flash in terms of ‘records’. A record occupies at least one Flash sector but may be larger than a sector and occupy multiple sectors. Any number of records of different lengths can be created, provided that they do not exceed the Flash capacity. The records are created automatically for stack context data and by the application (as indicated in Section 3.1) for application data. Each record is identified by a unique 16-bit value which is assigned when the record is created - for application data, this identifier is user-defined. The stack context data which is stored in Flash includes the following: Application layer data: AIB members, such as the EPID and ZDO state Group Address table Binding table Application key-pair descriptor Trust Centre device table Network layer data: NIB members, such as PAN ID and radio channel Neighbor table Network keys Address Map table On performing a KW41Z cold start or warm start without RAM held, the PDM must be initialized in the application as described in Section 2. If this is the first ever cold start, there will be no stack context data or application data preserved in the Flash. If it is a cold or warm start following previous use (such as after a reset), there should be stack context data and application data preserved in the Flash. On start-up, the PDM builds a file system in RAM and scans the Flash for valid data. If any data is found, it is incorporated in the file system. Saving and recovering application data in Flash are described in the subsections below. 3.1   Saving Data to Flash       Application data and stack context data are saved from RAM to Flash as described below.       Note: During a data save, if the Flash needs to be defragmented and purged, this will be performed automatically resulting in all records being re-saved.     Application data           You should save application data to Flash when important changes have been made to the data in RAM. Application data in RAM can be saved to an individual record           in Flash using the function PDM_eSaveRecordData(). A buffer of data in RAM is saved to a single record in Flash (a record may span multiple Flash sectors).          The records are created when calling PDM_eInitialise(). These records are traced by a unique 16-bit identifier assigned by the application - this identifier is subsequently          used to reference the record. The value used must not clash with those used by the NXP libraries - the ZigBee PRO stack libraries use values above 0x8000.          Subsequently, in performing a re-save to the same record (specified by its 16-bit identifier), the original Flash sectors associated with the record will be overwritten but          only the sector(s) containing data changes will be altered (if no data has changed, no write will be performed). This method of only making incremental saves improves          the occupancy level of the size-restricted Flash.     Stack Context Data          The NXP ZigBee PRO stack automatically saves its own context data from RAM to Flash when certain data items change. This data will not be encrypted. 3.2   Recovering Data from Flash       Application data and stack context data are loaded from the Flash to RAM as described below.     Application Data             During a cold start or a warm start without memory held, once the PDM module has been initialized (see Section 2.2), PDM_eReadDataFromRecord() must be called             for each record of application data in Flash that needs to be copied to RAM.     Stack Context Data             The function PDM_eReadDataFromRecord(), described above, is not used for records of stack context data. Loading this data from the Flash to RAM is handled             automatically by the stack (provided that the PDM has been initialized). 3.3   Deleting Data in Flash         All records (application data and stack context data) in the Flash can be deleted using the function PDM_vDeleteAllDataRecords().          Caution: You are not recommended to delete records of ZigBee PRO stack context data by calling PDM_vDeleteAllDataRecords() before a rejoin of the same secured          network. If these records are deleted, data sent by the node after the rejoin will be rejected by the destination node since the frame counter has been reset on the source          node. For more information and advice, refer to the “Application Design Notes” appendix in the ZigBee 3.0 Stack User Guide. 4.    PDM Features PDM offers a function that can be used to search for a specific record by using the 16-bit record ID. This function is called PDM_GetNVMTableEntry() and the required parameters are the record ID and an output pointer for the found entry. Another available PDM feature is providing a mechanism to safely write the data to NVM. This is done by calling the function PDM_vCompletePendingOperations(), which calls the appropriate NVM function that is used to complete all writings to NVM before any other operation. As an example, user can use this function to make sure that the data is written to the NVM before a reset.

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-340508

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

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.

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-332703

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-340993

When having several ZigBee Networks in the same area, and therefore several potential parents, it may become necessary to join one of them and discard the rest. While having a mechanism to only accept joining devices when desired is the best method (like using a button to trigger the joining), it might not always be possible since the parent nodes could be commercial devices or another vendor’s product without this feature. Below are some mechanisms that could be used for this purpose. In general, when searching for suitable parents, the process is as follows: ZDO of device to join sends a MAC scan request. The MAC layer starts scan. For every beacon it receives, it sends a beacon notify indication that is processed in ParseBeaconNotifincaiton() function from AppStackImpl.c The ParseBeaconNotifincaiton() function will add the relevant information in the discovery table and for this it needs a free entry, so it calls GetFreeEntryInDiscoveryTable() function with reuse parameter as FALSE. If the table is full, it will call GetFreeEntryInDiscoveryTable() with reuse set to TRUE to literally re-use low priority entries. When the MAC scan has finished, it will send a MAC scan confirm. When this reaches ZDO, the SearchForSuitableParent() function is called. At this point, there are several approaches that could be used: Use a specific Extended PAN ID to search only for a specific parent node Use a specific PAN ID to prioritize the network’s ID Search in a specific Channel where network is supposed to be operating in All these parameters are configurable in ApplicationConf.h file of the project’s Configure Folder and used in SearchForSuitableParent() function to filter Discovery table entries. Nevertheless, those solutions are not always the best for all applications since it may require hard-coding the network’s parameters. Fortunately, BeeStack leaves all this open for any modification in case it is necessary. In brief, if the discovery table gets full with suitable parents that you DO NOT want to use, you should update the "if(reuse)" statement of the GetFreeEntryInDiscoveryTable() function to replace an entry. In other words, if you think that the desired parent is not present in the discovery table (due to its size limitation or other reason), you should update the GetFreeEntryInDiscoveryTable() function to make sure discovery table contains only devices that are of interest to your node. Please note that the criteria used to select the desired parents is totally application specific. As mentioned, it is always best having a way to trigger the joining such as a button so the rest of parents have permit join set to FALSE and therefore join only to the desired parent without having to implement custom code. Anyway, you may select the solution that meets your application’s requirements the most.

Introduction This post guides you on migrating from MKW36Z512VHT4 to MKW36A512VFT4 MCUs. This example will make use of the "beacon" SDK example. SDK Download and Install 1- Go to MCUXpresso web page: MCUXpresso Web Page 2- Log in with your registered account. 3- Search for the "KW36A" device. Then click on the suggested processor and click on "Build MCUXpresso SDK"       4- The next page will be displayed. Select “All toolchains” in the “Toolchain / IDE” box and provide a name to identify the package. Then click on "Download SDK".     5- Accept the license agreement. Wait a few minutes until the system gets the package into your profile. Download the SDK clicking on "Download SDK Archive" as depicted in the following figure.     6- If MCUXpresso IDE is used, drag and drop the KW36A SDK zip folder in “Installed SDK’s” perspective to install the package.     At this point, you have downloaded and installed the SDK package for the KW36A device.   Software Migration in MCUXpresso IDE 1- Import the "beacon" example on the MCUXpresso workspace. Click on “Import SDK examples(s)…” option, a new window will appear. Then select "MKW36Z512xxx4" and click on the FRDM-KW36 image. Click on the "Next >" button.     2- Search beacon and select your project version (bm or freertos).     3- Go to Project/Properties. Expand C/C++ Build/MCU settings and select MKW36A512xxx4 MCU. Click Apply and Close button to save the configuration.     4- Rename MKW36Z folders as MKW36A, clicking the right mouse button and selecting "Rename". These are the following:   framework/DCDC/Interface -> MKW36Z framework/DCDC/Source -> MKW36Z framework/LowPower/Interface -> MKW36Z framework/LowPower/Source -> MKW36Z framework/XCVR -> MKW36Z4     5- Open the Project/Properties window in MCUXpresso IDE. Go to C/C++ Build/Settings and select MCU C Compiler/Includes folder in the Tool Settings window. Edit all paths related to MKW36 MCU, in according to MKW35 folders before created. The results must look similar as shown below:   ../framework/LowPower/Interface/MKW36A ../framework/LowPower/Source/MKW36A ../framework/DCDC/Interface/MKW36A ../framework/XCVR/MKW36A4     6- Select MCU Assembler/General folder in Tool Settings. Edit the paths related to MKW36 MCU. The results must look similar as shown below:   ../framework/LowPower/Interface/MKW36A ../framework/LowPower/Source/MKW36A ../framework/DCDC/Interface/MKW36A ../framework/XCVR/MKW36A4     7- Go to Project/Properties. Expand MCU C Compiler/Preprocessor window. Edit "CPU_MKW36Z512VHT4" and "CPU_MKW36Z512VHT4_cm0plus" symbols, rename it as "CPU_MKW36A512VFT4" and "CPU_MKW36A512VFT4_cm0plus" respectively. Save the changes.     8- Go to the workspace. Delete “fsl_device_registers, MKW36Z4, MKW36Z4_features, system_MKW36Z4.h and system_MKW36Z4.c” files located at CMSIS folder. Then, unzip the MKW35Z SDK package and search for “fsl_device_registers, MKW36A4, MKW36A4_features, system_MKW36A4.h and system_MKW36A4.c” files into this folder at the following paths:   <SDK_folder_root>/devices/MKW36A4/fsl_device_registers.h <SDK_folder_root>/devices/MKW36A4/MKW36A4.h <SDK_folder_root>/devices/MKW36A4/MKW36A4_features.h <SDK_folder_root>/devices/MKW36A4/system_MKW36A4.h <SDK_folder_root>/devices/MKW36A4/system_MKW36A4.c     9- Overwirte the “startup_mkw36z4.c” (located inthe startup folder) by the "startup_mkw36a4.c" located in the following path <SDK_folder_root>/devices/MKW36A4/mcuxpresso/startup_mkw36a4.c. You can simply drag and drop on the startup folder, and remove the older one.     10- Open "fsl_device_registers.h" file in CMSIS folder. Add"defined(CPU_MKW36A512VFT4)" in the following code (line 18 of the file):   /* * Include the cpu specific register header files. * * The CPU macro should be declared in the project or makefile. */ #if (defined(CPU_MKW36A512VFP4) || defined(CPU_MKW36A512VFT4) || defined(CPU_MKW36A512VHT4) || defined(CPU_MKW36A512VFT4))‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍   11- Open "ble_config.h" file in bluetooth->host->config folder. Add "defined(CPU_MKW36A512VFT4)" in the following code (line 146 of the file):   /* The maximum number of BLE connection supported by platform */ #if defined(CPU_QN9080C) #define MAX_PLATFORM_SUPPORTED_CONNECTIONS 16 #elif (defined(CPU_MKW36Z512VFP4) || defined(CPU_MKW36Z512VHT4) || defined(CPU_MKW36A512VFP4) || defined(CPU_MKW36A512VHT4) || defined(CPU_MKW36A512VFT4) || \ defined(CPU_MKW35Z512VHT4) || defined(CPU_MKW35A512VFP4) || \ defined(CPU_K32W032S1M2CAx_cm0plus) || defined(CPU_K32W032S1M2VPJ_cm0plus) || \ defined(CPU_K32W032S1M2CAx_cm4) || defined(CPU_K32W032S1M2VPJ_cm4) || \ defined(CPU_MKW38A512VFT4) || defined (CPU_MKW38Z512VFT4) || defined(CPU_MKW39A512VFT4) || \ defined(CPU_MKW37A512VFT4) || defined(CPU_MKW37Z512VFT4))‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍   12- Open "ble_controller_task.c" file in source->common folder. Add "defined(CPU_MKW36A512VFT4)" in the following code (line 272 of the file):    #elif (defined(CPU_MKW35A512VFP4) || defined(CPU_MKW35Z512VHT4) || defined(CPU_MKW36A512VFP4) || defined(CPU_MKW36A512VFT4) ||\ defined(CPU_MKW36A512VHT4) || defined(CPU_MKW36Z512VFP4) || defined(CPU_MKW36Z512VHT4)) /* Select BLE protocol on RADIO0_IRQ */ XCVR_MISC->XCVR_CTRL = (uint32_t)((XCVR_MISC->XCVR_CTRL & (uint32_t)~(uint32_t)( XCVR_CTRL_XCVR_CTRL_RADIO0_IRQ_SEL_MASK )) | (uint32_t)( (0UL << XCVR_CTRL_XCVR_CTRL_RADIO0_IRQ_SEL_SHIFT) ));‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍   13-Build the project.   At this point, the project is already migrated.   Software Migration in IAR Embedded Workbench IDE 1- Open the beacon project located in the following path: 2- Select the project in the workspace and press Alt + F7 to open project options.   3- In the General Options/Target window click the icon next to the device name and select the appropriate device NXP/KinetisKW/KW3x/NXP MKW36A512xxx4, then click the OK button.   4- Create a new folder with the name MKW36A at following paths: <SDK_root>/middleware/wireless/framework_5.4.6/DCDC/Interface <SDK_root>/middleware/wireless/framework_5.4.6/DCDC/Source <SDK_root>/middleware/wireless/framework_5.4.6/LowPower/Interface <SDK_root>/middleware/wireless/framework_5.4.6/LowPower/Source <SDK_root>/middleware/wireless/framework_5.4.6/XCVR     5- Copy all files inside MKW36Z folders located at the above paths and paste in MKW36A folders.     6- Select the beacon project in the workspace and press Alt+F7 to open project options window. In C/C++ Compiler/Preprocessor window, rename the paths related to MKW36Z folders to MKW36A folders. Rename the CPU_MKW36Z512VHT4 macro as CPU_MKW36A512VFT4 in the defined symbols text box. The results must look similar as shown below: Click the OK button. $PROJ_DIR$/middleware/wireless/framework_5.4.2/LowPower/Interface/MKW36A $PROJ_DIR$/../../../../../../../devices/MKW36A4/drivers $PROJ_DIR$/../../../../../../../middleware/wireless/framework_5.4.2/DCDC/Interface/MKW36A $PROJ_DIR$/../../../../../../../middleware/wireless/framework_5.4.2/XCVR/MKW36A4 $PROJ_DIR$/../../../../../../../devices/MKW36A4 $PROJ_DIR$/../../../../../../../devices/MKW36A4/utilities     7- Expand the startup folder, select all files, click the right mouse button and select the “Remove” option. Click the right mouse button on the folder and select “Add/Add files”. Add the startup_MKW36A4.s located at this path: <SDK_root>/devices/MKW36A4/iar/startup_MKW36A4.s Also, add system_MKW36A4.c and system_MKW36A4.h into the startup folder. Both files are located at the next path: <SDK_root>/devices/MKW36A4   8- Open "ble_config.h" file in bluetooth->host->config folder. Add "defined(CPU_MKW36A512VFT4)" in the following code: /* The maximum number of BLE connection supported by platform */ #if defined(CPU_QN9080C) #define MAX_PLATFORM_SUPPORTED_CONNECTIONS 16 #elif (defined(CPU_MKW36Z512VFP4) || defined(CPU_MKW36Z512VHT4) || defined(CPU_MKW36A512VFP4) || defined(CPU_MKW36A512VHT4) || defined(CPU_MKW36A512VFT4) || \ defined(CPU_MKW35Z512VHT4) || defined(CPU_MKW35A512VFP4) || \ defined(CPU_K32W032S1M2CAx_cm0plus) || defined(CPU_K32W032S1M2VPJ_cm0plus) || \ defined(CPU_K32W032S1M2CAx_cm4) || defined(CPU_K32W032S1M2VPJ_cm4) || \ defined(CPU_MKW38A512VFT4) || defined (CPU_MKW38Z512VFT4) || defined(CPU_MKW39A512VFT4) || \ defined(CPU_MKW37A512VFT4) || defined(CPU_MKW37Z512VFT4))‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍   9- Open "ble_controller_task.c" file in source->common folder. Add "defined(CPU_MKW36A512VFT4)" in the following code: #elif (defined(CPU_MKW35A512VFP4) || defined(CPU_MKW35Z512VHT4) || defined(CPU_MKW36A512VFP4) || defined(CPU_MKW36A512VFT4) ||\ defined(CPU_MKW36A512VHT4) || defined(CPU_MKW36Z512VFP4) || defined(CPU_MKW36Z512VHT4)) /* Select BLE protocol on RADIO0_IRQ */ XCVR_MISC->XCVR_CTRL = (uint32_t)((XCVR_MISC->XCVR_CTRL & (uint32_t)~(uint32_t)( XCVR_CTRL_XCVR_CTRL_RADIO0_IRQ_SEL_MASK )) | (uint32_t)( (0UL << XCVR_CTRL_XCVR_CTRL_RADIO0_IRQ_SEL_SHIFT) ));‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍   10-Build the project.   At this point, the project is already migrated.

The purpose of this document is to communicate known issues with the FRDM-KW41Z development platform.  This document applies to all revisions of the FRDM-KW41Z development platform.  However, items are divided among their respective revisions and each item may or may not apply to all revisions.  Revision A The known issues, which may cause confusion for new customers, for revision A are as follows: 1) Incorrect default jumper configuration Issue:  Jumper, J24, shunt connector does not shunt pins 1 and 2, as noted in the schematic notes.   Impact:  Customers will not, by default, be able to put the OpenSDA circuit into bootloader mode.   Workaround:  There is currently only one workaround for this issue. Move shunt connector on jumper, J24, to shunt pins 1 and 2.   2) Default OpenSDA application may lose serial data Issue:  In certain situations, the serial to USB bridge portion of the default OpenSDA application may not correctly forward serial data. This problem typically only occurs after a POR of a development platform.   Impact: Customers may experience data loss when using the serial to USB converter functionality in their application.  Workaround:  There is currently one workaround for this issue.   Update to the latest JLink OpenSDA firmware.  To update to this firmware, consult sections 2.1 and 2.2 of the OpenSDA User Guide (found here:  http://cache.freescale.com/files/32bit/doc/user_guide/OPENSDAUG.pdf ).  The latest JLink OpenSDA firmware can be found here:  SEGGER - The Embedded Experts - Downloads - J-Link / J-Trace .  (Note:  Be sure to select the correct development platform.)                                                             3) Unable to measure correct IDD current when operating in buck mode and P3V3_BRD is disconnected Issue:  When configured for buck mode operation and J8 does not have a shunt connector, it is expected that P3V3_BRD will not be powered and thus, board peripherals will not be powered (thermistor, I2C line pull-ups, SPI Flash, Accelerometer, etc,).  However it should be noted that in this configuration, P3V3_BRD will be back-powered through resistor R90.  R90 is a 180kOhm resistor that connects directly to the MCU reset pin.  This R90 also connects to V_TGTMCU which is directly connected to P3V3_BRD through shorting trace SH500.  The internal pull-up on the reset pin will, in this case, power P3V3_BRD.      Impact:  Customers will not be able to isolate the MCU IDD current from the board peripherals when measuring current in the buck mode configuration.  This is a problem mostly when attempting to achieve datasheet IDD current numbers for low power modes in buck mode.   Workaround:  There are currently three (3) workarounds for this issue. Remove resistor R90. Cut shorting trace SH500. Customers should exercise caution when using this workaround.  After cutting this short trace, the OpenSDA interface buffers would no longer be powered.  Therefore, OpenSDA programming and serial communication will not be possible even when J8 shorting jumper is placed.   Disable the reset pin in the FOPT field then configure the pin, PTA2, for GPIO output functionality driven low.  Customers should exercise caution when implementing this option.  The pin, PTA2, could be used as a GPIO in the end application in this configuration, but you would not want to drive PTA2 high while SW1 was directly connected to PTA2 through pins 2 and 3 of jumper J24.  In this situation, you potentially short VDD and VSS inadvertently by pressing SW1.  If using this workaround, it is recommended to ensure the shorting jumper of J24 is either removed or connected to pins 1 and 2.    4) Incorrect routing of SWD clock for stand-alone debugger configuration Issue:  The signal SWD_CLK_TGTMCU  is incorrectly routed to pin 1 of connector J12 instead of pin 4 of the SWD connector, J9.     Impact:  With this routing, when the OpenSDA circuit is configured as a stand-alone debugger for debugging other targets (i.e., when J12's shorting trace is cut), the OpenSDA SWD clock will not be able to be present on pin 4 of connector J9. Therefore, the FRDM-KW41Z cannot act as a stand-alone debugger to facilitate debugging other systems.   Workaround:  There is currently only one workaround for this issue.  The workaround is a hardware workaround that requires a cutting tool (such as a modeler's knife), soldering iron, solder, and a spare wire.  To implement the workaround, follow these instructions.   Cut trace J12.                                                                                                                                                                            Cut the trace next to pin 2 and 4 of J9 that connects J9, pin 4 to J12, pin 2. Once this is done, be sure to use a multimeter and ensure there is no electrical connection between J12, pin 2, and J9, pin 4.                                                                                                          Solder one end of a spare wire to J9, pin 4, and the other end of the spare wire to J12, pin 1.  This should be done on the bottom of the board.  

This document provides the calculation of the Bluetooth Low Power consumption linked to the setting of the Kinetis.   The Power Profile Calculator is build to provide the power consumption of your application. It's a mix between real measurements in voltage and temperature. The process is not taken into account which may create some variation.   DISCLAIMER: This excel workbook is provided as an estimation tool for NXP customers and is based on power profile measurements done on a set of randomly selected parts. A specific part may exhibit deviation from the nominal measurements used on this tool.   This document is the summary of all the information available in the AN12459 Power Consumption Analysis - FRDM-KW38 available in the NXP web page.   Several parameters could be fill-in: Buck or bypass mode (DCDC) Supply Voltage (2.4V to 3.6V) Temperature (-40°C to +105°C) Processor configuration (20MHz, 32MHz or 48MHz) 10 different deep sleep modes Different Tx output power (0dBm, +3.5dBm or +5dBm) Data rate (1Mbps, 2Mbps, 500kbps, 125kbps) Possibility to set the Advertising interval, connection interval, scan interval and active scan windows duration Fix the Bluetooth Packet sizes in Advertising and Connection  Tx/Rx payload.   One optional information is to provide an idea of the duration life time on 9 typical batteries.

This application note describes the usage of the DC-DC Switching Mode Power Supply (SMPS) converter for the MKW39A/38A/37A/38Z/37Z families. This document covers operating voltages, types of circuit operation, hardware design guidelines, software configuration, and power capabilities. It's a complementary document from the AN5025. The DC-DC converter for MKW3x is a dual output converter that supports two operating modes: Bypass and Buck. In Bypass mode, the DC-DC converter is disabled and the supply pins of the microcontroller must be supplied externally. In Buck mode, the DC-DC converter is enabled and requires a DC supply in the range of 1.8 V to 4.2 V (during startup the minimum required is 2.1 V).

As mentioned in this other post, its important to have the correct trim on the external XTAL. However, once you have found the required trim to properly adjust the frequency, it is not very practical to manually adjust it in every device. So here is where changing the default XTAL trim comes in handy. KW41Z With the KW41 Connecitivity Software 1.0.2, it is a pretty straightforward process. In the hardware_init.c file, there is a global variable mXtalTrimDefault. To change the default XTAL trim, simply change the value of this variable. Remember it is an 8 bit register, so the maximum value would be 0xFF. KW40Z With the KW40, it is a similar process; however, it is not implemented by default on the KW40 Connectivity Software 1.0.1, so it should be implemented manually, following these steps: Create a global variable in hardware_init.c to store the default XTAL trim, similar to the KW41:  /* Default XTAL trim value */ static const uint8_t mXtalTrimDefault = 0xBE;‍‍‍‍‍‍‍‍ Overwrite the default XTAL trim in the hardware_init() function, adding these lines after NV_ReadHWParameters(&gHardwareParameters):    if(0xFFFFFFFF == gHardwareParameters.xtalTrim)   {       gHardwareParameters.xtalTrim = mXtalTrimDefault;   }‍‍‍‍‍‍‍‍‍‍‍‍ Add this define to allow XTAL trimming in the app_preinclude.h file:  /* Allows XTAL trimming */ #define gXcvrXtalTrimEnabled_d  1‍‍‍‍‍‍‍ Once you have found the appropriate XTAL trim value, simply change it in the global variable declared in step 1.

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-343043

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