Writing this post just want to remind the customer of RAM allocation when use the on-chip CAN drivers in LPC11C24. Otherwise, when meet the abnormal issues, it is difficult to locate the root reason and it also causes a waste of time.      Now, take a real customer question as an example, to highlight the RAM allocation importance when using the on-chip CAN API in LPC11C24. Problem description     Customer used the LPC11C24 on-chip CAN API to realize the CAN frames sending and receiving, the CAN code was from the official lpcopen, and it worked OK when he just used the CAN code. But when customer added the UART code, they found the code always enter hardfault after a short time running. They test the UART code which without the CAN code directly, the UART code worked perfectly. It means, independent UART code and independent CAN code are all working normally, but when combine the UART and on-chip CAN code together, the code will enter hardfault. Problem analysis From the Cortex M0 devices generic user guide, we can get the information about the hard fault:     Faults are a subset of exceptions, see Exception model. All faults result in the HardFault exception being taken or cause lockup if they occur in the NMI or HardFault handler. The faults are:      execution of an SVC instruction at a priority equal or higher than SVCall      execution of a BKPT instruction without a debugger attached      a system-generated bus error on a load or store      execution of an instruction from an XN memory address      execution of an instruction from a location for which the system generates a bus fault      a system-generated bus error on a vector fetch      execution of an Undefined instruction      execution of an instruction when not in Thumb-State as a result of the T-bit being previously cleared to 0      an attempted load or store to an unaligned address Now we debug the problem project to check, which detail code line caused this hardfault problem. When the code enters the hardfault handler, check the MSP address in the flash, then find the LR register, which will link to the code before entering in the hardfault handler, the following are the according debug result:   The LR register is 0X1FFF2C1F, it means before enter in hardfault handler, the code runs to this address code. Now, check the 0X1FFF2C1F in the memory map.    We can find the address is in the ROM area, because we just use the ROM CAN driver, UART is just the pure register control code, then we can get the problem still relate to the on-chip CAN driver, not the UART code. But we can’t see or debug the detail ROM CAN driver directly, we still can’t find the root problem.    Even we know the problem is not caused by the UART, but another important clue which relates to the UART function also influence the test result after I do a lot of testing. In the customer code, he defines the UART user transmit and receive buffer like this: #define UART_SRB_SIZE 128    // Send #define UART_RRB_SIZE 32    // Receive /* Transmit and receive buffers */ static uint8_t rxbuff[UART_RRB_SIZE], txbuff[UART_SRB_SIZE];   On one occasion, I tried changing #define UART_SRB_SIZE 128 To  #define UART_SRB_SIZE 32 Just minimize the txbuff size, I found the code won’t enter in the hardfault handler any more. It seems very strange and contradiction with the hardfault handler enter point which is test before.    I also check the generated code size, the used RAM and flash size is:   text       data        bss        dec        hex    filename    7672          0        244       7916       1eec    pscan.axf LPC11C24 RAM is 8K, here just 244 Bytes, the stack also use the whole RAM, so the 8K RAM size should be enough to use.   In this situation, I check the project’s .map file about the txbuff with 128 and 32 respectively.    1)txbuff with 128Bytes Rxbuff and txbuff occupy the RAM address from 0X10000048 to 0X100000E8.     2)txbuff with 32Bytes Rxbuff and txbuff occupy the RAM address from 0X10000048 to 0X10000088. We can find the txbuff start address is the same, just the end address has difference.    With these information, we checked the LPC11C24 user manual chapter C_CAN on-chip drivers again, we found a significant description:      0X10000050 to 0X100000B8 is used by the on-chip CAN API RAM, and from the issue project, memory map file, we can find rxbuff and txbuff RAM address is 0X10000048 to 0X100000E8, it already occupies the whole CAN API RAM, this is the key point. Minimize the txbuff, then rxbuff and txbuff occupy the RAM address from 0X10000048 to 0X10000088, this address doesn’t occupy the whole on chip CAN API RAM, in this situation, the problem doesn’t happen, I think the used CAN API may in the RAM address 0X10000089-0X100000B8.    Anyway, just minimize the buffer size can’t solve the problem from the root side. We must follow the user manual to keep the RAM address from 0x10000050 to 0x100000b8 won’t be used by any other application code.   Problem solutions      From the above chapter, we can find the root problem is the application code occupies the on-chip CAN RAM, to solve the problem, we need to modify the linker file, to prevent the usage of on-chip CAN RAM range.      Because the customer is using the LPCXPresso IDE, then we take this IDE as an example, to protect the RAM address 0x10000050 to 0x100000b8. From the above, we can get that the LPCX11C24 have 8Kbytes RAM, normally, customer will define it just in one, now we divide the RAM to two pieces. 1) RAM2: Location 0X10000000, size 0X100 2) RAM: Location 0X10000100, size 0X1F00 In the LPCXpresso, Project Properties -> C/C++ Build -> MCU settings, then modify it like this:     Then generate the code, and check the map file again.   RAM address from 0x10000000 to 0X10000FF is not used by any other application code. All the application code RAM is using from address 0x10000100. After long time testing, we find the hardfault problem never happens, on customer side, it also works OK. In conclusion, when customer want to use the on-chip CAN API, they need to protect the RAM address from 0x10000050 to 0x100000b8 in the linker file.    

This document describes how to create a new LPC project using LPCOpen v2.xx, LPCXpresso v8.2.2 and LPC11U24 LPCXpresso board. In addition describes how to create 2 simple example codes. Blinking LED. Set the LED using a push bottom.  LPCOpen LPCOpen is an extensive collection of free software libraries (drivers and middleware) and example programs that enable developers to create multifunctional products based on LPC microcontrollers. After install LPCXpresso, the LPCOpen packages for supported board(s)/device(s) can be found at the path: <install_path>\lpcxpresso\Examples\LPCOpen > This directory contains a number of LPCOpen software bundles for use with the LPCXpresso IDE and a variety of development boards. Note that LPCOpen bundles are periodically updated, and additional bundles are released. Thus we would always recommend checking the LPCOpen pages to ensure that you are using the latest versions. This example was created using the LPC11U24 LPCXpresso board in this case the drivers selected is lpcopen_v2_00a_lpcxpresso_nxp_lpcxpresso_11u14.zip Importing libraries In order to create a new project, it is necessary to first import the LPCOpen Chip Library for the device used and optionally the LPCOpen Board Library Project. For do that it is necessary to follow these steps: 1. Click on Import project(s). 2. Select the examples archive file to import. In this case, the projects imported are contained within archives .zip.  3. For this example the LPC11U14 LPCXpresso board is selected. Click Open. Then click Next 4. Select only the LPCOpen Chip Library and LPCOpen Board Library Project. Click Finish. The same steps are required for any LPC device and board you are used. Creating a new LPC project.   The steps to create a new LPC project are described below: 1. In Quickstar Panel, click "New project"   2. Choose a wizard for your MCU. In this case LPC1100/LPC1200 -> LPC11Uxx -> LPCOpen-C Project This option will link the C project to LPCOpen. Then click Next.   3. Select the Project name and click Next.   4. Select the device used (LPC11U24 for this case) and click Next.   5. Select the LPCOpen Chip Library and LPCOpen Board Library, these projects must be present in the workspace.   6. You can set the following option as default clicking Next, then click Finish.   7. At this point, a new project was created. This project has a src (source) folder, the src folder contains: cr_startup_lpc11uxx.c: This is the LPC11Uxx Microcontroller Startup code for use with LPCXpresso IDE. crp.c: Source file to create CRP word expected by LPCXpresso IDE linker. sysinit.c: Common SystemInit function for LPC11xx chips. <name of project> my_first_example: This file contains the main code.     8. LPCXpresso creates a simple C project where it is reading the clock settings and update the system core clock variable, initialized the board and set the LED to the state of "On". 9. At this point you should be able to build and debug this project.   Writing my first project using LPCXpresso, LPCOpen and LPC11U24.   This section describes how to create 2 simple example codes. Blinking LED. Set the LED using a push bottom. The LPCOpen Chip Library (in this case lpc_chip_11uxx_lib) contains the drivers for some LPC peripherals. For these examples, we will use the GPIO Driver. The LPCOpen Board Library Project (in this case nxp_lpcxpresso_11u14_board_lib) contains files with software API functions that provide some simple abstracted functions used across multiple LPCOpen board examples. The board_api.h contains common board definitions that are shared across boards and devices. All of these functions do not need to be implemented for a specific board, but if they are implemented, they should use this API standard.   After create a new project using LPCXpresso and LPCOpen, it is created a simple C project where it is initialized the board and set the LED to the state of "On" using the Board_LED_Set function.   int main(void) {   #if defined (__USE_LPCOPEN)     // Read clock settings and update SystemCoreClock variable     SystemCoreClockUpdate(); #if !defined(NO_BOARD_LIB)     // Set up and initialize all required blocks and     // functions related to the board hardware     Board_Init();     // Set the LED to the state of "On"     Board_LED_Set(0, true); #endif #endif       // TODO: insert code here       // Force the counter to be placed into memory     volatile static int i = 0 ;     // Enter an infinite loop, just incrementing a counter     while(1) {         i++ ;     }     return 0 ; }       a. Blinking LED. In board_api.h file there is an API function that toggle the LED void Board_LED_Toggle(uint8_t LEDNumber);  LEDNumber parameter is the LED number to change the state. The number of the LED for the LPCXpresso LPC11U24 is 0. It is easy to create a delay function using FOR loops. For example: void Delay (unsigned int ms) {         volatile static int x,y;           while (ms)         {                 for (x=0; x<=140; x++)                 {                         y++;                 }                 ms--;         } } In order to have the LED blinking, it is necessary to call these functions in an infinite loop. while(1) {                 Board_LED_Toggle(0);                 Delay (10000);         } Complete code (Blinking LED). int main(void) { #if defined (__USE_LPCOPEN)         // Read clock settings and update SystemCoreClock variable         SystemCoreClockUpdate(); #if !defined(NO_BOARD_LIB)         // Set up and initialize all required blocks and         // functions related to the board hardware         Board_Init();         // Set the LED to the state of "On"         Board_LED_Set(0, true); #endif #endif          while(1) {                 Board_LED_Toggle(0);                 Delay (10000);         }         return 0 ; }  void Delay (unsigned int ms) {         volatile static int x,y;         while (ms)         {                 for (x=0; x<=140; x++)                 {                         y++;                 }                 ms--;         } }      b. Set the LED using a push bottom. For this example it is necessary to configure a pin as input.  The gpio_11xx_1.h file contains all the function definitions for the GPIO Driver. The example uses the pin 16 of port 0 to connect the push bottom. The function Chip_GPIO_SetPinDIRInput(LPC_GPIO_T *pGPIO, uint8_t port, uint8_t pin) sets the GPIO direction for a single GPIO pin to an input. In order to configure the Port 0, pin 16 as input we can use this function: Chip_GPIO_SetPinDIRInput(LPC_GPIO, 0, 16); Then, it is necessary to check the status of this pin to turn-on/turn-off the LED. The function Chip_GPIO_GetPinState(LPC_GPIO_T *pGPIO, uint8_t port, uint8_t pin) gets a GPIO pin state via the GPIO byte register. This function returns true if the GPIO is high, false if low. State_Input=  Chip_GPIO_GetPinState (LPC_GPIO, 0, 16);   Complete code (Set the LED using a push bottom). int main(void) {         bool State_Input;   #if defined (__USE_LPCOPEN)     // Read clock settings and update SystemCoreClock variable     SystemCoreClockUpdate(); #if !defined(NO_BOARD_LIB)     // Set up and initialize all required blocks and     // functions related to the board hardware     Board_Init();     Chip_GPIO_SetPinDIRInput(LPC_GPIO, 0, 16);     // Set the LED to the state of "On"     Board_LED_Set(0, false);  #endif  #endif      while(1) {           State_Input=  Chip_GPIO_GetPinState (LPC_GPIO, 0, 16);              if (State_Input==0){                 Board_LED_Set(0, true);             }             else {                 Board_LED_Set(0, false);             }     }     return 0 ; }   I hope this helps!! Regards Soledad

This content was originally contributed to lpcware.com by George Romaniuk     This project included testing the performance of the SPIFI interface on LPC4350. Example files were modified to run the M4 core at 200MHz and read and write to SPIFI attached FLASH. Timer was added to measure the execution and data transfer time. Reads were at an amazing 44.9MByte/s; writes were much slower due to FLASH. In addition to SPIFI, some DSP routines were timed and performance was documented.

Today's Data Acquisition Applications require separate ICs for input, processing, and output. With the new LPC4370, designers have a complete data acquisition solution on a single chip. With the release of NXP’s new LPC4370 Cortex-M4F microcontroller, we wanted to provide engineers with the tools necessary to evaluate its high-performance signal processing capabilities (up to 204 MHz) and its host of advanced features and peripherals including the 12-bit ADC at 80 Msps with up to six channels.   The result is a new product from Embedded Artists, named LabTool.  LabTool is as an add-on board to NXP’s LPC-Link 2 debugger and demoboard platform.  The LabTool includes a hardware daughter board and software running on the PC that enables the Link2 to be used as a logic analyzer, oscilloscope, and signal generator. It is designed around NXP’s new LPC4370 microcontroller, and the hardware can serve as a development platform for this MCU.   LPC4370 and LabTool Key Components Follow the URLs in the table to find more information on the product and its key components. LPC4370 The LPC4370, ARM Cortex-M4F based microcontrollers, are complete data acquisition solutions on a single chip. The LPC4370 provide the fast digital and analog inputs, the high performance processing capabilities, and the hi-speed output needed for data acquisition applications. Running up to 204MHz, the ARM Cortex-M4F of the LPC4370 is the industry’s fastest Cortex-M microcontroller. The Cortex-M4F is a next generation 32-bit core that offers system enhancements such as low power consumption, enhanced debug features, and a high level of support block integration. Download the LPC4370 documentation: LPC4370 BGA256 Product Information Page LPC4370 BGA100 Product Information Page LPC4370 User Manual and Data Sheet LPC4300 Series Leaflet LPC-Link2 LPC-Link 2 is an extensible, stand-alone debug probe that can be configured to support various development tools and IDEs using a variety of different downloadable firmware images. It can also be used as an evaluation board in its own right for the NXP LPC4370 triple core MCU. And through the use of an add-on board from Embedded Artists, it can be used as an oscilloscope or logic analyzer! For more information on the Link 2, view our NXP.com page. LabTool LabTool can be purchased as a kit that includes the Link2 main board plus the add-on board, or the two can be purchased separately.  A connector with 26 probe wires is included, and is the only accessory required for using the tool.  The probes feature a 2.54mm pigtail end, for easily connecting to headers and jumpers on a target platform.  A set of compatible microgrippers may also be useful, but must be purchased separately. Purchase LabTool, download documentation and the GUI at Embedded Artists product page.   LabTool also available for purchase at: Watch the video here.   LabTool Features   The LabTool consists of both a hardware platform and a software GUI, which combine together in providing the following set of features that are commonly used by electronic designers during bench debugging.  A standard 5.0V supply from your high-speed USB2.0 connector provides the power needed to operate the board, as well as the high-speed communication channel for the data stream.   Digital Channels 10 channel logic analyzer supporting 100MHz (2ch), 80Mhz (4ch), 50MHz (8ch), 20MHz (10ch) Selectable edge-sensitive and level-sensitive triggers give you flexibility in how the signal is displayed. 11 channel digital signal generator up to 80Mhz, at 3.3 volts logic level. Included with the digital interface are three protocol analyzers.  You can monitor SPI, I2C and UART with a built-in interpreter that shows the timing of clock and data transfers in the GUI. Demonstration signals are provided already on the board, by means of an LPC812 microcontroller.  This devices generates heartbeat PWM, four digital counters (at 750KHz, 1.5MHz, 3.0Mhz and 6.0MHz), plus SPI, I2C and UART data streams.  These signals can be used for quickly verifying the tools is up and running, and provides reference signals for comparing to your own design when measured by the LabTool.   Analog Channels   2 channel oscilloscope sampling at 80Msps (1ch), 40MHz (2ch), with 6MHz bandwidth rating.  The voltage range that can be sampled is a very wide range at +/- 25 volts.  Input impedance is 1Mohm. 2 channel analog output generation at 40KHz bandwidth, at +/- 5 volts.  Three built-in waveform generators support sine, square and triangle waveforms.   GUI   LabTool comes with a feature rich software interfaced developed by Embedded Artists.  The GUI gives users the capability to manage the digital and analog channels through: Dialogs for selecting digital and analog inputs channels One-shot and continuous sampling Sorting and moving of signals Applying application-specific signal names Saving settings in a project file Exporting collected data to .csv formatted files Appling SPI, I2C or UART protocol analyzers to selected channels Using four cursors to measure and interpret waveforms     Open Source Environment   The GUI is developed using Qt framework, and can be provided as open source. Source code for the firmware operating on the LPC4370 is also planned to be released for use among the community of NXP users.  Developers are encouraged to use this firmware as a starting point for creating exciting new applications based on LPC4370! Getting Started   A comprehensive user guide for the LabTool is available from Embedded Artists at the link given above. Tips for getting started:   Refer to the user guide and notes on Embedded Artists web site for the most recent instructions.  Here are some tips that have helped our testers and expert industry users to get started smoothly.   Install the GUI software first.  USB drivers (needed at step #2 below) are copied to the installation folder during this step. Attach the LabTool add-on board to the Link2 (see image below for proper orientation). Driver installation may take several minutes, and is accomplished in two steps.   When the hardware is first connected to a USB port, the driver for the Link2 must be installed.  This driver is included with the LPC-Link2 Configuration Tool.  The device manager shows the hardware is enumerated as “LPC Device”. Once the Link2 driver is loaded, the next step allows the LabTool GUI to be started.  The first time the GUI runs, it will detect the LabTool hardware, and will load an additional driver.  This driver is located in a sub-folder from the location where the LabTool software package was installed.  The device manager shows the hardware is now enumerated as “NXP LabTool”   Once the GUI is running, check that “LabTool Device” is displayed in the section marked “Selected device” in the diagram above. The probe bundle has each wire function labeled on the silk screen of the PCB.  Check these carefully to find cable D0, and connect it to the demonstration signal  labeled “PWM_LED” on the header at the bottom right corner of the board.  In the GUI, choose “Add Signal” and select D0 as an input channel; press OK.  Set a falling edge trigger and a sample rate of 2MHz.  Choose continuous sampling, and view the results in the waveform view.  It’s that simple!   Correct Orientation   Correct orientation is required.  Be sure the expansion headers on the Link2 are aligned properly to the connectors on the LabTool add-on board.  The USB port is located at the end opposite from the BNC connectors.     Industry Experts and NXP Testers   We asked leading experts in the embedded community to test the LPC4370 and LabTool, create some test code, and let us know what they thought of the whole process.  Below are their evaluations:   Industry Experts   Kevin Townsend has been working with LPC microcontrollers since the ARM7 LPC2000 products were released. He specializes in ARM Cortex-M0/M3/M4 design and development with interest in low power and wireless sensors. He is active in the open source HW world as Lead Engineer at Adafruit Industries. Kevin tested the LPC4370 and wrote a review on his blog site, www.microbuilder.eu. To read his insightful commentary follow this link.   Bob Boys is a Product Manager for Keil MDK and ARM DS-5 tools at ARM with multiple years of experience in the industry. He holds a Masters in Information Sciences and has worked with a variety of hardware and software platforms around the ARM Cortex family of products. Bob decided to test out the oscilliscope feature of the LabTool. See his review below.   Dirceu Rodriguez, Jr. is a computer engineer with a master's degree in electrical engineering. As an independent consultant, he tests new products with particular interest in the areas of wireless sensor networks, ARM processors, DSP, motor control, and medical applications. (Review coming soon)   Massimo Manca has 20+ years of experience in the industry. He has worked on a variety of applications with more than 30 different microcontroller families. Massimo gave the LabTool and Link2 a thorough testing on all parts.  Initial comments are provided below, with an additional review coming soon.   NXP Testers NXP Application Engineers have tested the LPC4370 and LabTool for themselves.  Their feedback and use cases are shown below.     Using the SPI Protocol Analyzer     Using LabTool to evaluate Rotary Encoder and QEI peripheral     Investigating I2C/SMBus issue using LabTool     Comparing the LabTool to a commercially available signal analyzer   Evaluations and Reports Kevin Townsend hosts a blog on his microbuilder.eu site. Read his insightful commentary here.   Bob Boys from ARM, Ltd. wrote:   I tested the scope part as this is what I am most interested in.  LabTool in this respect worked quite well compared to other USB scopes I have used that cost mush more.  I tested it on a two node CAN network and the SWO Serial Wire Output: both on a Keil MCB1700 (LPC1768) board.   I liked these things: 1)    Easy to change from neg/pos slope or no trigger. 2)    Changing the trigger point was very easy although I liked using the no trigger setting better to initially get a waveform going. 3)    Determining the timing was easy and surprisingly accurate.  At first I was getting very bad frequencies but after I calibrated the LabTool per the instruction it was fine. 4)    Setting the cursors was easy – but see point 5 below. 5)    The waveform faithfulness compared to my HP 100 mHZ scope was quite good. 6)    Installing the software was easy although I had some initial trouble with the USB drivers – it could detect it and under device the labtool Device was grayed out.  I had to uninstall the previous LPC-Link 2 USB drivers (which had worked OK for me) – it showed it was not installed correctly or something like that -  it had a small yellow icon in Device manager.  Now it works fine. 7)    Single shot and continuous collection works easier than on my HP.   I thought these could be improved: 1)    The scope selection is called Analog.  I was confused – why not just label it scope ? 2)    I had some difficulty getting a waveform displayed sometimes – I had to fiddle with it. 3)    I was not able to erase a waveform so sometimes I didn’t know if I had  a new one or nothing or ????  Making this part easier to use might be worth it. 4)    I could not make the waveform bigger or shift it up or down (position). 5)    When I clicked on a cursor icon to bring it up into the screen – the waveform shifted and it looked like (to me anyway) to have disappeared.  It was there – It took me a while to figure this out. 6)    CAN is a differential signal but it seemed to work.  A differential input would be nice.  So would a CAN Analyzer. 7)    I had a hard time getting the “DC” to work – “AC” was always better and easier. 😎    The ability to change the waveform colour might be a good idea.   Following are the results of two tests.   CAN on one channel: 1)    500 kHz is correct ! 2)    The waveform (at 80 MHz) is good – the overshoots are not visible on the HP but I didn’t adjust the tiny capacitor screws on the LabTool.  There are more of the resolution errors shown on the rise and fall edge than my HP – but HP still has some.  Not a big deal. Here is the CAN frame using two channels:  Even though I had to reduce the sampling freq to 40 mHz – it still looks good.   The ability to move the waveforms vertically (and maybe a polarity switch) would be nice.     SWO: Very often customers must measure the frequency on the SWO pin if they can’t get the Serial Wire Viewer (SWV) working and they do not know what their CPU clock is. A scope makes this easy and – LabTool did very good – I think sometimes the SWO pin can go up to 1 mHz and more – but this example at 1.25 worked fine. 1.25MHz as shown here is correct ! I compared all these waveforms to my HP and LabTool did quite well. Massimo Manca wrote:   After some hours of test my feeling is that the digital part works quite well, the I2C, SPI and UART interpreters are useful and well designed. Should be very interesting to have also a CAN interpreter and a 1-Wire interpreter.   Another thing should be useful is to define the priority of the triggers on the digital signals. I mean that should be useful for instance to define the trigger on the UART - D0 line with the highest priority so the other signals will be captured only it is already captured on its trigger front.   I should need to go back to my lab to test better the analog inputs. My feeling is that the signal is not perfect due to some interference by my laptop. Should be interesting to connect a USB isolator between the boards and the PC to see what changes.   The next step will be to test the board freely always using the demo signals without following the example list. I will provide update with the results.   Using the SPI Protocol Analyzer   Lately I’ve been working with one of NXP’s solution kits.  This kit includes an LPC812 Xpresso board and a daughterboard with the SEN300 sensor.  The sensor measures temperature, humidity and light.  It interfaces the microcontroller through a 4-wire SPI bus (SCK, MISO, MOSI, CS) running at 300kHz.   Considering that an end user of this solution kit may want to add another node on the SPI bus, it should be necessary to increase the communication rate from 300kHz to a higher speed, and allow for transfers to/from the additional device using the same SPI peripheral.  Types of SPI devices that could be considered are a simple LCD for displaying the sensor readings, or an EEPROM for data logging.   After I selected new dividers for the SPI master clock to increase the clock rate to 3MHz, the communication interface broke down.  I setup the LabTool digital interfaces D0 to D3 and configured the SPI protocol analyzer to use these for the corresponding SPI signals.  Following are some screen shots and the conclusion of the problem.   Normally the communication seemed to be occuring just fine.  I noticed that the chip select signal (Digital 3) was active low outside the boundaries of the waveform view in the LabTool GUI. From time to time, actually more often than not, the SPI analyzer could not interpret the transfer data, and showed “Frame Error” was occurring.   By changing the trigger to the rising edge of the chip select, I could see this occurring more frequently.  At that time, the chip select signal was momentarily toggling high/idle and then low/active in the middle of a data transfer.   I began stepping through the code to find the routines that set and cleared the state of the chip select (a simple digital output port).   I found that the routine that handles the SPI transmit/receive buffers could get out of sync with the function controlling the chip select output, and cause message transfers to overlap.  By adding some simple logic to ensure the chip select was not idled before the SPI buffers were serviced, the problem went away.  Here is a screen shot of a good SPI transfer at the higher SCK rate.   Using LabTool and the SPI protocol analyzer feature, I was able to identify the problem in the communication interface, and then use a debugger to finish checking the root cause.   Using LabTool to evaluate Rotary Encoder and QEI peripheral   Motor control applications often use the feedback from a rotary encoder in a closed loop control system.  The LPC4370 microcontroller includes a QEI peripheral (Quadrature Encoder Interface) that decodes these signals directly.  By monitoring both the number of pulses and the relative phase of the two signals, you can track the position, direction of rotation, and velocity.  In this example, we’ve measured the QEI signal sequence with LabTool.  The type of Rotary Encoder used in this project is SXA-4EG05E1024BM with 1024 pulses per round.   The encoder ouputs A,B and Zero terms. So we connect the encoder with LabTool through DIO0~DIO2. LabTool should also be connected with the Encoder’s gound pin to ensure they share a common gound.  Use one of the available grounding probes on the 26-pos connector (e.g. probe #4), to make this connection.   DIO0 -> A Term   DIO1-> B Term   DIO2-> Zero   Open the LabTool application program on your PC, and connect the LabTool using the USB connection. The GUI will show that LabTool is connected when the text "LabTool Device" changes from red to black text.  Now, you can click the “Add Signal” button and choose D0, D1 & D2 digital signals as below picture shows. We’ll rotate the Encoder by hand, so we set the “Sample Rate” as 100kHz.   Set the D2 Digital capture on rising edge.   Click the “Capture->Continuous” or button to start sampling the digital input channels.  When we rotate the Encoder, the signal capture below is displayed with LabTool. We can move the triggers C1&C2, C3&C4 to measure the signal’s frequency and duty cycle.   If we want to measure a whole cycle from the Encoder, we can set the “Sample Rate” as 50Mhz, then rotate the Encoder and capture the entire waveform shown next. LabTool's logic analyzer feature is very powerful and useful for motor control applications measurng the feedback from a rotary encoder.   Investigating I2C/SMBus issue using LabTool   One of our customers is designing-in the NXP Microcontroller in a SAS (Serially Attached SCSI) Server system. This controller is used to manage the overall backplane activities and interfaces to the host SAS Controller on SMBUS/I2C Bus. The customer was facing major issue of I2C Bus hanging.  As such, it was difficult to diagnose the issue as there were multiple slave devices on the bus. Coincidently, we had this LabTool lying around and I thought of using it in debugging the issue. Initially, I isolated this controller from the I2C bus and hooked it up to another I2C Master. While monitoring the bus activity on the LabTool’s I2C Analyzer, apparently the overall communication was just fine as shown below.   On a closer look, I noticed that the clock (SCL) was getting stretched a bit at times, but nothing unusual. I then connected this controller back in the system and monitored the I2C bus activity on I2C Analyzer again. And no surprise, the bus hanging problem was getting reproduced as seen in the capture below. After the clock stretching interval, the clock (D2=SCL) line was holding it’s status as low and data (D1=SDA) was high. It was clear that the problem appears only when there are multiple slaves connected to a SMBUS/I2C Bus Master. It gave me some direction to think and investigate more on similar lines. Gone through the details of SMBUS/I2C peripheral on SAS Controller and as usual googled for I2C issues with multiple slaves.  Finally got a clue while going through the minute details of SMBus specifications. Though it’s normal to use I2C slaves/devices with SMBus master and vice a versa, there are subtle differences in the specifications. The most vital difference is the Timeout and (as a consequence of timeout) minimum clock speed. There’s no time out in I2C specifications, any device can stretch the Clock as long as it wants. While the SMBus clearly specifies the time out of 35msec, where slave devices resets their interfaces whenever Clock goes low for longer than the timeout. Use of such timeout also dictates a minimum speed for the clock, because it can never go static. Thus, the SMBus has a minimum-clock-speed specification of 10kHz.   To comply with the SMBus specifications Slave devices should have this time out implemented. I then added a small piece of code to generate this timeout using one of the available timers and that resolved the issue. Thanks to the LabTool!   Comparing the LabTool to a commercially available signal analyzer   There are three key features of LabTool that are useful to any developer:   80MHz sample rate using digital inputs D0 to D3 and up to 60MHz for one Analog Input. You can analyze any UART, SPI or I2C communication. You have 4 cursors to measure your signals.   Here is a comparison versus another USB-hosted signal analyzer.  We will call it "AnalyzerB" in this article.   Features and Price: Regarding AnalyzerB, the cheaper option is the product SX at $169.0 USD, it has only 8 digital input/output with a maximum sample rate of 24MHz. The most comparable product will be the AX product with a pricing of $795 USD with also 8 digital input/output with 2 analog oscilloscope inputs but you can capture maximum at 24Msps and only one analog input at any time. The AX product also can analyze CAN, PS/2, SM bus and 1-Wire communication. These options could be added easily to the PC software.   So, the pricing of $129.00 USD for the NXP LabTool is a very good pricing and with the source code available you won't have any limit to customize or improve the LabTool.   Using the Tools: I did a zoom in the PWM signals in order to get a more detail measurement and I will compare these signals measurements with the AnalyzerB tool.     D7 is 2MHz D8 is between 3.33MHz and 5MHz D9 is between 3.33MHz and 2.5MHz D10 is between 1.42MHz and 1.66MHz I had these measurements because the sample rate is at 10MHz and LabTool is using the upper channels. Now I did a measurement using AnalyzerB tool.  It couldn’t read the 12MHz signal (channel 0); the sample rate is at 12MSPS. I had to increase to 24MSPS (MAX) in order to be able to measure the 12MHz signal. The frequency measurement in each signal was exactly 1.5MHz channel 3, 3MHz channel 2, 6MHz channel 1 and 12MHz channel 0 without any variation.   Now, using the LabTool I change the 4 PWM signals to channels 0 to 3 and increase the sample rate up to 100MHz. I had the following:   The frequency in the signals is: D0 is 12.5MHz and 10MHz D1 is 6.25MHz and 5.55MHz D2 is 2.94MHz and 3.12MHz D3 is 1.51MHz and 1.47MHz   The AnalyzerB tool didn’t show any variation in the frequency measurements. It might be because the LabTool has more precision. I went up to 100MHz sample rate and I had the same frequency measurements in each signal. Maybe the AnalyzerB is using some other method to implement an average or it might be over sampling to improve the measurement. I might need to have a third logic analyzer to see what tool is getting a right measurement.   I had some trouble using the LabTool GUI.  For example, I didn't know that LabTool is connected at first since the "LabTool Device" indication was not highlighted.  Also it was difficult to know how to choose the protocol analyzer, so that Combo Box could be improved.  It is clear that the LabTool has more resolution when using the lowest channels. The AnalyzerB tool has only a maximum of 25MSMP for all combinations. So the LabTool has an advantage because it could be 100MHz sample rate in 2 digital channels.   I like the LabTool but it might be a good idea to include test clips for each of the signals because not all the time the target circuit will have pins to plug the actual test points. These test clips will give more functionally to the LabTool.  Also, I would like to have more information about the actual LabTool system if it will be like a reference design for customer, like the source code for the LabTool software and also the firmware for the MCU.   The LabTool could be used for debugging without any issue; I think that the Start Guide should be updated with more detail information to improve the usability.