i.MX Processors Knowledge Base

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

i.MX Processors Knowledge Base

Discussions

Sort by:
      The i.MX6UL/LL/LZ processor supports 2 USB OTG interfaces, USB OTG1 and USB OTG2, and each USB interface can be configured as a device, host or dual role mode. On the EVK board of i.MX6UL/LL, USB OTG1 is designed as dual role mode, and USB OTG2 is designed as HOST mode. This is sufficient for most customers.       However, in actual applications, we may need 2 USB HOSTs, and at the same time, we don’t want to use MicroUSB to USB TYPE-AF cable for Host-Device mode conversion. Therefore, the design of the USB circuit needs to meet such requirements: 1. USB device mode We need a USB device to download the linux image to the flash or SD card on the board. 2. 2 USB HOSTs When the system is working normally, we need the board to support 2 USB HOST. i.MX6UL/LL/LZ has only 2 USB ports. How to design to meet this requirement without increasing the USB HUB? The following scheme is used as a reference, and I hope it will be helpful to customers with similar requirement:        The logic and application description of this Diagram:: Default—device mode In the process of debugging the software, we need to use the USB OTG interface to download the linux image, so it must work in device mode. What we need to do is: (1). Pull USB OTG ID up to 3.3V (2). The USB OTG D+/D- signal is switched to the MicroUSB connector. (3). The USB OTG VBUS is provided with 5V power from the external PC USB HOST. Usage:        -Use a jumper for Pin 1 and Pin2, USB OTG ID pin will be pulled up to High.        With the operation, SEL pin of USB Muxer is High, and USB signals are switched to port B, and USB differential signals are connected to MicroUSB connector. At the same time, MIC2026-1YM output is disabled. The USB OTG1 VBUS pin of CPU is supplied by VBUS of MicroUSB connector, that is to say, supplied by PC USB HOST.        In this mode, software engineer can use it to download images to flash on board. Normal Work—Host mode After the software debugging is completed, two HOSTs are needed on the board. At this time, we need to switch the USB OTG1 from device to HOST mode. What we need to do is: (1). Pull USB OTG1 ID down to LOW (2). The USB OTG D+/D- signal is switched to the USB Type-AF connector. (3). Board should supply 5V power for USB device connected USB Type-AF connector. Usage:        -Use a jumper for Pin 2 and Pin3, USB OTG ID pin will be pulled down to Low.        With the operation, USB OTG1 ID pin is pulled down to Low, SEL pin of USB Muxer is also LOW, USB signals are switched to Port A, and connected to USB type-AF connector. At the same time, MIC2026-1YM is enabled , OUTA will output 5V , which will supply USB device connected on USB type-AF connector.   [Note] Users need to pay attention to. When using the jumper with PIN1/2/3, the board needs to be powered off. In other words, when switching between device and host, you need to switch off the power, then power on, and restart the board. The solution can also be used for i.MX processors with USB 2.0 interface.   NXP CAS team Wedong Sun 01/15/2021
View full article
A new version of the Pins Tool for i.MX Application Processors has been released and is available for download as desktop tool from Pins Tool for i.MX Application Processors|NXP. The pins Tool for i.MX Application Processors is used for pin routing configuration, validation and code generation, including pin functional/electrical properties, power rails, run-time configurations, with the following main features: Desktop application Muxing and pin configuration with consistency checking Multicore support ANSI-C initialization code Graphical processor package view Multiple configuration blocks/functions Easy-to-use device configuration Selection of Pins and Peripherals Package with IP blocks Routed pins with electrical characteristics Registers with configured and reset values Power Groups with assigned voltage levels Source code for C/C++ applications Documented and easy to understand source code CSV Report and Device Tree File Localized for English and Simplified Chinese Mostly Connected: On-Demand device data download Integrates with any compiler and IDE What's New Added Label support to give signals a name Added ‘Log’ and ‘Problems’ view to report conflicts between settings Added support for templates to store user configurations as starting point for new configurations Added ability to download and share data for devices, especially for off-network host machines i.MX header files are now automatically part of the device data Import of legacy Processor Expert .pe files Export of register defines Various bug fixes and documentation improvements The release notes of the desktop application are attached to this article. Import Processor Expert Files A new importer has been added to import legacy Processor Expert for i.MX files: Labels Signals can now have user defined labels: Templates, Kits, Boards and Processors When creating a new configuration, it offers Templates, Boards and Processors. Custom configurations can be stored as templates and then used for new configurations. Board Specific Functions With the provided board and kit configurations, there are now pre-configured initialization functions for major blocks on the board: Export Data To simplify downloading the device specific data for the desktop tool, the 'Export' function can be used to download and export the data. The data can be copied that way to another machine or all data for a set of devices can be loaded. Export Registers With the Export command the registers can be exported as text/source: This is used to store the register values: /*FUNCTION********************************************************************** * * Function Name : init_audmux_pins * Description   : Configures pin routing and optionally pin electrical features. * *END**************************************************************************/ #define INIT_AUDMUX_PINS_IOMUXC_AUD5_INPUT_DA_AMX_SELECT_INPUT_VALUE            0x00000000   /*!< Register name: IOMUXC_AUD5_INPUT_DA_AMX_SELECT_INPUT */ #define INIT_AUDMUX_PINS_IOMUXC_AUD5_INPUT_TXCLK_AMX_SELECT_INPUT_VALUE         0x00000000   /*!< Register name: IOMUXC_AUD5_INPUT_TXCLK_AMX_SELECT_INPUT */ #define INIT_AUDMUX_PINS_IOMUXC_AUD5_INPUT_TXFS_AMX_SELECT_INPUT_VALUE          0x00000000   /*!< Register name: IOMUXC_AUD5_INPUT_TXFS_AMX_SELECT_INPUT */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DI0_PIN02_VALUE                  0x00000002   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DI0_PIN02 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DI0_PIN03_VALUE                  0x00000002   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DI0_PIN03 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DI0_PIN04_VALUE                  0x00000002   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DI0_PIN04 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DI0_PIN15_VALUE                  0x00000002   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DI0_PIN15 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA16_VALUE               0x00000003   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA16 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA18_VALUE               0x00000003   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA18 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA19_VALUE               0x00000003   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA19 */ ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ We hope you will find this new release useful. Thanks for designing with NXP! 
View full article
Multicore programming guide with Linux 3.14.52_1.1.0 and FreeRTOS BSP for i.MX 6SoloX
View full article
L5.4.3_1.0.0 release is now available on IMX_SW landing page: BSP Updates and Releases -> Linux ->Linux L5.4.3_1.0.0. Documentation -> Linux -> Linux 5.4.3_1.0.0 Documentation Files available: # Name Description 1 imx-yocto-LF_L5.4.3_1.0.0.zip i.MX L5.4.3_1.0.0 for Linux BSP Documentation. Includes Release Notes, User Guide. 2 LF_v5.4.y-1.0.0_images_MX6QPDLSOLOX.zip i.MX 6QuadPlus, i.MX 6Quad, i.MX 6DualLite, i.MX 6Solox Linux Binary Demo Files 3 LF_v5.4.y-1.0.0_images_MX6SLLEVK.zip i.MX 6SLL EVK Linux Binary Demo Files 4 LF_v5.4.y-1.0.0_images_MX6UL7D.zip i.MX 6UltraLite EVK, 7Dual SABRESD, 6ULL EVK Linux Binary Demo Files 5 LF_v5.4.y-1.0.0_images_MX7ULPEVK.zip i.MX 7ULP EVK Linux Binary Demo Files  6 LF_v5.4.y-1.0.0_images_MX8MMEVK.zip i.MX 8M Mini EVK Linux Binary Demo Files  7 LF_v5.4.y-1.0.0_images_MX8MNEVK.zip i.MX 8M Nano EVK Linux Binary Demo Files  8 LF_v5.4.y-1.0.0_images_MX8MQEVK.zip i.MX 8M Quad EVK Linux Binary Demo files 9 LF_v5.4.y-1.0.0_images_MX8QMMEK.zip i.MX 8QMax MEK Linux Binary Demo files 10 LF_v5.4.y-1.0.0_images_MX8QXPMEK.zip i.MX 8QXPlus MEK Linux Binary Demo files 11 imx-scfw-porting-kit-1.2.10.1.tar.gz System Controller Firmware (SCFW) porting kit v1.2.10.1 for L5.4.3_1.0.0   Target board: MX 8 Series MX 8QuadXPlus MEK Board MX 8QuadMax MEK Board MX 8M Quad EVK Board MX 8M Mini EVK Board MX 8M Nano EVK Board MX 7 Series MX 7Dual SABRE-SD Board MX 7ULP EVK Board MX 6 Series MX 6QuadPlus SABRE-SD and SABRE-AI Boards MX 6Quad SABRE-SD and SABRE-AI Boards MX 6DualLite SDP SABRE-SD and SABRE-AI Boards MX 6SoloX SABRE-SD MX 6UltraLite EVK Board MX 6ULL EVK Board MX 6ULZ EVK Board MX 6SLL EVK Board   What’s New/Features: Please consult the Release Notes.   Known Issues: For known issues and more details please consult the Release Notes.   More information on changes of Yocto, see: README: https://source.codeaurora.org/external/imx/imx-manifest/tree/README?h=imx-linux-zeus ChangeLog: https://source.codeaurora.org/external/imx/imx-manifest/tree/ChangeLog?h=imx-linux-zeus      
View full article
meta-avs-demos Yocto layer meta-avs-demos is a Yocto meta layer (complementary to the NXP BSP release for i.MX) published on CodeAurora that includes the additional required packages to support  Amazon's Alexa Voice Services SDK (AVS_SDK) applications. The build procedure is the described on the README.md of the corresponding branch. We have 2 fuctional branches now: imx-alexa-sdk: Support for Morty based i.mx releases imx7d-pico-avs-sdk_4.1.15-1.0.0: legacy support for Jethro releases The master branch is only used to collect manifest files, that used with repo init/sync commands will fetch the whole environment for the 2 special supported boards: i.MX7D Pico Pi and i.MX8M EVK. However the meta-avs-demos can be used with any i.MX board either. Recipes to include Amazon's Alexa Voice Services in your applications. The meta-avs-demos provides the required recipes to build an i.MX image with the support for running Alexa SDK. The imx-alexa-sdk branch is based on Morty and kernel 4.9.X and it supports the next builds: i.MX7D Pico Pi i.MX8M EVK Generic i.MX board For the i.MX7D Pico Pi and i.MX8M EVK there is an extended support for additional (external) Sound Cards like: TechNexion VoiceHat: 2Mic Array board with DSPConcepts SW support Synaptics Card: 2 Mic with Sensory WakeWord support The Generic i.MX is for any other regular i.MX board supported on the official NXP BSP releases. Only the default soundcard (embedded) on the board is supported. Sensory wakeword is currently only enabled for those with ARMV7 architecture. To support any external board like the VoiceHat or Synaptics is up to the user to include the additional patches/changes required. Build Instructions Follow the corresponding README file to follow the steps to build an image with Alexa SDK support README-IMX7D-PICOPI.md README-IMX8M-EVK.md README-IMX-GENERIC.md
View full article
  Question: How can we generate an ARM DS5 DStream format DDR initialization script using the DRAM Register Programming Aid?  Answer: Some RPAs include a  "DStream .ds file" tab for the ARM DS5 debugger specific commands. The i.MX6UL/ULL/ULZ DRAM Register Programming Aids for example already has this supported. However, the user can easily create  the .ds format from the existing .inc format. The basic steps to convert .inc files to .ds format are as follows: 1)  Replace the one instance of setmem /16 with mem set 2)  In that same line, replace 0x020bc000 = with 0x020bc000 16 3)  Use a Replace All command to change setmem /32 with mem set 4)  Use a Replace All command to change = with 32 5)  Use a Replace All command to change // with # 6)  Save as a .ds file.   Question: When using a 528MHz DRAM Controller interface with a DDR memory of a faster speed bin, which speed bin timing options should one use? Answer: For example, let’s assume our MX6DQ design is using a DDR3 memory from a DDR3-1600 speed bin.  However, the maximum speed of the MMDC interface for the MX6DQ using DDR3 is 528MHz.  Should we use the 1600 speed bin (800MHz clock speed) or the 1066 speed bin (533MHz clock speed)?  In short, the user should use the timings rated for the maximum speed (frequency) with which you are running, in this case DDR3-1066 (533MHz).  In some cases, like when using the MX6DL, the maximum DDR frequency is 400MHz.  In this case, you would want to try and use 800 timings found in the AC timing parameters table.  However, most DDR3 devices have speed bin tables that may go only as low as 1066, in which case you would use the closest speed bin to your operational frequency (i.e. the 1066 speed bin table).     Question: Some timing parameters may specify a min and max number, which should I use? Answer: In most cases, you will want to choose the minimum timings.  Some DRAM controllers may have a tRAS_MAX timing parameter, in which case you would obviously use the maximum tRAS parameter given in the DRAM data sheet. Also, for timing parameters tAONPD and tAOFPD, we also want to use the maximum values given in the DDR3 data sheet. These represent the maximum amount of time the DDR3 device takes to turn on or off the RTT (termination), therefore, we should wait at least this amount of time before issuing any commands or accesses.   Question: Some timing parameters state things like “Greater of 3CK or 7.5ns”; which should I use? Answer: This depends on your clock speed.  Say you are running at 533MHz.  At 533MHz, 7.5ns equates to 4CKs.  In this case, 7.5ns at 533MHz is GREATER than 3CK, so we would use the 7.5ns number, or 4CKs. At 400MHz, 7.5ns equates to 3CKs.  In this case, we’d simply use 3CKs.   Question: I have a design that will throttle the DDR frequency (dynamic frequency scaling).  At full speed, I plan to run at 533MHz, and then I plan to throttle down to say 400MHz whenever possible.  Do I need to re-calculate my 400 MHz timing parameters that were initially set for 533MHz? Answer: It is not necessary to re-calculate timing parameters for 400MHz, and you can re-use the ones for 533MHz.  The timings at 533 MHz are much tighter than 400 MHz, and the key here is to NOT violate timings.  Also, it may be a bit of a hassle maintaining two sets of timing parameters, especially if later in the design, you swap DDR vendors that might require you to re-calculate some timing parameters.  It’s easier to do it once and to come up with a combined worse-case timing parameters for 533MHz, which you know will work at 400MHz.  But, if you don’t mind maintaining two sets of timing parameters, and really want to optimize timings down to the last pico-second for 400MHz, then knock yourself out.   Question: Can I use these Register programming aids for both Fly by and T- Topology ? Answer Yes The DDR register programming aid is agnostic to the DDR layout. The same spreadsheet works for both topologies. We recommend running write leveling calibration for both topologies and the values returned by the Write Leveling routine from the Freescale DDR stress test should be incorporated back to the customer specific initialization script. The DDR stress test also has a feature whereby it evaluates the write leveling values returned from calibration and increments WALAT to 1 if the values exceed a defined limit. The DDR stress test informs the user when the Write Additional latency (WALAT) exceeds the limit and should be increased by 1, and reminds the user to add it back in the customer specific initialization script if required.   WALAT - 0 00000000 WALAT: Write Additional latency. Recommend to clear these bits. Proper board design should ensure that the DDR3 devices are placed close enough to the MMDC to ensure the skew between CLK and DQS is less than 1 cycle.     Question: Can I use the DEFAULT Register programming aid values for MDOR when using an Internal OSC instead of the recommended 32.768 KHZ XTAL ? Answer No, NXP recommends reprogramming these values based on the worse case frequency (Max clock) of the internal OSC of the device to guarantee JEDEC timings are met. Please refer to Internal Oscillator Accuracy considerations for the i.MX 6 Series for more details  
View full article
NOTE: Always de-power the target board and the aggregator when plugging or unplugging smart sensors from the aggregator. NOTE: See this link to instrument a board with a Smart Sensor. This page documents the triple-range "smart" current sensor that's part of a larger system for profiling power on application boards. The smart sensor features a Kinetis KL05Z with three current sense amplifiers. It allows measurement currents in three ranges. Four assembly options allow measurement of rail voltages 0-3.3V (two overall current ranges), 0-6.6V, and 12V. It connects to an aggregator, which powers, controls and aggregates data from a number of smart sensor boards. One of the biggest improvements over the older dual-range measurement system is that the on-sensor microcontroller allows near-simultaneous measurement of all instrumented rails on a board. The dual range profiler can only make one measurement at a time.  These are intended to be used with a microncontroller board to act as a trigger and data aggregator. This aggregator could also be used to reprogram the sensors.  The series resistance added by the smart sensor when in run mode (highest current range) is under 11 milliOhms as measured with 4-point probes and a Keysight B2902B SMU.  A "power oscilloscope" can be made by triggering measurements at regular intervals and presenting the results graphically.... Schematic: Board Layout, Top: Board Layout, Bottom: Here's a photo of two with a nickel is included to show scale. The board measures about 0.5 by 1.3 inches. Connections: The smart sensor header connections are: 5V: powers the 3.3V regulator, which in turn powers everything else on the sensor board 12V: all the gates of all the switching FETs are pulled pulled up to 12V GND: ground connection SCL/TX: I2C clock line  SDA/RX: I2C data line  SWD_CLK:  line for triggering smart sensors to make measurements RESET_B:  line for resetting the smart sensor board SWD_IO: select line for the smart sensor Theory of operation: Three shunts and current sense amplifiers are used to measure current in three ranges. One shunt/sense amp pair has a 0.002Ω shunt integrated into the IC package (U1, INA250). The other two sense amps (U2 and U3, INA212) require an external shunt.  FETs Q1, Q2,  and Q3 are used to switch the two lower range shunt/sense amp pairs in and out of circuit. In normal run operation (highest current range), Q1 (FDMC012N03, with Rds(on) under 1.5mΩ) is turned on, which shorts leaves only U1 in circuit. FETs Q4, Q5 and Q6 translate the voltages to 3.3V so that GPIO on U4 (MCU KL05Z) can control them.  Rail voltage measurement is facilitated via resistors R3, R4, and R12 and Q7. Not all of these are populated in every assembly option. For measuring rail voltages 0-3.3V, R12 is populated. To measure 0-6.6V, R3, R4,and Q7 are populated. When turned on Q7 enables the voltage divider. All of the assembly option population info can be found in the schematic (attached). Regulator U5 (AP2210N) provides the 3.3V supply for all of the components on the board. This 1% tolerance regulator is used to provide a good reference for the ADC in U4.  Microcontroller U4 detects the assembly population option of the board via resistors R9, R10, and R11 so that the same application code can be used across all variations of the sensor boards. GPIO control the FETs and four ADC channels are used to measure the sense amplifier outputs and the rail voltage. Having a microcontroller on the sensor board allows the user to do extra credit things like count coulombs as well as allowing all similarly instrumented rails to measure at the same time via trigger line SWD_CLK. Data communication can be via I2C or UART, since these two pins can do both.  But if multiple sensor boards are to be used with an aggregator, communication needs to be over I2C. Application Code: The latest application code for the KL05Z on the smart sensor resides here: https://os.mbed.com/users/r14793/code/30847-SMRTSNSR-KL05Z/. The latest binary is attached below. In order to re-flash a smart sensor, the modification detailed in the aggregator page needs to be made. Once the modification is completed, leave the aggregator unpowered while pluging the SWD debugger into J5 and the smart sensor to be programmed into JP15. Very old UART-based application code for the KL05Z, built in the on-line MBED compiler (note that it requires the modified mbed library for internal oscillator). This code was used while testing the first smart sensor prototypes. It has since been abandoned. It's published here in the event that a user wants to use a single sensor plugged into JP15 with UART breakout connector J6. /****************************************************************************** * * MIT License (https://spdx.org/licenses/MIT.html) * Copyright 2017-2018 NXP * * MBED code for KL05Z-based "smart" current sensor board, basic testing * of functions via UART (connected via FRDM board and OpenSDA USB virtual * COM port). * * Eventual goal is to have each smart sensor communicate over I2C to an * aggregator board (FRDM board with a custom shield), allowing 1-10 power * supply rails to be instrumented. Extra credit effort is to support * sensors and aggregator with sigrok... * * Because there is no crystal on the board, need to edit source mbed-dev library * to use internal oscillator with pound-define: * change to "#define CLOCK_SETUP 0" in file: * mbed-dev/targets/TARGET_Freescale/TARGET_KLXX/TARGET_KL05Z/device/system_MKL05Z4.c * ******************************************************************************/ #include "mbed.h" // These will be GPIO for programming I2C address... // not yet implemented, using as test pins... DigitalOut addr0(PTA3); DigitalOut addr1(PTA4); DigitalOut addr2(PTA5); DigitalOut addr3(PTA6); // configure pins for measurements... // analog inputs from sense amps and rail voltage divider... AnalogIn HIGH_ADC(PTB10); AnalogIn VRAIL_ADC(PTB11); AnalogIn LOW1_ADC(PTA9); AnalogIn LOW2_ADC(PTA8); // outputs which control switching FETs... DigitalOut VRAIL_MEAS(PTA7); // turns on Q7, connecting voltage divider DigitalOut LOW_ENABLE(PTB0); // turns on Q4, turning off Q1, enabling low measurement DigitalOut LOW1(PTB2); // turns on Q5, turning off Q2, disconnecting shunt R1 DigitalOut LOW2(PTB1); // turns on Q6, turning off Q3, disconnecting shunt R2 // input used for triggering measurement... // will eventually need to be set up as an interrupt so it minimizes delay before measurement InterruptIn trigger(PTA0); // use as a trigger to make measurement... // PTB3/4 can be used as UART or I2C... // For easier development with one smart sensor, we are using UART here... Serial uart(PTB3, PTB4); // tx, rx long int count=0; int n=25; // global number of averages for each measurement int i, temp; bool repeat=true; // flag indicating whether measurements should repeat or not const float vref = 3.3; // set vref for use in calculations... float delay=0.25; // default delay between measurement bool gui = false; // flag for controlling human vs machine readable output bool statistics = false;// flag for outputting min and max along with average (GUI mode only) void enableHighRange(){ LOW_ENABLE = 0; // short both low current shunts, close Q1 wait_us(5); // delay for FET to settle... (make before break) LOW1 = 0; LOW2 = 0; // connect both shunts to make lower series resistance VRAIL_MEAS = 0; // disconnect rail voltage divider wait_us(250); // wait for B2902A settling... } void enableLow1Range(){ LOW1 = 0; LOW2 = 1; // disconnect LOW2 shunt so LOW1 can measure wait_us(5); // delay for FET to settle... (make before break) LOW_ENABLE = 1; // unshort low current shunts, open Q1 VRAIL_MEAS = 0; // disconnect rail voltage divider wait_us(250); // wait for B2902A settling... } void enableLow2Range(){ LOW1 = 1; LOW2 = 0; // disconnect LOW1 shunt so LOW2 can measure wait_us(5); // delay for FET to settle... (make before break) LOW_ENABLE = 1; // unshort low current shunts, open Q1 VRAIL_MEAS = 0; // disconnect rail voltage divider wait_us(500); // wait for B2902A settling... } void enableRailV(){ VRAIL_MEAS = 1; // turn on Q7, to enable R3-R4 voltage divider wait_us(125); // wait for divider to settle... // Compensation cap can be used to make // voltage at ADC a "square wave" but it is // rail voltage and FET dependent. Cap will // need tuning if this wait time is to be // removed/reduced. // // So, as it turns out, this settling time and // compensation capacitance are voltage dependent // because of the depletion region changes in the // FET. Reminiscent of grad school and DLTS. // Gotta love device physics... } void disableRailV(){ VRAIL_MEAS = 0; // turn off Q7, disabling R3-R4 voltage divider } // this function measures current, autoranging as necessary // to get the best measurement... void measureAuto(){ Timer t; float itemp; float tempI=0; float imin = 1.0; // used to keep track of the minimum... float imax = 0; // used to keep track of the maximum... t.start(); // use timer to see how long things take... enableHighRange(); // this should already be the case, but do it anyway... for (i = 0; i < n; i++){ itemp = HIGH_ADC; // read HIGH range sense amp output if (statistics && itemp>imax) imax = itemp; // update max if necessary if (statistics && itemp<imin) imin = itemp; // update min if necessary tempI += itemp; // add current sample to running sum } tempI = tempI/n *vref/0.8; // compute average we just took... if (gui) uart.printf("=> %5.3f ", tempI); if (statistics && gui) uart.printf("[%5.3f/%5.3f] ", imin*vref/0.8, imax*vref/0.8); // if current is below this threshold, use LOW1 to measure... if (tempI < 0.060) { if (!gui) uart.printf("... too Low: %f A, switching to low1 ==>\r\n", tempI); tempI=0; enableLow1Range(); // change FETs to enable LOW1 measurement... imin = 1.0; imax = 0; for (i = 0; i < n; i++){ itemp = LOW1_ADC; // read LOW1 sense amp output if (statistics && itemp>imax) imax = itemp; // update max if necessary if (statistics && itemp<imin) imin = itemp; // update min if necessary tempI += itemp; // add current sample to running sum } tempI = tempI/n *vref/0.05/1000; // compute average we just took... if (gui) uart.printf("%6.4f ", tempI); if (statistics && gui) uart.printf("[%6.4f/%6.4f] ", imin*vref/0.05/1000, imax*vref/0.05/1000); // if current is below this threshold, use LOW2 to measure... if (tempI < 0.0009){ if (!gui) uart.printf("... too Low: %f A, switching to low2 ==>\r\n", tempI); tempI=0; enableLow2Range(); // change FETs to enable LOW1 measurement... imin = 1.0; imax = 0; for (i = 0; i < n; i++){ itemp = LOW2_ADC; // read LOW2 sense amp output if (statistics && itemp>imax) imax = itemp; // update max if necessary if (statistics && itemp<imin) imin = itemp; // update min if necessary tempI += itemp; // add current sample to running sum } tempI = tempI/n *vref/2/1000; // compute average we just took... if (gui) uart.printf("%8.6f ", tempI); if (statistics && gui) uart.printf("[%8.6f/%8.6f] ", imin*vref/2/1000, imax*vref/2/1000); } } t.stop(); // stop the timer to see how long it took do do this... enableHighRange(); if (!gui) uart.printf("\r\nCurrent = %f A Current Measure Time = %f sec\r\n", tempI, t.read()); } // the autoranging should really be done with functions that return values, as should the // functions below... This would make for shorter and more elegant code, but the author // is a bit of a pasta programmer... void measureHigh(){ float highI=0; enableHighRange(); for (i = 0; i < n; i++){ highI += HIGH_ADC; } highI = highI/n; uart.printf("HIghI = %f A\r\n", vref*highI/0.8); } void measureLow1(){ float low1I=0; enableLow1Range(); for (i = 0; i < n; i++){ low1I += LOW1_ADC; } enableHighRange(); low1I = low1I/n; uart.printf("low1I = %f A\r\n", vref*low1I/0.05/1000); } void measureLow2(){ float low2I=0; enableLow2Range(); for (i = 0; i < n; i++){ low2I += LOW2_ADC; } enableHighRange(); low2I = low2I/n; uart.printf("low2I = %f A\r\n", vref*low2I/2/1000); } // measure the rail voltage, default being with // a divide by 2 resistor divider // It has to be switched out when not in use or it will // add to the measured current, at least in the low ranges... void measureRailV(){ float railv=0; float mult = vref*2; // since divide by 2, we can measure up to 6.6V... float vmin = 5; float vmax = 0; float vtemp; enableRailV(); // switch FETs so divider is connected... for (i = 0; i < n; i++){ vtemp = VRAIL_ADC; // read voltage at divider output... if (statistics && vtemp>vmax) vmax = vtemp; // update max if necessary if (statistics && vtemp<vmin) vmin = vtemp; // update min if necessary railv += vtemp; // add current sample to running sum } disableRailV(); // now disconnect the voltage divider railv = railv/n; // compute average (note this is in normalized ADC [0..1]) // Convert to voltage by multiplying by "mult" if (!gui) uart.printf("RailV = %5.3f V ", mult*railv); if (gui) uart.printf("%5.3f ", mult*railv); if (statistics && gui) uart.printf("[%5.3f/%5.3f] ", mult*vmin, mult*vmax); uart.printf("\r\n"); } // not sure how useful this function is... void measureAll(){ measureHigh(); measureLow1(); measureLow2(); measureRailV(); } // test function to see if trigger pin is being hit... // intended for use later to do timed triggering of measurements... void triggerIn(){ uart.printf("You're triggering me! \r\n"); measureAll(); } // main... int main() { // set up basic conditions... Timer m; uart.baud(115200); enableHighRange(); // default state - only HIGH sense amp in circuit, no divider // signal that we're alive... uart.printf("Hello World!\r\n"); // configure the trigger interrupt... trigger.rise(&triggerIn); while (true) { count++; wait(delay); if (repeat){ // if repeat flag is set, keep making measurements... m.reset(); // reset and start timer... m.start(); measureAuto(); // measuring current using auto-ranging... measureRailV(); // measure rail voltage... m.stop(); // stop the timer. if (!gui) uart.printf(" Total Measure Time = %f sec", m.read()); if (!gui) uart.printf("\r\n\r\n"); } // see if there are any characters in the receive buffer... // this is how we change things on the fly... // Commands (single keystroke... it's easier) // t = one shot automeasure // v = measure volt // h = one shot high measure // k = one shot LOW1 measure // l = one shot LOW2 measure (letter l) // r = toggle repeat // R = turn off repeat // + = faster repeat rate // - = slower repeat rate // = = set repeat rate to 0.25 sec // g = use human readable text output // G = use compressed text format for GUI // s = turn statistics output off // S = turn statistics output on (only in GUI mode) // n = decrease number of averages for each measurement // N = increase number of averages for each measurement // // these were for testing FET switching... // 1 = LOW_ENABLE = 0 (the number 1) // 2 = LOW1 = 0 // 3 = LOW2 = 0 // 4 = VRAIL_MEAS = 0 // ! = LOW_ENABLE = 1 // @ = LOW1 = 1 // # = LOW2 = 1 // $ = VRAIL_MEAS = 1 if (uart.readable()){ temp = uart.getc(); if (temp==(int) 't') { if (!gui) uart.printf("Keyboard trigger: "); measureAuto(); measureRailV(); //measureAll(); } if (temp==(int) 'v') { uart.printf("Keyboard trigger: "); measureRailV(); } if (temp==(int) 'h') { uart.printf("Keyboard trigger: "); measureHigh(); } if (temp==(int) 'k') { uart.printf("Keyboard trigger: "); measureLow1(); } if (temp==(int) 'l') { uart.printf("Keyboard trigger: "); measureLow2(); } if (temp==(int) '1') { LOW_ENABLE = 0; uart.printf("Keyboard trigger: LowEnable = %d\r\n", 0); } if (temp==(int) '2') { LOW1 = 0; uart.printf("Keyboard trigger: LOW1 = %d\r\n", 0); } if (temp==(int) '3') { LOW2 = 0; uart.printf("Keyboard trigger: LOW2 = %d\r\n", 0); } if (temp==(int) '4') { VRAIL_MEAS = 0; uart.printf("Keyboard trigger: VRAILMEAS = %d\r\n", 0); } if (temp==(int) '!') { LOW_ENABLE = 1; uart.printf("Keyboard trigger: LowEnable = %d\r\n", 1); } if (temp==(int) '@') { LOW1 = 1; uart.printf("Keyboard trigger: LOW1 = %d\r\n", 1); } if (temp==(int) '#') { LOW2 = 1; uart.printf("Keyboard trigger: LOW2 = %d\r\n", 1); } if (temp==(int) '$') { VRAIL_MEAS = 1; uart.printf("Keyboard trigger: VRAILMEAS = %d\r\n", 1); } if (temp==(int) 'r') { repeat = !repeat; uart.printf("Keyboard trigger: repeat toggle: %s \r\n", repeat ? "true" : "false"); } if (temp==(int) 'R') repeat = false; if (temp==(int) '+') { delay -= 0.05; if (delay<0.05) delay = 0.05; } if (temp==(int) '-') { delay += 0.05; if (delay>1) delay = 1; } if (temp==(int) '=') delay = 0.25; if (temp==(int) 'g') gui = false; if (temp==(int) 'G') gui = true; if (temp==(int) 's') statistics = false; if (temp==(int) 'S') statistics = true; if (temp==(int) 'n') { n -= 25; if (n<25) n = 25; } if (temp==(int) 'N') { n += 25; if (n>1000) n = 1000; } if (temp==(int) 'N' || temp==(int) 'n') uart.printf("/r/n/r/n Averages = %d \r\n\r\b", n); } } }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍
View full article
Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response.   This is a detailed programming aid for the registers associated with MMDC initialization. The last sheet formats the register settings for use with ARM RealView ICE. It can also be used with the windows executable for the DDR Stress Test. This programming aid was used for internal NXP validation boards.
View full article
Recently, some customers are using i.MX processor, they want to add raid & LVM function support to the kernel, but they have encountered the problem that the compilation cannot pass. Tested it in L4.14.98, L4.19.35 & L5.4.x, Only L4.14.98 bsp exists the problem. Here are the experimental steps I have done, including the same problems I encountered with the customer, and how to modify the kernel to ensure that the compilation passes. 1. Exporting cross compilation tool chain from yocto BSP (1) Downloading Yocto BSP and compiling it. Following steps in i.MX_Yocto_Project_User's_Guide.pdf, download Yocto BSP and compile it successfully. (2) Exporting cross compilation tool chain Following methods described in i.MX_Linux_User's_Guide.pdf, export cross compilation tool chain from yocto BSP. See Chapter 4.5.12 of the document, please! Then cross compilation tool chain will be like below: (3) Copying linux BSP source code to a new directory # cd ~ # mkdir L4.14.98-2.0.0 # cd L4.14.98-2.0.0 # cp -r ~/imx-yocto-bsp/build-fb/tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/4.14.98- r0/git ./ Then all linux source code has been copied to L4.14.98-2.0.0, which is the top directory of linux kernel source code, I will compile kernel image here. 2. Compiling linux kernel # cd ~/L4.14.98-2.0.0 # source /opt/fsl-imx-fb/4.14-sumo/environment-setup-cortexa9hf-neon-poky-linux-gnueabi # export ARCH=arm # make imx_v7_defconfig # make menuconfig Then we will add RAID and LVM modules to linux kernel. In order to reproduce errors, I added all related modules to kernel. See below, please! Device drivers---->Multiple devices driver support (RAID and LVM) After save and exit, began to compile kernel. # make (make –j4) The following errors will occur: ------------------------------------------------------------------------------------------- drivers/md/dm-rq.c: In function ‘dm_old_init_request_queue’: drivers/md/dm-rq.c:716:2: error: implicit declaration of function ‘elv_register_queue’; did you mean ‘blk_register_queue’? [-Werror=implicit-function-declaration] elv_register_queue(md->queue); ^~~~~~~~~~~~~~~~~~ blk_register_queue cc1: some warnings being treated as errors scripts/Makefile.build:326: recipe for target 'drivers/md/dm-rq.o' failed make[2]: *** [drivers/md/dm-rq.o] Error 1 scripts/Makefile.build:585: recipe for target 'drivers/md' failed make[1]: *** [drivers/md] Error 2 Makefile:1039: recipe for target 'drivers' failed make: *** [drivers] Error 2 ------------------------------------------------------------------------------------------- 3. Finding out root cause and solving it (1) elv_register_queue( ) function The function is loaded in dm-rq.c : int dm_old_init_request_queue(struct mapped_device *md, struct dm_table *t) { … … elv_register_queue(md->queue); … … } BUT compiler didn’t find it’s declaration and entity. Searching source code, and found it declared in linux_top/block/blk.h: … … int elv_register_queue(struct request_queue *q); … … It’s entity is in linux_top/block/elevator.c: int elv_register_queue(struct request_queue *q) { … … } (2) Adding declaration and exporting the function --- Declaration Add the line below to dm-rq.c: … … extern int elv_register_queue(struct request_queue *q); … … --- Exporting the function(elevator.c) Add EXPORT_SYMBOL(elv_register_queue); to the end of function, see below. int elv_register_queue(struct request_queue *q) { … … } EXPORT_SYMBOL(elv_register_queue); 4. Re-compiling Linux Kernel The above error will not occur and the compilation will complete successfully.   NXP CAS team Weidong Sun
View full article
When you do long test (days or weeks) test on i.MX board and your test fails, you often wants to know what has happen with a JTAG probe. The problem is when you have 50 boards running in parallel, you don't have the budget to have 50 JTAG debug probe. If you do a "hot plug" of your JTAG probe, you have roughly one chance out 2 to reset your board... so you'll have to wait another couple of hour to resee the problem. Anyway to have a reliable JTAG plug with no reset, it is really simple... cut the RESET line on your cable! then you'll still be able to "attach" to your i.MX. On the MEK board, with a 10-pin JTAG connector, you have the cut the cable line 10 of the ribbon cable: On the cable, cut the reset line like this: With my Lauterbach JTAG  probe, when I do a "hot plug" I never have a reset of my i.MX. BR Vincent
View full article
as we known, mx6sx doesn’t have IPU, if we need to resize, rotation or blending…., we can use pxp module, this part, we talk about rotation for example. We also can use GPU for rotation, but in imx6sx, the number after 6sx in the part number stands for the chip including gpu or not, the number 4 and 3 mean mx6sx has gpu, like MCIMX6X3EVN10AB. and 1,2 and 3 mean mx6sx doesn’t have gpu, like MCIMX6X2EVN10AB for gpu, we know we can use xrander to rotate ,in this part, we focus on pxp rotation the stesp: enable pxp in the kernel:               $ bitbake -c menuconfig linux-imx, then choose Device Drivers ---> DMA Engine support ---> [*] MXC PxP support [*] MXC PxP Client Device 2) download the built image from tmp/deploy/images/imx6sxsabresd 3) boot up the board, then you can find the pxp_v4l2_test.out in the unit test 4) use the command as below to test the rotation: ./pxp_v4l2_test.out -sx 480 -sy 272 -res 352:240 -a 100  -r 90 fb-352x240.yuv BLANK   Sx and sy is resolution for display, -res is resolution for image or video. -r is for rotaion, you can set 0,90,180 and 270 for it. I attach the fb-352x240.yuv for testing
View full article
Instrumenting A Board To instrument a board, the connection between the power supply and the target device needs to be broken, usually via a series resistor that's placed on the board. Sometimes the inductor needs to be lifted if no series resistor was included on the rail by the board's designer. In the ideal case, through-hole connections were also provided on the board for the connection of these off-board sensors. Here are three close-up photos that show several boards that have been instrumented: In all three cases, the sensors stand in place via the two outer current carrying wires. The middle and right used insulated wires where as the one on the left used bare wires. In all three cases, the sensor's + connection needs to go towards the power supply and the - connection goes to the target device. The outer wires here are 24-26 gauge. (The relatively heavy gauge wire is used to keep the series resistance of inserting a smart sensor to a minimum.) The ground connection is the middle hole of the smart sensor. In the left and middle photos, a 30 gauge wire connects to the middle hole ground connection on the  board. In the right photo, the ground wire was more conveniently added to a big cap just below the bottom of edge of the photo. Here are wider angle view photos of two of the boards above: The sensors on the left are free-standing since the current carrying wires are stiff enough to hold them upright. Care must be taken since too much flexing will cause a wire to break. Too much bending can also cause a short to the board (and that's why insulated wires were used on these boards). The board on the right has the sensors laying parallel to the board. They are not affixed to the board, but a wire is wrapped around the bundle of ribbon cables out of view past the right edge of the photo. For boards without the through hole connections, the smart sensors need to be immobilized to keep from pulling the SMT pads off the board. If there is room on the board or sides of connectors or large components, the sensors may be attached down with foam double-sticky tape (see photo below, sensor affixed on top i.MX7ULP): For boards where there are no convenient unpopulated areas or there are too many sensors, some other means needs to be devised to immoblize the smart sensors. In the left photo below, two inductors per sensor have been flipped and the two sensors inserted to instrument the two rails. The solder pads on the inductors would easily be broken off by any movement of the smart sensors, so a cage with clamps to hold the ribbon cables was 3D printed. On the back side, there is room for the aggregator to be zip tied to the bottom plate, so the instrumented board can be moved as a single unit with minimal flexing of the ribbon cables.
View full article
i.MX evaluation board can be a simple solution to program i.MX boards in a factory for instance. i.MX evaluation board are not for industrial usage, but you can find plenty of cheap i.MX insdustrial boards on the web. Here I am using an i.MX8QXP rev B0 MEK board and I will program an i.MX6Q SABRE SD board. The first step is to generate your image. Follow the documentation steps to generate the "validation" image. You will have to customize a little bit the local.conf file (in conf/local.conf) to have git, cmake, gcc and other missing package. edit local.conf and add the following lines at the end of the file: IMAGE_INSTALL_append = " git cmake htop packagegroup-core-buildessential xz p7zip rsync"‍‍‍‍‍ I have added rsync package in local, it can replace cp (copy) but with the --progress option you can see the copy progression. P7zip replace unzip for our images archives avaialable on nxp.com as unzip as issues with big files. then rebake your image: bitbake -k fsl-image-validation-imx‍‍‍‍‍ When it is done, go in tmp/deploy/image/<your image generated> and use uuu to program your board (I use a sd card; thus I can increase the partition esily): sudo ./uuu -b sd_all imx-boot-imx8qxpmek-sd.bin-flash fsl-image-validation-imx-imx8qxpmek.sdcard.bz2/*‍‍‍‍‍ As the rootfs can be too small, use gparted under Linux for instance to increase the size of the partition. Put the SD card and start your board. Here here the dirty part... You may know archlinux|ARM websitesite (Arch Linux ARM ), you have a lots of precompiled packages. Thus on the board you can download it, and copy the file in /usr folder (you can use it to have the latest openSSL for  instance!). Plug an ethernet cable on the board and check if it is up: ifconfig -a ifconfig eth0 up‍‍‍‍‍‍‍‍‍‍ Now you should have access to the internet. On uuu webpage you can find all the packages you need (here I am using a 4.14.98_2.0.0 Linux): mkdir missinglibs cd missinglibs wget http://mirror.archlinuxarm.org/aarch64/core/bzip2-1.0.8-2-aarch64.pkg.tar.xz wget http://mirror.archlinuxarm.org/aarch64/core/nettle-3.5.1-1-aarch64.pkg.tar.xz wget http://mirror.archlinuxarm.org/aarch64/core/libusb-1.0.22-1-aarch64.pkg.tar.xz wget http://mirror.archlinuxarm.org/aarch64/extra/libzip-1.5.2-2-aarch64.pkg.tar.xz wget http://mirror.archlinuxarm.org/aarch64/core/zlib-1:1.2.11-3-aarch64.pkg.tar.xz wget http://mirror.archlinuxarm.org/aarch64/extra/p7zip-16.02-5-aarch64.pkg.tar.xz cd ..‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Wait all the archives are downloaded (otherwise you'll decompress before the archive is downloaded) as wget is running in background! Now untar the archives and copy it in the rootfs (dirty): tar -xJf libzip-1.5.2-2-aarch64.pkg.tar.xz tar -xJf libusb-1.0.22-1-aarch64.pkg.tar.xz tar -xJf nettle-3.5.1-1-aarch64.pkg.tar.xz tar -xJf bzip2-1.0.8-2-aarch64.pkg.tar.xz cp zlib-1:1.2.11-3-aarch64.pkg.tar.xz zlib tar -xJf zlib tar -xJf p7zip-16.02-5-aarch64.pkg.tar.xz cd usr sudo cp -R . /usr cd ../../ ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Download and compile uuu: git clone git://github.com/NXPmicro/mfgtools.git cd mfgtools/ cmake . make‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Download an image on nxp.com for instance. I have downloaded on the i.MX6 4.14.98_2.0.0 image and put it on a usb key. then unzip it in the uuu folder: 7z e L4.14.98_2.0.0_ga_images_MX6QPDLSOLOX.zip‍‍‍‍ As mentionned before unzip cannot hadle big files... so use 7z as me plug the i.MX6Q SABRE SD to the i.MX8X and program your i.MX6 board: ./uuu uuu.auto-imx6qsabresd‍ uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.3.74-0-g64eeca1 Success 1 Failure 0 ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍
View full article
We will build a remote debug environmet of Qt Creator in this user guide.   Contents 1 Change local.conf file in Yocto 2 2 Build and deploy Yocto SDK 2 2.1 Build full image SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.2 Deploy SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3 Configure QT Kit 2 3.1 Setup device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3.2 Configure QT version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.3 Configure gcc and g++ manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.4 Configure gdb manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.5 Configure Kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.6 Very important thing!! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4 Test result
View full article
NOTE: Always de-power the target board and the aggregator when plugging or unplugging smart sensors from the aggregator. NOTE: See this link to instrument a board with a Smart Sensor. Overview The i.MX Power Profiler system consists of one to fourteen "smart" current sensors, an aggregator shield, and a Kinetis FRDM board (the FRDM-KL25 has been used in prototyping but the FRDM-K64F and FRDM-K66F should also be fully compatible). One of the biggest improvements of this system over its preceeding dual-range measurement system is that the microcontroller on each sensor board allows near-simultaneous measurement of all instrumented rails on a board. The dual range profiler has only a single MCU for all sensors, so only one measurement can be made at a time.  It is intended to be used to instrument one to fourteen rails of a target i.MX appliation board. Ideally, the target board will have been designed with a matching/mating power sense footprint for each rail to be measured.  Each smart sensor can sense current in three ranges with three current sense amplifiers. They are "smart" because each sensor board has a Kinetis KL05Z on it to control the switching FETs and to digitize the analog signals (the sense amplifier outputs and the target's power supply rail voltage). A 1% voltage regulator on each smart sensor provides a good voltage reference right next to the KL05Z to ensure better ADC accuracy. Each smart sensor board communicates via I2C. The aggregator shield has three I2C bus extenders (PCA9518) which essentially provide a dedicated I2C bus for each of the connected smart sensors. The FRDM board's I2C is also connected to one of the bus extenders ports. Individual GPIO lines are routed to each smart sensor's connected along with a ganged reset and trigger line for all of the connected smart sensors. A boost regulator generates almost 12V from the FRDM board's 5V supply, which is used for all the switching FETs on the smart sensor boards. The FRDM board's 5V rail is also routed to each smart sensor, which is regulated down to 3.3V locally on each connected smart sensor. Here is a photo of the very first prototypes after moving to 10-pin 0.05" spaced headers and ribbon cables instead of FFC: The smart sensor is intended to mate with through-hole current sense tap points on the target i.MX application board. Three holes spaced at 0.05" each. When not instrumented with sensor, a short needs to be placed across the outer two pins so that the board will function normally. The through hole connections provide physical protection to the target board, keeping traces from getting ripped off. The ground connection in the center provides a reference for meauring the rail voltage on the target board. A partial layout example of the implementation of the current sense footprint is below, where two 0805 shorting resistors in parallel are placed on each side of the holes. The top trace connects to the regulator output and the bottom to the load, usually an i.MX power supply rail. To include the current sense footprint into a board during the design phase, it should be configured as in the following partial schematic:  Every effort should be made to place the feedback on the i.MX side of the sense points so that the regulator compensates for the additional series resistance of the smart sensor, which effectively eliminates the additional series resistance the smart sensor adds. The Feedback should be before the smart sensor if the switching supply won't tolerate the additional series resistance (i.e., output becomes unstable).
View full article
Purpose:  Introduce how to debug M4 using trace32 and the difference with general debug case.If you are using other jtag debug tools, maybe you need to do the similar configuration. Debug tools: Trace32 – you can refer to http://www.lauterbach.cn/ for more information about this tool. Firmware: Here we using Freertos as the example, but not limited to this. There is one small difference with general debug case to M4 in 6sx, which when you attach M4 and break M4, it may impact the peripheral that A9 is using. You may have found when you break M4, A9 uart console also was frozen at the same time. This is caused by that when M4 enter debug mode, the debug_req will also assert in the peripherals which you are using on the A9 system. So,need configure the peripherals to keep running when the debug_req is assert when do the M4/A9 debug separately. Need configure the DBGEN (*) register in the related peripherals to allow the eripherals not going into debug mode and keep running even if debug_req is HIGH. The peripherals we need take care are: CAN, UART, EPIT,GPT, ENET, PWM. Note: For the CAN, the register bit is called FRZ Here is the details of uart dbgen in the RM: So if we want debug M4 separately,we should disable this bit, as A9 was using this peripheral. Here we take Freertos as the example to illuminate how to debug M4 step by step: Enable DBGEN case: Load M4 image into memory and kick off M4. (You can refer to  for the details)           =>fatload mmc 2:1 0x9ff00000 hello_world_ddr.bin                reading hello_world_ddr.bin 18748 bytes read in 30 ms (609.4 KiB/s)           =>dcache flush           =>bootaux 0x9ff00000               ##Starting auxiliary core at 0x9FF00000                ... Attach M4 using the m4.cmm file(attached): Note:  You can find the elf file at the same folder of binary: So now you can debug your code step by step.If you go back to A9 side uart console, you would find the console have been frozen. Disable DBGEN case at A9 side: Load M4 image into memory and kick off M4. (You can refer to  for imx6sx user guide  the details)           =>mm 0x20200b4                              020200b4:00000020 ? 0x820           =>fatload mmc 2:1 0x9ff00000 hello_world_ddr.bin                reading hello_world_ddr.bin 18748 bytes read in 30 ms (609.4 KiB/s)           =>dcache flush           =>bootaux 0x9ff00000                ##Starting auxiliary core at 0x9FF00000                ... Attach M4 using the m4.cmm file(attached) In this case you will the A9 uart console still can work, after you break M4. Disable DBGEN case at M4 side: Load M4 image into memory and kick off M4.   =>fatload mmc 2:1 0x9ff00000 hello_world_ddr.bin                     reading hello_world_ddr.bin 18748 bytes read in 30 ms (609.4 KiB/s)           =>dcache flush           =>bootaux 0x9ff00000          ##Starting auxiliary core at 0x9FF00000 Attach M4 using the m4_disable_dbgen.cmm  file(attached) In this case you will the A9 uart console still can work, after you break M4.   Notes: For more trace32 usage, please refer to http://www.lauterbach.cn/           For more imx6sx information, please refer to i.MX 6SoloX Family of Applications Processors|NXP.
View full article
NOTE: Always de-power the target board and the aggregator when plugging or unplugging smart sensors from the aggregator. The aggregator portion of the i.MX Power Profiling System sits between the "smart" current sensor boards and the host computer. It provides power and signal connections to each connected sensor board. The communication is done over I2C, where three I2C bus extenders (PCA9518) effectively provide a dedicated bus to each I2C device, to better allow for cabling.  More information will follow... A photo, layout images and schematic attached below.   MBED source for the FRDM-KL25Z is available here: 30848-KL25Z-AGGREGATOR    Smart Sensor Connections At each smart sensor header JP0-JP13, these are the connections provided: 5V: powers the 3.3V regulator on each sensor board 12V: all the gates of all the switching FETs are pulled pulled up to 12V GND: ground connection SCL/TX0: I2C clock line  SDA/RX0: I2C data line  SWD_CLK:  global line for triggering smart sensors to make measurements RESET_B:  global line for resetting all smart sensor boards SWD_IO_n: individual select line for each smart sensor I2C Bus Connection Three I2C bus extenders (PCA9518) provide buffered connections between the FRDM board and all the connected smart sensors. The bus extenders were added to allow for longer cables between the aggregator and the smart sensor boards. Each bus extender has five ports and along with connections that allow extending the bus to more bus extenders. Gate Supply The aggregator contains a boost regulator that boost the 5V input from the FRDM board to 12V. The boosted voltage is fed to each of the smart sensor headers. It's used by the smart sensor board to pull up the gates of the switching FETs above any of the rails under test by at least 4.5V in order to benefit from a lower Rds(on). Caution must be exercised with some older FRDM boards since the 5V from the USB connection passes through diodes with a maximum current of 200mA.  The boost regulator and the load presented by the smart sensor boards may exceed the diode's limit and damage it. (Yes, it's happened... two older FRDM-KL25Z boards were used during development. One of them failed with the diode shorted (~0.05 Ohms), so everything kept working. The other failed with a  short of ~45 Ohms, so it kind of worked but not really...) Application Code for Aggregator  To date, application code has only been developed for the FRDM-KL25Z board. The latest application code resides at: https://os.mbed.com/users/r14793/code/30848-KL25Z-AGGREGATOR/, with the latest binary attached below. SWD Programming of Smart Sensors  Connectors J5 and JP15 are provided as an adapter for programming the smart sensor boards via SWD. JP15 provides power to the smart sensor board, since they have no direct 3.3V input for the KL05Z. An SWD programmer (or suitably modified FRDM-KL05Z board) connects to J5. Both connections use 10-pin 0.05"-spaced ribbon cables. Additionally, when a smart sensor is connected to JP15, J6 provides access to the UART pins of the smart sensor (the I2C pins on the smart sensor also mux out the UART of the KL05Z). No hardware changes are necessary at all; changing the code running on the smart sensor is all that's required. In fact, during the initial prototyping of the smart sensors, the serial UART connection was used instead of I2C. Modify Aggregator To Use SWD Dongle To Program Smart Sensor:  Add a wire as shown on the bottom side of the aggregator board as shown below. This ties 3.3V on the aggregator to the debug header, enabling the voltage level translators on the dongle to communicate with the KL05Z on the smart sensor board.  
View full article
[中文翻译版] 见附件   原文链接: https://community.nxp.com/docs/DOC-343518 
View full article
The document descript how to use the win32diskimager to create bootable sdcard.  How to resize sdcard mirror rootfs partition. Ex: fsl-image-validation-imx-imx6qpdlsolox.sdcard
View full article