Jump to content
43oh

pabigot

Members
  • Content Count

    577
  • Joined

  • Last visited

  • Days Won

    30

Reputation Activity

  1. Like
    pabigot got a reaction from xpg in MSP debug stack no longer open source   
    Just a heads up for those concerned with software licensing: although TI has open-sourced the MSP Debug Stack, in fact it now contains material that is not open-source, related to an Energy Trace facility. That facility and the change in licensing appeared in June 2013 in slac460f, prior to which this package was entirely BSD.
     
    I've confirmed that objects derived from the sources with the TI TSPA license (displayed below) are present in libmsp430.so, which appears to bring the licensing below into effect. There is a single API header which is BSD-3-Clause, but to use it would explicitly invoke material that is restricted.
     
    Anybody using the MSP debug stack who has not reviewed the license on each new release should be made aware of the change and consult qualified legal counsel as appropriate.
     

    /* * EnergyTraceProcessor.h * * Copyright (c) 2007 - 2013 Texas Instruments Incorporated - http://www.ti.com/ * * All rights reserved not granted herein. * Limited License. * * Texas Instruments Incorporated grants a world-wide, royalty-free, * non-exclusive license under copyrights and patents it now or hereafter * owns or controls to make, have made, use, import, offer to sell and sell ("Utilize") * this software subject to the terms herein. With respect to the foregoing patent * license, such license is granted solely to the extent that any such patent is necessary * to Utilize the software alone. The patent license shall not apply to any combinations which * include this software, other than combinations with devices manufactured by or for TI (<93>TI Devices<94>). * No hardware patent is licensed hereunder. * * Redistributions must preserve existing copyright notices and reproduce this license (including the * above copyright notice and the disclaimer and (if applicable) source code license limitations below) * in the documentation and/or other materials provided with the distribution * * Redistribution and use in binary form, without modification, are permitted provided that the following * conditions are met: * * * No reverse engineering, decompilation, or disassembly of this software is permitted with respect to any * software provided in binary form. * * any redistribution and use are licensed by TI for use only with TI Devices. * * Nothing shall obligate TI to provide you with source code for the software licensed and provided to you in object code. * * If software source code is provided to you, modification and redistribution of the source code are permitted * provided that the following conditions are met: * * * any redistribution and use of the source code, including any resulting derivative works, are licensed by * TI for use only with TI Devices. * * any redistribution and use of any object code compiled from the source code and any resulting derivative * works, are licensed by TI for use only with TI Devices. * * Neither the name of Texas Instruments Incorporated nor the names of its suppliers may be used to endorse or * promote products derived from this software without specific prior written permission. * * DISCLAIMER. * * THIS SOFTWARE IS PROVIDED BY TI AND TI<92>S LICENSORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, * BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. * IN NO EVENT SHALL TI AND TI<92>S LICENSORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, * OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE * POSSIBILITY OF SUCH DAMAGE. */
  2. Like
    pabigot reacted to drkm in Optimizing LPM Current on EXP430FR5969 (and other boards)   
    When a GPIO in an input state the input is high impedance. Meaning that there is a large resistance between the any voltage that could be present on the pin and the GND/0V. Since V=IR, if R is high then we can guarantee that the current will be low. 
     
    Pulling the pin low with a pull down resistor provides a path to ground (while maintaining a large input impedance) that any stray EMI from say an ossilator or power supply.
     
    When a GPIO is set to an output it is either sinking or sourcing current. Meaning that if you were to pull the line low you are allowing the current path to go through the processor through the pin. ( I am simplifying this a fair bit since there are protection diodes, ect).
     
    Does that make this clearer? Like I said earlier, the enviroment has alot to do with these variables as well. If you were working on a small board that had a ossilator ossilating at high frequencies, EMI becomes an issue.
     
    For the RX pins that you are disconnecting, ect. I would leave the pins in high impedance such that if you had an accident or misplaced wire the risk of destroying something goes down significantly since there is no "easy" path to ground. 
  3. Like
    pabigot got a reaction from bluehash in Execution time - the easy way   
    Excellent; thank you. For reference, here's a portable version using CMSIS, checked on Tiva and EFM32 processors. (You will need to include the CMSIS device header, e.g. TIVA.h for TM4C and em_device.h for EFM32. That's hidden in bspacm/core.h below.)
     
    For reference, the necessary information is in the ARMv7-M Architecture Reference Manual; you have to register with ARM to download the PDF. See sections C1.6.5 for DEMCR and C1.8 for DWT.
     

    /* BSPACM - demonstrate cycle counter interface * * Written in 2014 by Peter A. Bigot <http://pabigot.github.io/bspacm/> * * To the extent possible under law, the author(s) have dedicated all * copyright and related and neighboring rights to this software to * the public domain worldwide. This software is distributed without * any warranty. * * You should have received a copy of the CC0 Public Domain Dedication * along with this software. If not, see * <http://creativecommons.org/publicdomain/zero/1.0/>. */ #include <bspacm/core.h> #include <stdio.h> #define BSPACM_CORE_ENABLE_CYCCNT() do { \ if (! (DWT_CTRL_NOCYCCNT_Msk & DWT->CTRL)) { \ CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk; \ DWT->CYCCNT = 0; \ DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk; \ } \ } while (0) #define BSPACM_CORE_DISABLE_CYCCNT() do { \ if (! (DWT_CTRL_NOCYCCNT_Msk & DWT->CTRL)) { \ DWT->CTRL &= ~DWT_CTRL_CYCCNTENA_Msk; \ CoreDebug->DEMCR &= ~CoreDebug_DEMCR_TRCENA_Msk; \ } \ } while (0) #define BSPACM_CORE_CYCCNT() DWT->CYCCNT #define BSPACM_CORE_DELAY_CYCLES(cycles_) do { \ uint32_t const delta = (cycles_); \ uint32_t const cc0 = DWT->CYCCNT; \ while ((DWT->CYCCNT - cc0) < delta) { \ /* spin */ \ } \ } while (0) void main () { uint32_t cc0 = 0; BSPACM_CORE_ENABLE_INTERRUPT(); printf("\n" __DATE__ " " __TIME__ "\n"); printf("System clock %lu Hz\n", SystemCoreClock); if (DWT_CTRL_NOCYCCNT_Msk & DWT->CTRL) { printf("DWT does not support cycle counting\n"); return; } BSPACM_CORE_ENABLE_CYCCNT(); do { uint32_t cc1 = DWT->CYCCNT; uint32_t delta = cc1 - cc0; printf("Cycle counter %lu, delta %lu\n", cc1, delta); cc0 = cc1; BSPACM_CORE_DELAY_CYCLES(8000000U); } while (1); }
  4. Like
    pabigot got a reaction from xpg in The Datasheet "Book Club"   
    Today's research is on Cortex-M sleep modes and interrupt handling. I'm still digesting the bulk of it, but the short form is there are three common operational modes (RUN, SLEEP, DEEP SLEEP) that are implemented through Cortex-M instructions WFI/WFE and bits in the SCR. (Anything lower than DEEP SLEEP, like "hibernate" or EM3/EM4, is probably vendor-specific). Based on a sample size of two (TM4C and EFM32), RUN and SLEEP are simple, but DEEP SLEEP can reconfigure your processor and peripheral clocks back to their power-up defaults. PRIMASK plays an important role in this too, if you want to be sure all interrupts are handled before you commit to sleeping. (Which you probably do, if what your interrupts do includes assumptions that the clocks are configured in a particular way.)
     
    The "book-club" relevant part is that section 5.2.6 "System Control" of the TM4C123GH6PM datasheet clearly specifies that software must confirm the EEPROM is not busy prior to entering either SLEEP or DEEP SLEEP. TivaWare's ROM_SysCtl*Sleep and CPUwfi() don't do this explicitly, though many of the EEPROM_* commands do check EEPROM.EEDONE before returning. Keep this in mind if you happen to be mucking with the EEPROM just before going to sleep, say, maybe to save some state in non-volatile memory.
  5. Like
    pabigot got a reaction from igor in On Bit-Banding   
    Having reached a new stage of enlightenment, what I wrote in another topic turns out to be wrong. I can't find any other posts here that discuss bit-banding in detail, so I'm starting this so the correction is easier to find. See also the relevant section of Cortex-M3 Application Note 179.
     
    I had said:
    This second use which allows manipulation of GPIO pins with only certain pins being modified is really cool and slick and is not bit-banding.
     
    It works because TI's implementation provides a 256-element array map to the state of the eight pins supported by each GPIO module. In Energy Micro's GPIO interface, which has 16 pins per port, the same problem is solved by having DOUTSET, DOUTCLR, and DOUTTGL registers which set, clear, and toggle (respectively) the GPIO pins for which a 1 is set in the word written to the register.
     
    Bit-banding is specifically mapping each bit of an addressable 32-bit word to thirty-two consecutive addressable words for which only bit 0 is significant in each. In the Cortex-M architecture it can be done for words in either one 1MB region of SRAM or one 1MB region of the peripheral memory. Only bit 0 of the RHS is relevant to the assignment regardless of which bit in the original location is acccessed, unlike the case above where it was only bits 2 and 6 of the RHS that were relevant.
     
    Bit-banding is not useful for the original example (enabling two distinct bits in a register simultaneously). It is useful for enabling or disabling a single bit without affecting its neighbors, or eliminating a window of vulnerability if an interrupt might occur during the multi-instruction read-modify-write sequence that the ARM instruction set requires. (MSP430 has instructions that set and clear multiple bits in a value atomically; ARM does not, and bitbanding solves that problem for the case of a single-bit manipulation. The DOUTSET/DOUTCLR approach of EFM32 is much closer to the MSP430 model.)
     
    If the address of the word being modified and the bit index are not known at compile time, there will be little to no code savings from using bit-banding: the calculation for the address is:

    #define BITBAND_SRAM(word_, bit_) (*(volatile uint32_t *)((BITBAND_RAM_BASE + 4 * ((bit_) + 8 * ((uintptr_t)&(word_) - SRAM_BASE))))) #define BITBAND_PER(word_, bit_) (*(volatile uint32_t *)((BITBAND_PER_BASE + 4 * ((bit_) + 8 * ((uintptr_t)&(word_) - PER_RAM_BASE))))) which can be optimized to a constant only if both &word_ and bit_ are compile-time constants. 
    Bit-banding is used extremely rarely in TI's driverlib (only in SysCtlPeripheral functions, and the motivation in those situations is unclear). It's used somewhat more frequently in Energy Micro's emlib.
     
    The primary use I can see for it in user code is to set a flag in a word that holds shared state without having to disable interrupts. It is used in quite a few TivaWare examples this way:

    HWREGBITW(&g_ui32Flags, FLAGS_STREAMING) = 1;
  6. Like
    pabigot got a reaction from bluehash in The Datasheet "Book Club"   
    Today's research is on Cortex-M sleep modes and interrupt handling. I'm still digesting the bulk of it, but the short form is there are three common operational modes (RUN, SLEEP, DEEP SLEEP) that are implemented through Cortex-M instructions WFI/WFE and bits in the SCR. (Anything lower than DEEP SLEEP, like "hibernate" or EM3/EM4, is probably vendor-specific). Based on a sample size of two (TM4C and EFM32), RUN and SLEEP are simple, but DEEP SLEEP can reconfigure your processor and peripheral clocks back to their power-up defaults. PRIMASK plays an important role in this too, if you want to be sure all interrupts are handled before you commit to sleeping. (Which you probably do, if what your interrupts do includes assumptions that the clocks are configured in a particular way.)
     
    The "book-club" relevant part is that section 5.2.6 "System Control" of the TM4C123GH6PM datasheet clearly specifies that software must confirm the EEPROM is not busy prior to entering either SLEEP or DEEP SLEEP. TivaWare's ROM_SysCtl*Sleep and CPUwfi() don't do this explicitly, though many of the EEPROM_* commands do check EEPROM.EEDONE before returning. Keep this in mind if you happen to be mucking with the EEPROM just before going to sleep, say, maybe to save some state in non-volatile memory.
  7. Like
    pabigot got a reaction from spirilis in On Bit-Banding   
    Having reached a new stage of enlightenment, what I wrote in another topic turns out to be wrong. I can't find any other posts here that discuss bit-banding in detail, so I'm starting this so the correction is easier to find. See also the relevant section of Cortex-M3 Application Note 179.
     
    I had said:
    This second use which allows manipulation of GPIO pins with only certain pins being modified is really cool and slick and is not bit-banding.
     
    It works because TI's implementation provides a 256-element array map to the state of the eight pins supported by each GPIO module. In Energy Micro's GPIO interface, which has 16 pins per port, the same problem is solved by having DOUTSET, DOUTCLR, and DOUTTGL registers which set, clear, and toggle (respectively) the GPIO pins for which a 1 is set in the word written to the register.
     
    Bit-banding is specifically mapping each bit of an addressable 32-bit word to thirty-two consecutive addressable words for which only bit 0 is significant in each. In the Cortex-M architecture it can be done for words in either one 1MB region of SRAM or one 1MB region of the peripheral memory. Only bit 0 of the RHS is relevant to the assignment regardless of which bit in the original location is acccessed, unlike the case above where it was only bits 2 and 6 of the RHS that were relevant.
     
    Bit-banding is not useful for the original example (enabling two distinct bits in a register simultaneously). It is useful for enabling or disabling a single bit without affecting its neighbors, or eliminating a window of vulnerability if an interrupt might occur during the multi-instruction read-modify-write sequence that the ARM instruction set requires. (MSP430 has instructions that set and clear multiple bits in a value atomically; ARM does not, and bitbanding solves that problem for the case of a single-bit manipulation. The DOUTSET/DOUTCLR approach of EFM32 is much closer to the MSP430 model.)
     
    If the address of the word being modified and the bit index are not known at compile time, there will be little to no code savings from using bit-banding: the calculation for the address is:

    #define BITBAND_SRAM(word_, bit_) (*(volatile uint32_t *)((BITBAND_RAM_BASE + 4 * ((bit_) + 8 * ((uintptr_t)&(word_) - SRAM_BASE))))) #define BITBAND_PER(word_, bit_) (*(volatile uint32_t *)((BITBAND_PER_BASE + 4 * ((bit_) + 8 * ((uintptr_t)&(word_) - PER_RAM_BASE))))) which can be optimized to a constant only if both &word_ and bit_ are compile-time constants. 
    Bit-banding is used extremely rarely in TI's driverlib (only in SysCtlPeripheral functions, and the motivation in those situations is unclear). It's used somewhat more frequently in Energy Micro's emlib.
     
    The primary use I can see for it in user code is to set a flag in a word that holds shared state without having to disable interrupts. It is used in quite a few TivaWare examples this way:

    HWREGBITW(&g_ui32Flags, FLAGS_STREAMING) = 1;
  8. Like
    pabigot got a reaction from Lyon in Execution time - the easy way   
    Excellent; thank you. For reference, here's a portable version using CMSIS, checked on Tiva and EFM32 processors. (You will need to include the CMSIS device header, e.g. TIVA.h for TM4C and em_device.h for EFM32. That's hidden in bspacm/core.h below.)
     
    For reference, the necessary information is in the ARMv7-M Architecture Reference Manual; you have to register with ARM to download the PDF. See sections C1.6.5 for DEMCR and C1.8 for DWT.
     

    /* BSPACM - demonstrate cycle counter interface * * Written in 2014 by Peter A. Bigot <http://pabigot.github.io/bspacm/> * * To the extent possible under law, the author(s) have dedicated all * copyright and related and neighboring rights to this software to * the public domain worldwide. This software is distributed without * any warranty. * * You should have received a copy of the CC0 Public Domain Dedication * along with this software. If not, see * <http://creativecommons.org/publicdomain/zero/1.0/>. */ #include <bspacm/core.h> #include <stdio.h> #define BSPACM_CORE_ENABLE_CYCCNT() do { \ if (! (DWT_CTRL_NOCYCCNT_Msk & DWT->CTRL)) { \ CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk; \ DWT->CYCCNT = 0; \ DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk; \ } \ } while (0) #define BSPACM_CORE_DISABLE_CYCCNT() do { \ if (! (DWT_CTRL_NOCYCCNT_Msk & DWT->CTRL)) { \ DWT->CTRL &= ~DWT_CTRL_CYCCNTENA_Msk; \ CoreDebug->DEMCR &= ~CoreDebug_DEMCR_TRCENA_Msk; \ } \ } while (0) #define BSPACM_CORE_CYCCNT() DWT->CYCCNT #define BSPACM_CORE_DELAY_CYCLES(cycles_) do { \ uint32_t const delta = (cycles_); \ uint32_t const cc0 = DWT->CYCCNT; \ while ((DWT->CYCCNT - cc0) < delta) { \ /* spin */ \ } \ } while (0) void main () { uint32_t cc0 = 0; BSPACM_CORE_ENABLE_INTERRUPT(); printf("\n" __DATE__ " " __TIME__ "\n"); printf("System clock %lu Hz\n", SystemCoreClock); if (DWT_CTRL_NOCYCCNT_Msk & DWT->CTRL) { printf("DWT does not support cycle counting\n"); return; } BSPACM_CORE_ENABLE_CYCCNT(); do { uint32_t cc1 = DWT->CYCCNT; uint32_t delta = cc1 - cc0; printf("Cycle counter %lu, delta %lu\n", cc1, delta); cc0 = cc1; BSPACM_CORE_DELAY_CYCLES(8000000U); } while (1); }
  9. Like
    pabigot got a reaction from abc in MSP430 vs Silicon Labs efm32   
    Again, most of these concerns need to be answered in context. For the reliability ones, if you're installing into extreme conditions, they're going to matter. If the product sits on a table in a residence, they probably don't.
     
    For bugs, as long as you're not working with early stage experimental silicon, it's unlikely you'll come across any that are unknown or don't have reasonable workarounds. When you read the errata list for an MCU, make sure you understand the conditions under which the problem can arise: some of them sound pretty horrible, but in the real world just aren't going to be relevant.
  10. Like
    pabigot got a reaction from bluehash in How slow can MSP430 run?   
    Probably as slow as you can find a clock to feed it. Without hardware modifications, selecting VLOCLK as the source for MCLK would put it about 10kHz. Haven't tried that personally.
     
    It's not likely to be useful, though. The slower it runs, the longer it takes to do the work. The optimum speed for least power for a given task is almost certainly not going to be the slowest speed, even if that produces the lowest-power per unit time. You'd have to calculate based on duty cycles, durations of tasks, and a bunch of other application-specific information.
  11. Like
    pabigot got a reaction from abc in How slow can MSP430 run?   
    Probably as slow as you can find a clock to feed it. Without hardware modifications, selecting VLOCLK as the source for MCLK would put it about 10kHz. Haven't tried that personally.
     
    It's not likely to be useful, though. The slower it runs, the longer it takes to do the work. The optimum speed for least power for a given task is almost certainly not going to be the slowest speed, even if that produces the lowest-power per unit time. You'd have to calculate based on duty cycles, durations of tasks, and a bunch of other application-specific information.
  12. Like
    pabigot got a reaction from abecedarian in How slow can MSP430 run?   
    Probably as slow as you can find a clock to feed it. Without hardware modifications, selecting VLOCLK as the source for MCLK would put it about 10kHz. Haven't tried that personally.
     
    It's not likely to be useful, though. The slower it runs, the longer it takes to do the work. The optimum speed for least power for a given task is almost certainly not going to be the slowest speed, even if that produces the lowest-power per unit time. You'd have to calculate based on duty cycles, durations of tasks, and a bunch of other application-specific information.
  13. Like
    pabigot got a reaction from tripwire in How slow can MSP430 run?   
    Probably as slow as you can find a clock to feed it. Without hardware modifications, selecting VLOCLK as the source for MCLK would put it about 10kHz. Haven't tried that personally.
     
    It's not likely to be useful, though. The slower it runs, the longer it takes to do the work. The optimum speed for least power for a given task is almost certainly not going to be the slowest speed, even if that produces the lowest-power per unit time. You'd have to calculate based on duty cycles, durations of tasks, and a bunch of other application-specific information.
  14. Like
    pabigot reacted to enl in Reversing the LED? i.e. sinking it to MCU?   
    See SLAS735 (MSP430G2X53 datasheet, or other device datasheets) for the graphs. SLAS735G, fig 6-9, "Typical characteristics, Outputs" shows the curent vs output potential vs supply potential.
     
    The MSP430 devices are pretty much symmetric with respect to sourcing and sinking. Driving at too high a current may not *immediately* damage an output, but driving an LED without a limiting resistor (or current limiting driver) will likely either smoke the LED or damage the I/O in the microcontroller eventually. The damage may not happen immediately, but the drive transistor will be dissipating power due to the potential drop, and will fail sooner or later due to the cumulative effect of the heat. A good rule is no more load than keeps you within the safe spec for logic signals, which is about 12mA at 3V for the MSP430G series. Half that is better. Many LEDs will fail very quickly even with fairly small overcurrent.
     
    Remember, the I-V curve for an LED, like any diode, is substantially exponential. Small increase in potential, large increase in current.
     
    Driving individual LEDs isn't a big deal these days. At 4mA (the drive current for the red LED on the launchpad), modern high efficiency devices are as bright as or brighter than the 20mA devices 20 years ago. Not lighting bright, but display and indicator bright, even outdoors during the day. Blinding in a poorly lit room.
     
    Any more current than this, it is best to use an external driver (NPN transistor to ground with limit resistor; current limiting LED driver IC; etc). When driving multiple LEDs from an output (multiplex display, etc) you pretty much need to use external drivers, as, even when PWM'd to low *average* current, the instantaneous current will be an issue.
     
    Also note that overloading the GPIO pins, for example with an LED, may effect UART by dropping the internal power bus or raising the internal ground bus: the UART output won't go full supply range. If all you are doing is lighting LEDs, not a big deal until the core can't run anymore (3V supply, that can be as low as 35 to 40mA total, depending on the temperature)
  15. Like
    pabigot got a reaction from bluehash in Turning MSP430 into an amperemeter - possible?   
    Very interesting. From the MSP430_EnergyTrace header in the source release (which is BSD-3-Clause):
     

    Record format ------------- The default record format for operation mode 1 for the MSP430FR5859 is 22bytes for each record consisting of: [8byte header][8byte device State][4byte current I in nA][2byte voltage V in mV][4byte energy E in uWsec=uJ] Where the header consists of: [1byte eventID][7byte timestamp in usec] The eventID defines the number of arguments following the header. eventID = 1 : I value, 32 bits current eventID = 2 : V value, 16 bits voltage eventID = 3 : I & V values, 32 bits current, 16 bits voltage eventID = 4 : S value, 64 bits state (default type for ET_PROFILING_DSTATE) eventID = 5 : S & I values, 64 bits state, 32 bits current eventID = 6 : S & V values, 64 bits state, 16 bits voltage eventID = 7 : S & I & V & E values, 64 bits state, 32 bits current, 16 bits voltage, 32 bits energy (default type for ET_PROFILING_ANALOG_DSTATE) eventID = 8 : I & V & E values, 32 bits current, 16 bits voltage, 32 bits energy (default type for ET_PROFILING_ANALOG) eventID = 9 : S & I & V values, 64 bits state, 32 bits current, 16 bits voltage Sampling frequencies from 100 Hz to 100 kHz. 
    It's probably the same general solution as Energy Micro uses for the energyAware Profiler.
     
    Might be a capability that could be added to mspdebug when using the tilib driver.
     
    Tempting project, but I really need to focus on BSPACM for now.
     
    *EDIT* See http://forum.43oh.com/topic/5364-msp-debug-stack-no-longer-open-source/ for licensing restrictions related to this feature.
  16. Like
    pabigot reacted to greeeg in Turning MSP430 into an amperemeter - possible?   
    I noticed that the new Wolverine launchpad has an EnergyTrace feature.
    It is reported in the change log
    New device support: .. MSP430FR5969 revF Family (full EnergyTrace and ULP feature support) New features: .. Added EnergyTrace I wonder if this will be a similar kind of thing. I havent found any other documentation on it.
    (But the source is freely available, Hmmm)
  17. Like
    pabigot got a reaction from 215 in Default handler ???   
    Stupid question, but did you enable the clock module for GPIOC? In CMSIS form:

    SYSCTL->RCGCGPIO |= SYSCTL_RCGCGPIO_R2; No idea how you do that in TivaWare but there'll be some command.
  18. Like
    pabigot got a reaction from abc in Optimizing LPM Current on EXP430FR5969 (and other boards)   
    tl;dr: the recommended common configuration for pins for low-power mode applies only to unconnected pins. For unused but connected pins, it might be the wrong approach.
     
    As requested:
     
    While doing power tests with the EXP430FR5969 LaunchPad I noticed an anomaly related to the RX jumper in block J13 connecting the XSP430FR5969 to the emulator:
    If P2SEL1.1 is clear (P1.2 is a GPIO) and J13.RX is shorted, current draw is high in LPM3.5. If P2SEL1.1 is clear (P1.2 is a GPIO) and J13.RX is open, current draw is low in LPM3.5. If P2SEL1.1 is set (P1.2 is EUSCI_A0.RX) and J13.RX is shorted, current draw is low in LPM3.5. If P2SEL1.1 is set (P1.2 is EUSCI_A0.RX) and J13.RX is open, current draw is high in LPM3.5. I encountered this because standard practice in LPM on MSP430 is to configure all pins except LFXIN/LFXOUT to either input+pullup/pulldown or output/ground. The latter is what's used in the EXP430FR5969 Out-of-Box Experience code and is what I selected for BSP430's API. 
    In the application I was working with, I was using EUSCI_A0 as a back-channel UART to display the voltage being presented by the supercap, as collected once per minute.
     
    Experience with earlier MSP430s suggested that in many cases leaving a peripheral enabled forces the clocks the peripheral depends on to remain active, even when supposedly entering LPM levels that would normally turn them off. To cut down on power I wanted to turn off EUSCI_A0 prior to entering LPM so the clock request wouldn't override my intent.
     
    BSP430's serial abstraction provides three levels of "off" for peripherals: iBSP430serialSetReset_rh() simply controls the software reset bit, leaving the GPIOs in their peripheral configuration. iBSP430serialSetHold_rh() goes further, deconfiguring the GPIOs and putting them into the default low-power mode (output low). Both of these can be reversed by re-invoking the function with an enable flag. iBSP430serialClose() deconfigures the peripheral and the pins it depends on and forgets what the configuration was.
     
    I started with "reset" (disable the peripheral, leave the GPIOs configured in the UART function). For power evaluation on the EXP430FR5969 one's supposed to disconnect the eZFET side of the board from the MSP430 side by removing the jumpers on J13. There are eight individual jumpers on that header, and it's a real PITA to pull them off, chase down the ones that flew across the room, put them all back on to reprogram, etc.
     
    For my application, I wanted TX to remain connected so I could see the output each time the thing woke up. Serendipitously, I discovered that I could achieve the nominal 400nA LPM3.5 current (actually, I was getting 250nA) by leaving RTS and CTS off all the time, and only removing the Vin jumper as I went between capacitor-power testing and reprogramming.
     
    Much simpler.  This lasted until I was happy with everything, then decided I should be using the "hold" variant because clearly putting the GPIOs into low-power mode might reduce power even more, no?
     
    No. All of a sudden I couldn't get anything below 4uA in LPM3.5 any more.
     
    Fussing about ensued, with the eventual discovery above: something about being configured in GPIO mode made it necessary to remove the RX jumper, while leaving RX shorted is fine if the pin is in its UART configuration.
     
    I'm sure those who are EEs can explain exactly what's happening, and why, and never (well, hardly ever) make such mistakes.
     
    The takeaway, though, is that when the user's guide recommends input/pulldown/pullup or output low as the default configuration for LPM for "unused pins", they really mean unconnected pins. Which is different, especially on evaluation/experimenter boards where there are all kinds of features that aren't being used for a particular application. For the EXP430FR5969, the recommended configuration happens to work for most of the pins that cross the J13 header, but not for RX (and CTS; RTS is fine), presumably because of what they're connected to on the ezFET side of the board.
     
    Beware: It'll also hold for pins on boards where there isn't a jumper you can remove for power testing.
     
    So: As usual, the basic rule doesn't always apply. Make assumptions, fine; but test them, and if something doesn't make sense, take the time to analyze it and figure out what's going wrong.
     
    And explain it all here on the forums so others can benefit from your experiences or correct your misunderstandings. (I'm not going to get any real work done the rest of this week, am I? Didn't think so....)
  19. Like
    pabigot got a reaction from jpnorair in MSP430 vs Silicon Labs efm32   
    Culprit explained here.
     
    I believe it should be possible to use the energyAware Profiler with external boards. My intent is to do this, but I haven't gotten there yet. Probably next week, though. (Edit: See details in EFM32 AN0027 on Energy Optimization.)
     
    Still worth having a uCurrent on your desk; cost you about $60, plugs into your multimeter. High ratings from Adafruit, though they don't have them in stock right now.
  20. Like
    pabigot got a reaction from abc in MSP430 vs Silicon Labs efm32   
    Radios, displays, and misconfigured pins are far more dominating factors than the MCUs that I've been working with, which is why it's important to be able to confirm that when the chip is supposed to sleep at 400nA it really is doing so. So I like having at least enough accuracy for tenths of a microamp. The uCurrent is the best tool I've found for that, though the LOG114 might work if I had the EE background to use it properly.
     
    I blew a couple hours earlier this week coming to understand why disabling the UART on the EXP430FR5969 increased current draw during sleep (from 250nA to 30+uA). Sometimes I make a similar "insignificant" change and later find out that "sleep" is now at 200uA. Low power applications design isn't entirely trivial, and good validation tools are pretty important.
  21. Like
    pabigot got a reaction from spirilis in MSP430 vs Silicon Labs efm32   
    Radios, displays, and misconfigured pins are far more dominating factors than the MCUs that I've been working with, which is why it's important to be able to confirm that when the chip is supposed to sleep at 400nA it really is doing so. So I like having at least enough accuracy for tenths of a microamp. The uCurrent is the best tool I've found for that, though the LOG114 might work if I had the EE background to use it properly.
     
    I blew a couple hours earlier this week coming to understand why disabling the UART on the EXP430FR5969 increased current draw during sleep (from 250nA to 30+uA). Sometimes I make a similar "insignificant" change and later find out that "sleep" is now at 200uA. Low power applications design isn't entirely trivial, and good validation tools are pretty important.
  22. Like
    pabigot reacted to jpnorair in MSP430 vs Silicon Labs efm32   
    I use a LOG114 EVM board and a scope to measure low currents on MCUs.  It's quite ideal for this, because it can measure transitions from the uA range to the mA range in us.  Also, for me it has always reported measurements that are bang-on to reference.
     
    I would expect the EFM32 to have higher sleep current than RF5969 does, when RAM is being retained, because they are both built on a similar 130nm low-leakage process yet the EFM has more RAM.  More RAM = more transistors = more leakage.
  23. Like
    pabigot got a reaction from abc in MSP430 vs Silicon Labs efm32   
    The EFM32 has something they call a "peripheral reflex system", which as I understand it allows completion of one peripheral action to cue another without MCU involvement. Something like DMA, but generalized.
     
    Hand waving; I haven't gotten to that point in my experiments yet. But in concept I believe this is supposed to be more efficient than the MSP430 interrupt-driven approach, or less limited that MSP430's trigger mechanism.
  24. Like
    pabigot reacted to wasson65 in Demographics of embedded development   
    I'm no spring chicken (45) and this is my guess:  When I started programming (34 years ago...), being a computer user almost always meant being a computer programmer, and being a computer programmer almost always meant that you had to have knowledge of the systems you were programming on.
     
    In other words, I think 25 years ago, there was naturally more overlap between programmers and those interested in electronics and hardware.  I mean, people used to purchase ram chips and put them into ISA boards with sockets on them to expand their memory.
     
    Now, people's phones are multiple orders of magnitude more powerful than those early computers were.  And there are lots of computer programmers who have learned how to program in high level languages and never have had to actually worry about twiddling bits outside of some basic lab in college.
     
    So, a large percentage of the 'programming' population has never had to think much about memory usage, understand how data is actually stored, understand what 'endian' means.  The connection to any particular piece of hardware has been abstracted away under so many layers of layers, that somehow it's thought that actually touching hardware is somehow mysterious and difficult.  
     
    Additionally, there is another thing: VLSI.  When the circuit boards are just two layers, and the chips don't have hundreds of millions of gates, it was actually possible to look at a physical circuit board, look at the traces, look at the connectors, look at the chips, and almost extract the entire logical schematic.  Today's schematics are almost useless as they simply show 250 lines going into one big block marked U0.  How do you even begin to understand it by observation?  There's no way.  The bottom rungs of the ladder have been knocked off.
     
    Sad.  I'm so thankful I was born when I was, because any earlier, and I would not have had my own computer at a very young age, and any later and the computer would have been so powerful it would have been nothing more than a magic box.
  25. Like
    pabigot got a reaction from bluehash in SHARP Memory Display Booster Pack   
    Two items:
     
    * A solution to RWB's issue was to add a new linker section for read-write data in FRAM, and use the DATA_SECTION pragma to place the display buffer into it. I've sent him the code.
     
    * I've updated bsp430 (in branch next) to support the 128x128 and 400x240 displays; this was trivial and probably any reasonable SharpLCD can be used there without modifying the code.
     
    These are nice little puppies, but I'd be much happier if they were installed on an aircraft aluminum backing with at least a half inch border on each edge. The dental silicone I'm using to temporarily keep them from flopping off the PCBs is a poor solution, and the big one extends so far beyond the PCB edges I have to really try to remember not to use the display for leverage while pulling the SPI/power/signal cable off the breakout's headers.
×
×
  • Create New...