NXP Designs Knowledge Base

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

NXP Designs Knowledge Base

Discussions

Sort by:
This MQX demo re-uses the standard MQX web_hvac demo with the GT202 Wi-Fi module setup in SoftAP mode. This example shows MQX RTCS, DHCP server, and web server running in the Kinetis MCU with the Atheros drivers. The client will be able to connect to the Soft Access Point, receive an IP address, and then use a web browser to view the web_hvac web pages.  The User Guide is included in the ZIP file.
View full article
Demo This demo showcases an OpenWRT based Thread Border router running on i.MX6UL and the various options to configure and use routing, firewall and out of band commissioning for Thread networks in combination with WiFi, Ethernet and NFC. OpenWRT is an open source Linux distribution for embedded devices specifically designed for residential gateways and routers. When enhanced with the Kinetis Thread protocol it offers the perfect solutions for creating a Linux based Thread Border Router Large and dense mesh network consisting in 64+ Thread nodes Each node is router capable, network decides dynamically which nodes become active routers Multiple application functionality run in parallel: Device addressing and identification Lighting demonstration with multicast Occupancy sensing demonstration Border Router with Network management web GUI   Features: Application layer communication based on generic CoAP framework CoAP messaging aligned with current ZigBee or OIC frameworks Kinetis KW2xD and Kinetis KW41 ARM Cortex-M4/M0+ MCUs with large on-board memory (up to 512KB flash/128 KB RAM) enable multiple applications to run on a common Thread IP network fabric. 1 i.MX6UL ARM Cortex-A7 with Kinetis KW2xD Linux Border Router used for interfacing with network management GUI Network management and interoperable Thread diagnostics framework used to monitor node state Nodes are enabled for OTA Updates _____________________________________________________________________________________________ Featured NXP Products: Product Link i.MX6UltraLite Evaluation Kit i.MX6UltraLite Evaluation Kit | NXP  Freedom Development Platform for Kinetis® KW2x MCUs FRDM-KW24D512|Freedom Development Platform|Kinetis | NXP  _____________________________________________________________________________________________
View full article
This doc explain how to modify the bootloader to boot linux&mcal, to solve the conflict between bootloader, mcal and linux   本文说明在S32G2 RDB2板上如何定制开发Bootloader,本文示例主要实现功能是: Bootloader启动一个M核,MCAL驱动测试程序,本文分别测试了MCU,DIO,UART的MCAL驱动示例代码。 Bootloader同时启动A53 Linux 目录 1    需要的软件,工具,文档与说明... 3 1.1  软件与工具... 3 1.2  参考文档... 3 1.3  开发说明... 3 2    测试软件安装编译说明... 4 2.1  安装RTD_MCAL驱动... 4 2.2  编译MCAL驱动测试程序(以MCU为例) 5 2.3  优化重排M7 demo镜像及与MPU设置的配合... 5 2.4  去掉CLOCK INIT. 7 2.5  去掉MCU相关INIT. 8 2.6  DIO MCAL程序去掉PORT INIT. 9 2.7  UART MCAL程序去掉PORT INIT. 10 2.8  UART MCAL程序修改CLOCK TREE.. 10 2.9  解决中断冲突... 11 2.10 准备A53 Linux镜像... 12 3    Bootloader工程说明... 13 3.1  关掉XRDC支持... 13 3.2  关掉eMMC/SD支持(可选) 14 3.3  关掉secure boot(可选) 14 3.4  增加MCAL驱动所需要的PORT的初始化... 15 3.5  解决Bootloader,MCAL与Linux的clock冲突... 17 3.6  配置A53 Boot sources: 34 3.7  配置M7 Boot sources: 35 3.8  关闭调试软断点:... 36 3.9  编译Bootloader工程... 37 3.10 制造Bootloader的带IVT的镜像... 38 3.11 烧写镜像... 41 4    测试... 42 4.1  硬件连接... 42 4.2  MCU MCAL+Linux测试过程... 42 4.3  DIO MCAL+Linux测试过程... 43 4.4  UART MCAL+Linux测试过程... 43 5    Bootloader源代码说明... 43 6    Bootloader定制说明... 45 6.1  QSPI NOR驱动说明... 45 6.2  eMMC/SDcard启动支持... 46 6.3  DDR初始化... 46 6.4  Secure Boot支持... 46 7    调试说明... 46 7.1  Bootloader的调试... 46 7.2  MCAL驱动的调试... 46   add one more doc to explain how to modify atf to boot on G3.
View full article
This application note explain how to run M kernel PFE master and A kernel PFE slave demo without bootloader support. chinese version: 在真实的产品中,一般会使用一个基于M7_0核的bootloader来启动M和A核,这个bootloader负责所有M核和A核资源的初始化,解决M核和A核的资源冲突,并且启动M和A核。所以理论上运行M PFE Master Mcal驱动加A PFE Slave Linux驱动也是需要一个bootloader的。参考文档《S32G_Bootloader_V*》,Johnli,可以在公开community上搜索获得。 本文讨论一种简易的办法,就是: S32G3 RDB3板子配置为SDcard启动,插入SDcard,里面放有PFE SLAVE驱动的Linux镜像。 上电启动后运行PFE Master工程的lauterbach调试脚本:run_main_G3_REV1_1.cmm,这个脚本会重启整个S32G3。 然后在脚本中用wait 10S的操作,这个时候Linux已经启动,并且使用Uboot的代码调用ATF来完成PFE相关pre-init, partition reset和时钟与管脚初始化(如上分析, EMAC0~2的RGMII IOMUX已经配置好),然后Slave驱动会等待一段时间,等MCAL Master驱动加载,继续运行PFE Master MCAL代码后,Linux端Slave驱动也加载正确。然后就可以测试整个M Master/A Slave Demo。 总结:以上办法实际上是把bootloader应该做的PFE相关硬件初始化工作由Linux来完成,以便快速搭建Demo,这样客户在做真实的产品开发时,可以做为一个NXP release的标准参考。
View full article
Combining NXP's wireless MCU with NFC controller allows to build a BLE-NFC bridge. It allows demonstrating transmission of NFC data over BLE, acting then as a king of Magic NFC remote. This demonstrator is built assembling the OM5578: Development Kits for PN7150 Plug’n Play NFC Controller (OM5578/PN7150ARD version including Arduino compatible connectors). on top of the FRDM-KW41Z: Freedom Development Kit for Kinetis ® KW41Z/31Z/21Z MCUs (minimum version B1 since previous versions have a pin conflict on the Arduino connector) Alternatively the Rigado R41Z Eval Board can be used as replacement to the FRDM-KW41Z To complete the demonstration, an android phone is used as BLE counterpart. It shall run the modified version of Kinetis BLE Toolbox android application including the NFC demo part. This dedicated version of the Kinetis BLE Toolbox android application is available for download from the files attached to this document. Below is a video of the demo. As shown, it demonstrate capabilities to control the NFC discovery remotely (via BLE) from the phone. Then, if tapping a card on the bridge, the related information including the content is conveyed through BLE to the phone and get displayed by the app. Additionally, the app can configure a message to be shared whenever an NFC reader (e.g. NFC phone) tap the bridge. The K41Z firmware of this demo is built based on the wireless UART example from MCUXpresso Software Development Kit (SDK), and updated with the porting of the NXP-NCI MCUXpresso example. The complete MCUXpresso project is given in source code in the attached files. To replicate the demo, just import it in an MCUXpresso workspace by selecting "Existing Projects into Workspace", then browsing to the BLE-NFC_bridge_MCUXpressoProject.zip file. Select the frdmkw41z_BLE-NFC_bridge from the "Project Explorer" view, and click on the blue bug icon to build, flash and debug the program.
View full article
This article explains the details and customization of the S32G M7 core Standby demo. And how to porting to Autosar Mcal demo. Contents 1    Description of reference materials. 2 2    Demo creation and running process. 2 2.1  Demo checkpoints. 2 2.2  The difference between Standby and StandbyRAMboot 4 3    S32G Standby principle and Code Description. 5 3.1  Peripheral initialization function. 5 3.2  standbyramc_cpy(optional) 5 3.3  WKPU_set 8 3.4  standby_modechange. 13 4    VR5510 PMIC Standby principle and code description. 15 4.1  PMIC_initConfig. 15 4.2  PMIC_standbyEntry. 17 5    Customization modification. 18 5.1  Do not enable RTC wakeup feaure. 18 5.2  Eable CAN1_RX wakeup feature. 19 5.3  Only support full boot 21 5.4  Open the DDR related power 21 5.5  Modify debug serial port to UART1. 24 5.6  Modify the device drive clock. 26 5.7  close other non-main core. 30 6    Build a new MCAL demo. 34 6.1  Modify the UART driver 35 6.2  Implement the clock shutdown code. 36 6.3  Configure the power mode switching driver 37 6.4  Confgure the wakeup source. 42 6.5  Add PMIC driver 51 6.6  Main function call routine. 59 6.7  Test 61 6.8  Future development plan. 62 本文说明S32G M7核Standby demo 详细情况及定制,以及如何新建一个mcal demo 录 1    参考资料说明... 2 2    Demo创建运行过程... 2 2.1  创建运行... 2 2.2  Standby和StandbyRAMboot的区别... 4 3    S32G Standby原理与代码说明... 5 3.1  外设初始化函数... 5 3.2  standbyramc_cpy(可选) 5 3.3  WKPU_set 8 3.4  standby_modechange. 13 4    VR5510 PMIC Standby原理与代码说明... 14 4.1  PMIC_initConfig. 14 4.2  PMIC_standbyEntry. 16 5    定制修改... 17 5.1  关闭RTC唤醒功能... 17 5.2  打开CAN1_RX唤醒功能... 19 5.3  只支持full boot 20 5.4  打开DDR相关电源... 21 5.5  修改调试串口为UART1. 23 5.6  修改设备驱动时钟... 25 5.7  事先关掉所有其它的非主核... 29 6    修改为MCAL Demo. 33 6.1  修改UART驱动... 34 6.2  实现时钟关闭代码... 35 6.3  配置电源模式切换驱动... 36 6.4  配置唤醒源... 41 6.5  加入PMIC驱动... 50 6.6  主函数逻辑实现... 58 6.7  运行测试... 60 6.8  未来开发计划... 61   attachment include chinese/english doc, s32ds codes with 2 zip package(remove the .7z), mcal codes.  
View full article
This post entry provides a detailed description of how the Device-to-device communication demo was developed so that you can leverage this knowledge to integrate NFC into your own system. This document has been structured as follows:   Introduction Device-to-device communication demo functionality NFC for communication with a batteryless unit NFC for communication between two devices mounted in close proximity NFC for communication with a rotating part as a cable replacement solution Hardware details Base board based on CLRC663 plus Rotating disk based on NTAG I2C plus Application logic Reader module to rotating disk communication Rotating disk to reader module communication MCU code details NTAG I2C plus pass-through mode data exchange synchronization considerations Reader module MCU code NTAG_Device2DeviceDemo  application workflow Rotating disk MCU code NTAG_I2C _Explorer_01_LEDs_ButtonXample application workflow Video recorded session Available resources Introduction The Device-to-device communication demo shows how NFC can be used as a cable replacement between two units or devices. It is based on the CLRC663 plus NFC Frontend and the NTAG I 2 C plus connected tag solutions. It demonstrates how NFC is used for: Wireless communication with a batteryless unit. Wireless communication between two devices mounted in close vicinity that need to be completely isolated (e.g. dust or water proof). Wireless communication with a rotating part and as a cable replacement solution.   Device-to-device communication demo functionality The purpose of the demo is to illustrate how to enable device-to-device communication via NFC. It consist of: A base board of 14x12 cm, which embeds the CLRC663 plus NFC reader IC for the RF field generation. A sensor embedded on a separate, rotating sensor disk of 8 cm diameter, which embeds the NTAG I 2 C plus connected tag.   The base board and the rotating sensor disk communicate via NFC and optionally, a tablet display can be connected via a Bluetooth Low Energy (BLE) connection (the BLE connection is beyond the scope of this post entry).     NFC for communication with a batteryless unit The first scenario demonstrates the use of NFC for communication with a batteryless unit or sensor. Energy from the RF field generated by an NFC reader can be harvested to power up small devices so that a battery or other power supply no longer needs to be included.   In this demo, only the base board is powered using a 5V supply input (e.g. USB battery bank) while the rotating disk electronics are powered using only the harvested energy from the RF field generated by the base board. To maximize energy transfer and avoid possible interference caused by the electronics, both the rotating disk and base board antennas are placed on the edges. In the following video, you can observe how as soon as the base board is supplied, it starts generating an RF field and automatically. Then,  all the electronics on the rotating disk are powered and its LED turns GREEN.   http://wpc.08c9.edgecastcdn.net/0008C9/twistage-production/f54/f54337d597118_12181097.mp4?d273d3b84ae78c6b0b40b4df7e407772944048591ee44914b69449116aeb54387b9f NFC for communication between two devices mounted in close proximity The second scenario demonstrates the use of NFC for communication between two devices mounted in close proximity. For instance, any machine or device where sensors are inside or in close vicinity and the sensor needs to be completely sealed (e.g. waterproof, dustproof, etc).   In this demo, the bidirectional communication between the two units is demonstrated using push buttons, which light up LEDs on the opposite unit. For the base board to rotating disk communication direction: While action button 1 is pressed, the LED on the rotating disk turns BLUE. While action button 2 is pressed, the LED on the rotating disk turns RED. While action button 1 and button 2 are pressed, the LED on the rotating disk turns WHITE.   http://wpc.08c9.edgecastcdn.net/0008C9/twistage-production/912/912db3bd13b06_12160248.mp4?d273d3b84ae78c6b0b40b4df7e407772944048591ee44914b69449116aeb54387c99 With the other way around, for the rotating disk to base board communication direction: While action button 3 is pressed, a pattern on the LED circle will appear.   http://wpc.08c9.edgecastcdn.net/0008C9/twistage-production/d0b/d0b0072da0120_12160391.mp4?d273d3b84ae78c6b0b40b4df7e407772944048591ee44914b69449116aeb54387e98   NFC for communication with a rotating part as a cable replacement solution The third and last scenario demonstrates the use of NFC to communicate wirelessly with two moving parts where cables may break. For instance, any solution consisting of a main unit and a sensing part recording mechanical-stress readings on moving parts.   In this demo, the accelerometer on the rotating disk continuously sends its coordinates to the base board, which lights up a specific LED according to the calculated angle between the two units. In the following video, you can see that the LED circle "follows" the movement of the rotating disk.   http://wpc.08c9.edgecastcdn.net/0008C9/twistage-production/c0e/c0e3daf347aed_12160349.mp4?d273d3b84ae78c6b0b40b4df7e407772944048591ee44914b69449116aeb5438709a   Hardware details This section shows the architecture and main components of the base board and rotating disk.  The PCB schematics are attached at the end of this post entry.   Base board based on CLRC663 plus The disk has been dismounted so you can better appreciate the different components of the base board. The base board is driven by an LPC11U68 MCU, which is a low-cost Cortex-M0 USB solution, with 256 kB of flash memory, up to 80 GPIOs and several host interfaces (more details on the LPC11U68 product website).   From the LPC11U68 MCU, some of the GPIOs are used to connect the action buttons and the 12 LEDs of the circle, an SPI port is used to connect the CLRC663 plus NFC Frontend and, a USART port is used for connecting a BLE chip based on NXP's QN9021 chip.     The NFC functionality is provided by our CLRC663 plus reader IC, an NXP high performance multi-protocol reader. It is the evolution of CLRC663, with a larger LPCD detection range, more output power (2x times higher transmitter current), larger temperature operating range and pin-to-pin compatibility with the former version.   Rotating disk based on NTAG I 2 C plus The rotating disk is based on NXP solutions as well. This PCB board is driven by an LPC11U24 MCU, which is a low-cost Cortex M0 32 bit MCU, with 32 kB of flash memory, up to 40 GPIOs and several host interfaces (more details on the LPC11U24 product website).   From the LPC11U24 MCU, some of the GPIOs are used to connect the action button 3 and the RGB LED. In addition, an I 2 C interface port is shared to connect a temperature sensor, the accelerometer and the NTAG I 2 C plus.     The NTAG I 2 C plus is a family of connected NFC tags that combines a memory, a passive NFC interface with a contact I 2 C interface.  Functionally, the NTAG I 2 C plus behaves as a dual port memory. Therefore, the data can pass from an external NFC device to the embedded system. In addition, to this dual interface solution, it has more features: A field detection pin, to send a wake up signal The Energy harvesting, to power external devices The SRAM, a memory without writing cycles limitation The pass-through mode, for fast data exchange between interfaces Several memory access management settings from both NFC and I2C interfaces And an originality signature, to protect against clones.   Application logic This section describes how data is exchanged between the reader module (base board) and the rotating disk using NTAG I 2 C plus as a bridge (pass-through mode) between the two embedded systems.   Reader module to rotating disk communication In this demo, the reader module sends data to the rotating disk when any of its two action buttons are pressed. The NTAG I 2 C plus is configured in pass-through mode and the SRAM memory is used as conduit between the twto units.  The figure below illustrates a simplified representation of NTAG I 2 C plus memory seen from the NFC perspective (organized in pages of 4 bytes each). The red area represents the EEPROM memory while the yellow one represents the SRAM memory location. While the button 1 is pressed: The GPIO 4 of the LPC11U68 is in high level. The CLRC663 plus writes one byte into the SRAM memory (last page, value = 0x01). The LPC11U24 on the rotating disk reads the SRAM. The LPC11U24 changes the GPIO 18 status to high level. The RGB LED turns blue.   The operation that takes place while button 2 is pressed is pretty similar. Basically, it changes: the data written by the CLRC663 plus in the SRAM and the GPIO activated by the LPC11U24 on the rotating disk. More precisely, the steps are: The GPIO 5 of the LPC11U68 is in high level. The CLRC663 plus writes one byte into the SRAM memory (last page, value = 0x02). The LPC11U24 on the rotating disk reads the SRAM. The LPC11U24 changes the GPIO 16 status to high level and sets GPIO 18 to low level. The RGB LED turns red.     In the same way, while the two buttons are pressed at the same time: The LPC11U68 detects that GPIO 4 and 5 are in high level The CLRC663 plus programs a different value on the last SRAM byte (0x03). The LPC11U24 on the rotating disk reads the SRAM. The LPC11U24 sets to high the three GPIOs (16,17,18) controlling the RGB LED. The RGB LED turns white The key message is that: what it is written in the SRAM controls the behavior of the rotating disk LED, demonstrating wireless data exchange between the two embedded systems.   Rotating disk to reader module communication In this demo, the rotating disk keeps sending data to the reader module for as long as it is powered by the RF field. Precisely, it continuously sends the disk position (via the accelerometer axis coordinates) and the measured temperature value. Additionally, an extra byte is sent while the button 3 is pressed. The actual steps are: First, the LPC11U24 MCU triggers a read operation to the temperature sensor and accelerometer. The temperaturre reading occupies 2 bytes while the accelerometer axis coordinates occupy 6 bytes. This data is transfered the LPC11U24 via the I 2 C shared bus. The LPC11U24 writes these 8 bytes into the SRAM in page addresses 0xFD, 0xFE and 0xFF (see the figure below). The CLRC663 plus reads the SRAM when the LPC11U24 has finished writing it. With the read information, the LPC11U68 base board MCU calculates the angle and sets the appropriate GPIO to high level. Since the LED circle contains 12 LEDs, the base board is able to represent position changes of 30 degrees (360º / 12 LEDs).   As mentioned, this data transfer keeps going for as long as the disk is powered. The key concept here is that the LED circle operation is directly controlled by the disk position and the axis coordinates which are exchanged via the NTAG I 2 C plus SRAM at any given moment. To illustrate this, the disk is rotated 90 º clockwise. The steps that take place are: The LPC11U24 MCU triggers the next reading command, the accelerometer axis coordinates have changed to different ones representing the new disk position (in red in the memory map figure below). The LPC11U24 writes into the SRAM again these 8 bytes (now with the updated accelerometer axis coordinates) The CLRC663 plus reads the SRAM when the LPC11U24 has finished writing it. With this new reading, the LPC11U68 MCU recalculates the angle and applies a different GPIO configuration (which leads to a different LED turned on in the circle).     Last, while button 3 is pressed: The LPC11U24 GPIO 12 is set to high value. The LPC11U24 checks GPIO 12 pin status before writing into the SRAM. While it is high level, it adds an additional byte into the SRAM (third byte on page 0xFF- value=0x01). The CLRC663 plus reads the SRAM, getting the latest data from the moving part. With the current firmware, while the third byte on page address 0xFF is set to 0x01, the LPC11U68 performs a LED pattern activating all the GPIOs simultaneously (all the LEDs are ON).     MCU code details This section explains the firmware implementation details for both the base board (CLRC663 plus) and the rotating disk (NTAG I 2 C plus). Before going into the firmware implementation details, a few considerations for data exchange synchronization when using the NTAG I 2 C plus pass-through mode are explained.   NTAG I 2 C plus pass-through mode data exchange synchronization considerations In the demo, the pass-through mode is used to exchange data between the base board and the rotating disk. The pass-through mode provides the SRAM for data communication and the mechanisms for the synchronization of the data transfer. This signalling can be done through the field detection pin or by polling the equivalent registers over the I 2 C interface. For the NFC to I 2 C direction, the synchronization can be done: By checking the SRAM_I2C_READY register to learn if new data has been written by the RF interface. By checking the filed detection pin changing from HIGH to LOW voltage.   For I 2 C interface to NFC direction, the synchronization can be done: By checking the SRAM_RF_READY register to learn if new data has been written by the I 2 C interface. By checking the filed detection pin changing from LOW to HIGH voltage.   The following table includes register bits which can be used for communication synchronization. In addition, there is a dedicated application note providing more details on how NTAG I 2 C plus can be used for bidirectional data communication.   Register bit Use PTHRU_ON_OFF Detects if the pass-through mode is still enabled (gets reset in case of RF or I2C power down). TRANSFER_DIR Defines the data flow direction for the data transfer. I2C_LOCKED Detects if memory access is currently locked to I2C. RF_LOCKED Detects if Memory access is currently locked to RF. SRAM_I2C_READY Detects if there is data available in the SRAM buffer to be fetched by the I²C side. SRAM_RF_READY Detects if there is data available in the SRAM buffer to be fetched by the RF interface. RF_FIELD_PRESENT Shows if a RF field strong enough to read the tag is there.   Reader module MCU code The MCU firmware was developed using our LPCXpresso platform, which provides a complete development environment for LPC MCU and LPC boards. In the source code, there are five project folders: The FreeRTOS project folder, which is an open source real-time operating system (RTOS) for embedded systems supporting many different architectures and compiler toolchains The Lpc_chip_11u6x_lib and nxp_lpcxpresso_11u68b project folders, which belong to the LPCOpen libraries supporting the LPC11U68 MCU and PCB board, the MCU chip integrated in the Explorer board. If you use another MCU, you should replace them by the specific LPCOpen libraries. The NTAG_Device2DeviceDemo  project folder, which implements the logic supporting the device-to-device communication demo for the reader module. The NxpNfcRdLib project folder, which is the NXP's NFC Reader Library software stack supporting the implementation of the demo, the contactless protocols, the LPC MCU host interfaces and the CLRC663 drivers.   The reader module MCU code leverages on the NFC Reader Library. The NFC Reader Library is a software stack for creating and developing contactless applications for NXP's NFC readers. This API facilitates the most common operations required in NFC applications such as: reading or writing data into contactless cards, exchanging data with other NFC-enabled devices and emulating cards.   In order to use the NFC Reader Library, a stack of components has to be built up from the bottom to the top layer. Precisely, the application requirements define which modules need to be enabled and which do not. For the reader module firmware: The FreeRTOS is used. The SPI is used as host interface. A CLRC663 plus reader IC is used. And, communication with NTAG I 2 C plus is needed ( ISO14443 Type A card and NFC Forum Type 2 Tag compliant)   As a result, the software components that need to be enabled within the NFC Reader Library are depicted in the following picture: NTAG_Device2DeviceDemo  application workflow The reader module firmware starts its execution as soon as it is connected to the power bank. The firmware initializes the GPIOs, the UART for the tablet connection and the NFC Reader Library for the contactless operation. After all these initializations, the firmware code generates a new thread in charge of dealing with the disk operation. In this separate thread, the discovery loop for detection of Type A and Type V cards is configured and started. After that, the firmware keeps listening until the NTAG I 2 C plus is detected (i.e. the disk is mounted). On detection, the operation with the rotating disk starts: The reader module waits until the SRAM is available for the RF interface. The SRAM is available for the RF interface while the pass-through mode is enabled (PTHROUGH_ON_OFF register is set) and the RF to I 2 C direction is set (TRANSFER_DIR register bit). The board buttons are checked and the SRAM is written with the corresponding information.   At this point, the program awaits to receive data from the rotating disk. For that, it keeps polling if new data was written in the SRAM by the I 2 C interface (SRAM_RF_READY register bit is set). If new data is available, the SRAM is read and the data is processed: The accelerometer axis coordinates are read, the angle is calculated and the appropriate LED on the circle is activated. While the button 3 is pressed, the MCU triggers the LED pattern on the circle. Optionally, if the tablet connection is established, data is also sent using the BLE channel.   The following figure depicts the reader module application workflow in detail:   Rotating disk MCU code The MCU firmware was also developed using the LPCXpresso platform.  In the source code, there are four project folders: The Lpc_chip_11uxx_lib and nxp_lpcxpresso_11u24h_board_lib project folders belong to the LPCOpen libraries supporting the LPC11U24 MCU and PCB board, the MCU chip integrated in the Explorer board. If you use another MCU, you should replace them by the specific LPCOpen libraries. The NTAG_I 2 C _API project folder is a library providing a set of functions and procedures that allow you to communicate with the NTAG I 2 C from the I 2 C interface. Among others, functions to perform memory operations on EEPROM, SRAM, registers and for enabling the pass through mode The NTAG_I 2 C _Explorer_01_LEDs_ButtonXample project folder implements the logic for the rotating disk of this demo.   NTAG_I 2 C _Explorer_01_LEDs_ButtonXample application workflow The rotating disk firmware starts its execution as soon as it harvests enough energy from the reader's module RF field. The first operation taken is to enable the pass-through mode. Then, the firmware stays on a loop for as long as it is energized.   In this loop, it sets the SRAM into RF to I 2 C direction (TRANSFER_DIR register bit) and waits until the base board has written data. After data has been written from the RF side, it reads the SRAM and checks the last byte: While the last byte value is 0x01, it means the button 1 is pressed and the firmware sets the RGB LED to blue While the last byte value is 0x02, it means the button 2 is pressed and the firmware sets the RGB LED to red While the last byte value is 0x03, it means the button 1 and 2 are pressed and the firmware sets the RGB LED to white.   After receiving data from the base board, it prepares to send data back. For that: it checks the button status, it reads the temperature value and the accelerometer position. Once all the data has been collected: It changes the SRAM to I 2 C to RF direction (TRANSFER_DIR register bit). It writes into the SRAM and waits until the RF has read the data (SRAM_RF_READY register is cleared).   This loop is repeated for as long as the disk is powered. The following figure depicts the rotating disk application workflow in detail:     Video recorded session On 9 March 2017, a live session explaining the device-to-device communication demo was recorded. You can watch the recording here:   http://wpc.08c9.edgecastcdn.net/0008C9/twistage-production/149/149fee5f5e282_12181079.mp4?d273d3b84ae78c6b0b40b4df7e407772944048591ee44914b69449116aeb5439ff51 Available resources   Schematics Please see attached in the separate attachment section below. Device-to-device demo source code Please see attached in the separate attachment section below. Quick-start guide for showing the demo Please see attached in the separate attachment section below Android app The android app can be used on a tablet or smart phone connected via BLE to this demo to show additional parameters, and to have a bigger screen for demonstrations. You find it in Google play ("device2devicedemo") and attached below.  
View full article
Speed development time when designing your portable medical device with NXP's Healthcare Analog Front End (AFE) reference platform which includes a complete hardware platform, schematics and software.  Based on the Kinetis Microcontroller K53 measurement. Demo Owner: dr.josefernandezv Demo Owner: aleguzman Features Speed development time when designing your portable medical device with NXP's Healthcare Analog Front End (AFE) reference platform which includes a complete hardware platform, schematics and software NXP offers a complete development platform based on the Tower System, which eases the development of medical applications with a fully integrated set of solutions that reduces the design effort The Medical suitcase is composed of six different analog front ends, each one focused on a specific medical application. Applications included are, 1-Lead ECG, pulse oximeter, blood pressure monitor, glucometer, spirometer, and ultrasound digital stethoscope Featured NXP Products K50_100: Kinetis K50 Measurement 100 MHz MCUs Healthcare Analog Front End( AFE) Block Diagram
View full article
Demo         This was a super fun project to work on and is popular around the office and on the road.  Now I have two of these for a truly amazing barrage of Nerf darts!  It's also always a lot of fun to tear things down and the Nerf gun had some cool plastic work and the shooting mechanism is more simple than what I originally guess.  But I digress, this post is about how you can build one of these yourself.  Please leave any questions or comments in the section below and I will try to answer and make refinements to this guide as we go.   The shopping list (aka Bill of Materials or BOM)   If you shop around you might be able to find better prices or substitute parts.   Type Part Qty Price URL UBEC HKU5 1 $             5.33 http://www.hobbyking.com/hobbyking/store/__16663__HobbyKing_HKU5_5V_5A_UBEC.html LiPo TURNIGY 2200mAh 3S 20C 1 $             7.89 http://www.hobbyking.com/hobbyking/store/__8932__Turnigy_2200mAh_3S_20C_Lipo_Pack.html Servo S5030DX 1 $           28.63 http://www.hobbyking.com/hobbyking/store/__18862__Hobbyking_S5030DX_Digital_MG_Servo_X_Large_HV_164g_0_20s_30kg.html Servo HK15138 1 $             3.12 http://www.hobbyking.com/hobbyking/store/__16269__HK15138_Standard_Analog_Servo_38g_4_3kg_0_17s.html Relay PCB COM-11041 1 $             3.95 https://www.sparkfun.com/products/11041 Relay Components Various 1 $             3.00 https://www.sparkfun.com/wish_lists/36307 Nerf Gun Nerf Dart Tag Swarmfire Blaster 1 $           44.99 http://www.toysrus.com/product/index.jsp?productId=11267568 Controller FRDM-K64F 1 $           29.00 FRDM-K64F | mbed Servo Arm Double Servo Arm X-Long 1 $             3.20 http://www.hobbyking.com/hobbyking/store/__19468__CNC_Alloy_Double_Servo_Arm_X_Long_Futaba_.html Servo Arm Heavy Duty Alloy Arm 1 $             5.63 http://www.hobbyking.com/hobbyking/store/__18350__Heavy_Duty_Alloy_1in_Servo_Arm_Futaba_Red_.html Servo Linkage Alloy Pushrod with Ball-Link 65mm 1 $             2.10 http://www.hobbyking.com/hobbyking/store/__25834__Alloy_Pushrod_with_Ball_Link_65mm.html Lazy Susan Shepherd 6 in. Lazy-Susan Turntable 1 $             4.49 http://www.homedepot.com/p/Shepherd-6-in-Lazy-Susan-Turntable-9548/100180572#.UYk5UqLql8E Metal Rod 3/8 in. x 36 in. Zinc Threaded Rod 1 $             2.87 http://www.homedepot.com/p/3-8-in-x-36-in-Zinc-Threaded-Rod-17340/202183465#.UYk5pqLql8E Frame 1/2 MDF 2ftx4ft 1 $           10.45 http://www.homedepot.com/p/1-2-in-x-2-ft-x-4-ft-Medium-Density-Fiberboard-Handy-Panel-1508108/202089097?N=btn1#.UYk6CqLql8E   The build   Two main pieces to construct in this phase.  The base turret and the actual hacking of the Nerf gun.   All your base.. The base of the turret is pretty rudimentary, lot's of room for improvement here.  I used 1/2 MDF and some carpentry skills.  Here is some instruction on how to build a MDF box.  Atop the box is a lazy Susan (ball bearing ring) so that the top-plate can rotate smoothly.  We considered leaving this element out, but worried that it would put to much strain on the servo.   On the subject of servos, a few tidbits of wisdom for you as you build this thing.  First, the left/right servo needs to be dead center of the lazy susan, if your off too much things will start to bind which is not good for your servo.  Second, I used large higher torque servos which cost a bit more, they might be overkill, but it certainly performs well.   I did a quick dimensionally accurate rendering of the design in Sketchup. Files are here.   Hacking the Nerf   Now for the fun stuff.   There is no shortage of screws with this Nerf Gun.  So get out your Phillips screwdriver and go to town. There are two electrical systems in the Nerf that we are going to tap into.  One is the power switch and the other is the electrical trigger. This is the electrical trigger.  The trigger goes to our relay, which is either on or off.  We did try at first to use a 7.2V R/C car battery, but the Nerf draws too much power and didn't fire.  Going up to a 11.1V LiPo fixed that right up. This is the power switch. In Nerfinator 1.0 everything was hardwired together, which prevented us from completely pulling the Nerf from the base and made repairs difficult to say the least.  Nerfinator 2.0 we put this handy connector which allowed us to completely and easily remove the Nerf from the base.  Shipping this thing around the country will take a toll on it!  On that subject, Nerf 1.0, stopped cycling to the next position for us at the Austin Mini Maker Faire.  After a through inspection of the operational mechanics inside the Nerf (really cool BTW) it was a little bitty spring that was causing the piston not to fully retract.  We replaced the spring with 1/2 a ballpoint pin spring and to our surprise it all worked again. Electrical Connection Diagram   Added High-Level Block Diagram.  Need to add pinouts.  You'll have to read the code for now to figure it out.     Code   Mbed was the programming tool of choice for this build.   Receive Side (RX) - The receiver is the base side.  This one takes input from the remote and controls the servo movement. NerfGun_nRF24L01P_RX - a mercurial repository | mbed Transmit Side (TX) - The transmitter is the remote side.  This one senses the users movement (accelerometer) and sends that data to the base station. NerfGun_nRF24L01P_TX - a mercurial repository | mbed   Finishing Touches   In the first passes of this build we just used a bare development board as the remote control.  We found that when given the remote they would not orientate it properly, so 3D Printed Controller STL files   Development Team John McLellan - Amplification/Motivation Clark Jarvis - Software/Hardware Iain Galloway and Angus Galloway - Design and print of controller FRDM_case_sunday_PART_REV_001.STL.zip
View full article
  i.MXRT系列具有内部ROM,并且ROM中暴露出了一些功能接口可供用户直接使用。 本文介绍了Flexspi Nor ROM APIs, 并且列举了API相关的参数及示例程序。 通过这些API可以很方便的操作外部Flexspi Nor Flash。用户无需关系细节。   Products Product Category NXP Part Number URL MCU MIMXRT1060 https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/i-mx-rt-crossover-... MCU MIMXRT600 https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/i-mx-rt-crossover-...   Tools NXP Development Board URL i.MX RT1060 Evaluation Kit https://www.nxp.com/design/development-boards/i-mx-evaluation-and-development-boards/mimxrt1060-evk-... i.MX RT600 Evaluation Kit https://www.nxp.com/design/development-boards/i-mx-evaluation-and-development-boards/i-mx-rt600-eval...   SDK SDK Version URL MCUXpresso SDK Builder https://mcuxpresso.nxp.com/en/welcome
View full article
Android Open Accessory support allows external USB hardware (an Android USB accessory) to interact with an Android-powered device in a special accessory mode. When an Android-powered powered device is in accessory mode, the connected accessory acts as the USB host (powers the bus and enumerates devices) and the Android-powered device acts in the USB accessory role. This ADK library is based on NXP Kinetis Microcontroller KL26, It implements some functions to communicate with android phone.  
View full article
The purpose of this project is the control of a RGB LED panel using the FlexIO peripheral included in the Kinetis K82 microcontroller. The FlexIO peripheral offers a great advantage, unloading the CPU in the process of refreshing the LED color and brightness information, comparing with other control methods using GPIO bit-banging or PWM + DMA. I will use different method. The panel will use LED stripes with the WS2812B controller. We will also have a simulation platform for developing the applications. Hardware: 30 x16 LED WS2812B Panel Multiplexer board FRDM-K82 Uctronics QVGA display Software: IAR Workbench 7.50.1 SDK 1.3 for the Kinetis K82 FreeRTOS eGUI graphic library You can watch the video with the LED panel working: Video Link : 4707 Part 1: Building the LED Panel Part 2: LED control method using the FlexIO Part 3: Software for LED Panel emulation Part 4: Software for panel control
View full article
Demo This demonstration provides an overview of developing with the various components of the LPCXpresso Ecosystem, showing the main features of the LPCXpresso IDE tools, from project import/creation to multi-core debug, trace and power measurement. A variety of LPCXpresso development boards with their built in LPC-Link2 debug probes will be shown off in conjunction with the LPCXpresso IDE.  The LPCOpen peripheral drivers and examples will be used, demonstrating features of several of NXP's low power and flexible LPC MCU families     For more information : LPCXpresso IDE http://www.nxp.com/pages/:LPCXPRESSO LPCXpresso Boards http://www.nxp.com/pages/:LPCXPRESSO-BOARDS http://www.nxp.com/pages/:LPCXPRESSO-BOARDS  LPC Low Power 32-bit Microcontrollers http://www.nxp.com/pages/:LPC-ARM-CORTEX-M-MCUS     Video Link
View full article
UDOO Neo has been designed primarily as a complete pocket-size wireless solution for Internet of Things (IoT) and connected device development, featuring Wireless N and Bluetooth 4.0 LE on-board connectivity. Furthermore, the new board will also integrate a three-axis accelerometer, gyroscope and magnetometer, allowing it to sense its position in any given environment.         Features   Links http://www.udoo.org/udoo-neo-the-wireless-playground-for-the-internet-of-things-that-fits-in-your-pocket/ http://www.udoo.org/udoo-neo/ ARM Cortex-A9|i.MX 6 Multicore Processors|NXP Mobile World Congress, and what UDOO Neo represents in the IoT space - UDOO Board Image   UDOO Neo projects walkthrough:    
View full article
    Description: Teensy 3.1 and Teensy-LC are a complete USB-based development tools featuring respectively the Kinetis 32-bit Cortex-M4 K20 and Cortex-M0+ KL26 devices running @ 72 and 48 MHz. Teensy 3.1 is equipped with 256KB flash and 64KB RAM. Teensy-LC board is equipped with 62KB flash and 8KB RAM.   Value Propositions * Very small footprint development tools * Very Low Cost dev tool * They are able to implement many different projects * Open source SDKs   Teensy board with very high extended-Arduino compatible performance levels and libraries taking advantage of Kinetis features like low power modes and internal DMA. Libraries for LED (WS2811) and 16bit 44.1kHz audio quality is where Makers go when they need quality, performance and small size. FEATURES Hardware Specifications Specification Teensy LC Teensy 3.0 Teensy 3.1 & 3.2 Units Processor MKL26Z64VFT4 32 bit ARM Cortex-M0+ 48 MHz MK20DX128 32 bit ARM Cortex-M4 48 MHz MK20DX256 32 bit ARM Cortex-M4 72 MHz Flash Memory 62 128 256 kbytes RAM Memory 8 16 64 kbytes EEPROM 1/8 (emu) 2 2 kbytes I/O 46, 5 Volt 34, 3.3 Volt 34, 3.3V, 5V tol Analog In 8 14 21 PWM 9 10 12 UART,I2C,SPI 1,1,1 3,1,1 3,2,1 Price $24.00 $19.00 $19.80 USD   Software Enablement Teensy 3.2 & 3.1: New Features https://www.pjrc.com/store/teensylc.html     RECOMMENDED PRODUCTS Product Description Kinetis K Microcontroller Kinetis L Microcontroller RESOURCES Title Type PJRC (Teensy Official Website) Web Page
View full article
本文说明S32G HSE On-demand SMR验证的应用方法,本文演示的示例应用为: Secure Bootloader对Linux Bootloader fip.bin的验证 目录 1    背景说明与参考资料... 2 1.1  背景说明... 2 1.2  参考资料... 3 2    S32G On-demand SMR Verification说明... 4 2.1  SMR Verify的说明... 4 2.2  On-demand SMR Verify. 4 3    环境搭建... 5 3.1  EB配置说明... 5 3.2  ATF编译说明... 8 3.3  镜像烧写... 9 4    Bootloader代码开发... 9 4.1  OnDemand SMR install 9 4.2  OnDemand SMR verify. 13 5    测试... 16 5.1  Lauterbach跟踪... 17 5.2  Fip.bin破坏实验... 19 5.3  硬件确认... 19   This application doc explains the application method of S32G HSE On_demand SMR verification. The example application demonstrated in this doc is: Secure Bootloader verification of Linux Bootloader fip.bin This application doc explains the application method of S32G HSE On_demand SMR verification. The example application demonstrated in this doc is: Secure Bootloader verification of Linux Bootloader fip.bin Contents 1    Background Description and Reference Materials. 2 1.1  Background Description. 2 1.2  Reference Materials. 3 2    S32G On-demand SMR Verification. 4 2.1  SMR Verify. 4 2.2  On-demand SMR Verify. 4 3    Build the Development Environment 5 3.1  EB Configuration. 5 3.2  ATF Compiling. 8 3.3  Burn Image. 9 4    Bootloader Codes Development 9 4.1  OnDemand SMR install 9 4.2  OnDemand SMR verify. 13 5    Testing. 16 5.1  Lauterbach Tracking. 16 5.2  Fip.bin Broken Test 19 5.3  Probe the Hardware. 19
View full article
this doc and project explain how to integrate S32G M stby demo and Linux STR demo to one demo to achieve the fast boot, chinese version: 本文说明如何在S32G2 RDB2板上搭建 一个M7 MCAL Standby Fullboot GPIO resume Demo加A53 Suspend to RAM的Demo,主要的 应用场景是电动汽车的快速启动。 G3与更新版本BSP的支持情况与此类 似,不再另外说明,客户可以自行参考开发。 请注意本文为培训和辅助文档,本文不是 官方文档的替代,请一切以官方文档为准。     目录 1 参考资料说明与声明 .................................................. 2 2 STBY+STR的硬件注意点 .......................................... 3 3 修改M7 MCAL Standby Demo代码 ............................ 5 3.1 Clock相关修改 ........................................................ 5 3.2 MCU相关修改 ......................................................... 5 3.3 UART Clock相关修改 ............................................. 7 3.4 Port相关修改 .......................................................... 7 3.5 I2C相关修改 ........................................................... 7 3.6 实现M核进入STDY状态等待功能 ........................... 8 3.7 Main函数的修改 ..................................................... 8 4 修改Bootloader工程来支持同时Boot M/A核Demo ... 10 4.1 I2C Clock相关修改 ............................................... 10 4.2 Port相关修改 ........................................................ 11 4.3 其它修改 ............................................................... 12 5 修改A53 Linux代码 .................................................. 13 6 Demo 运行测试 ........................................................ 13 6.1 硬件连接 ............................................................... 13 6.2 镜像烧写 ............................................................... 13 6.3 Demo运行 ............................................................ 14 7 工程发布包............................................................... 15 8 未来开发建议 ........................................................... 17 8.1 M/A核同步机制 ..................................................... 17 8.2 功能安全与信息安全 ............................................. 17 9 遗留问题 .................................................................. 17 9.1 IPCF STR支持 ...................................................... 18 9.2 PFE Slave STR支持 ............................................. 18 注意以下说明与声明: 说明: 汽车网关有快速启动要求,而电动车因为驻车时有更大的电池提供待机电源,所以希望是使 用Linux 的suspend to ram 的功能来实现Linux 的快速启动,而在S32G 上则需要考虑将M 核的 Standby 功能 与A 核的STR 功能 结合起来,目前可用的资源包括:  从BSP32 起支持ATF,可以支持Linux 端的STR 功能,文档《S32G_Linux_STR_V1-*.pdf》 (John.Li)说明linux STR 的原理和与M7 Standby Demo 结合时所需要的修改。  NXP 的M7 内部standby demo,可以支持M 核端的standby 功能,支持full boot 和standby ram boot。文档《S32G_Standby_Demo_V4-*.pdf》(John.Li)有详细说明,本文使用MCAL full boot+GPIO resume Demo。  本Demo 与本文主要说明如何将这两个Demo 结合起来,形成一个整体的Demo。  由于需要Boot M 核加A 核,所以也需要Bootloader 工程的支持,文档 《S32G_Bootloader_V1-*.pdf》(John.Li)说明了如何创建一个MCAL sample 加Linux 的 Bootloader 工程。 声明: 请注意:  M7 standby demo 本来为NXP 内部Demo,不保证运行质量。而Linux 本身也是reference software。  Linux STR 本身会引入比较复杂的电源管理切换,也会引起系统级的不稳定性。  本文所说的方法也是实验性质,不保证运行质量。 所以客户应该谨慎决定其产品功能并自行保证其产品质量,本文及本Demo 仅为Demo 性质。   This article explains how to build a demo of M7 MCAL Standby Fullboot GPIO resume Demo plus A53 Suspend to RAM on the S32G2 RDB2 board. The main application scenario is the quick start of electric vehicles. The support situation of G3 and the newer version of BSP is similar to this, no further explanation is given, customers can refer to it for development by themselves.  Please note that this article is a training and auxiliary document. This article is not a substitute for the official document. Please refer to the official document. Contents 1    Reference materials and statement 2 2    STBY+STR hardware checkpoints. 3 3    Modified M7 MCAL Standby Demo codes. 5 3.1  Clock modification. 5 3.2  MCU related modification. 6 3.3  UART Clock related modificaiton. 7 3.4  Port related modification. 8 3.5  I2C related modification. 8 3.6  Enable the waiting function of M core entering STDY. 9 3.7  Main function modification. 9 4    Modify the Bootloader project to support simultaneous M/A core demo  11 4.1  I2C Clock related modification. 11 4.2  Port related modifcaiton. 11 4.3  Others modificaiton. 13 5    Modify A53 Linux codes. 14 6    Demo running and testing. 14 6.1  Hardware link. 14 6.2  Image burning. 14 6.3  Demo running. 15 7    Project release package. 16 8    Suggestion for the future development 17 8.1  M/A core sync mechanism.. 17 8.2  Function safety and Information security. 17 9    Remaining issues. 18 9.1  IPCF STR support 18 9.2  PFE Slave STR support 18   as need refer:   S32G_Linux STR This doc explain S32G Linux STR details and modify to integrate with M stdy demo https://community.nxp.com/t5/NXP-Designs-Knowledge-Base/S32G-Linux-STR/ta-p/1652680 S32G Standby Demo the project build a new Mcal standby demo and explain its details https://community.nxp.com/t5/NXP-Designs-Knowledge-Base/S32G-M-kernel-Standby-demo-and-how-to-porting-to-Mcal/ta-p/1556313 S32G Boot customization doc how to run bootloader to run mcal&linux https://community.nxp.com/t5/NXP-Designs-Knowledge-Base/S32G-Bootloader-Customzition/ta-p/1519838
View full article
This project include the codes and doc to support optimize the EMI of S32G by frequency changing and SSC. Contents as follows: 目录 1 展频的基本概念 ......................................................... 2 2 获取测试用uboot源代码 ............................................. 5 3 DDR_PLL的改频 ........................................................ 5 4 DDR_PLL的展频 ........................................................ 9 5 总结修改后的源代码 ................................................ 17
View full article
Demo Advantages of i.MX6 Dual/Quad Plus Features Memory bandwidth utilization greatly improved On-die caches for GPU Multi-source GPU composition Featured NXP Products i.MX6DP i.MX6QP
View full article
Demo Owner: Derek Snell   This demo combines several solutions from NXP and our partners. The demo is a thermostat application, using the Kinetis family as a communication gateway between a ZigBee network and connecting to the cloud. The demo runs on the MQX Real-Time Operating System (RTOS). It also uses the NXP PEG graphics library for the user interface displayed on an LCD. The ZigBee communication uses NXP’s BeeStack ZigBee stack, and connects with an NXP wireless development board programmed as a remote temperature sensor. The demo will also connect with an off-the-shelf ZigBee light bulb, and wirelessly controls it. The demo network connection is setup for Wi-Fi, using a Wi-Fi module from Qualcomm. The cloud connection allows the thermostat to be monitored and controlled remotely with mobile devices, and uses a solution provided by deviceCloud.io.     NXP Products Product Link Shield Adapter Module for the Tower System Shield Adapter Module for the Tower System | NXP  Kinetis® KW2x Tower System Modules TWR-KW2x|Tower System Board|Kinetis® MCUs | NXP  Kinetis K70 120 MHz Tower System Module TWR-K70F120M|Tower System Board|Kinetis MCUs | NXP  Serial (USB, Ethernet, CAN, RS232/485) Tower System Module Serial (USB, Ethernet, CAN, RS232/485) Tower System Module | NXP  Graphical LCD Tower System Module with RGB Interface Graphical LCD Tower Module with RGB Interface | NXP    Design Resources Getting Started Guide Development Tools Thermostat Demo Software Firmware updated to v1.0 on 9/9/14      - DCIO Cloud agent now uses SSL from WolfSSL.  This improves WebSocket connections to cloud server through some protected networks. Firmware updated to v0.8 on 7/15/14      - Updated to support latest GT202 shield hardware from Qualcomm.  Rev 1.3 and newer boards changed pinout of CHIP_PWD signal. Firmware updated to v0.7 on 6/20/14      - Updated to use new SNTP server.  Previous server stopped responding and prevented cloud connection. Getting Started guide updated to v0.4 on 7/15/14
View full article