Jump to content
43oh

pabigot

Members
  • Content Count

    577
  • Joined

  • Last visited

  • Days Won

    30

Everything posted by pabigot

  1. 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 vol
  2. 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.
  3. The uCurrent is indeed great, but I've only gotten it to work with a DMM, which is fine when the system stays in whatever mode I want to measure long enough to turn my head and read the display. My attempts to use it with a scope result in the unit under test rebooting; I'm told this is because of ground incompatibilities. This makes it difficult to get the power profile over time. I'm hoping the energyAware Profiler will eliminate this. Relevance is: Yes, it's clearly sub 500nA in LPM3.5 for the XSP430FR5969. But how long does it take to come up, put everything back together, service the
  4. Yeah, default for any "unused" pin is output low, so I can imagine that caused electrons to flow. Maybe outputting high would solve it, or maybe making it an input with pullup or pulldown. There didn't seem to be any benefit in going that way: it was just as easy to leave the GPIOs configured in the UART function; it's just that I hadn't thought that'd be necessary. The essential point is: the default rule isn't going to work in all cases, and when it doesn't the cost can be high. I think I actually saw this first because at one stage I was checking RX on power-up to see if it was pulled
  5. 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.
  6. 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,
  7. 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).
  8. The baud rate setting is constant for converting an input clock at a particular rate to a specific baud rate. If you were using a different clock rate for your timer, you would need to calculate different baud rate settings. Glancing at your code, it appears you are using the same clock rate (I didn't check whether the baud or timer settings are right). I don't see you setting up to use the LF crystal, so the DCO rate may be inaccurate, resulting in the UART timing being off and so failing to communicate with the PC. Or, since you can communicate with UART sometimes, it could be that
  9. You can clock as many peripherals as you like from the same source, but they all have to be configured consistently. Presumably your UART expects SMCLK at a frequency that is different from the one you use for TA0. Change the UART configuration to match and it'll work fine.
  10. That's what I understand it to be. One reason I'm doing my testing is that the MSP430FR5969 equivalent to EM3 (viz., LPM3.5) is actually showing up at 250nA for my test application though the data sheet says 400nA. So that 600nA from EFM32 may be high in practice (or the uCurrent may not be measuring things accurately). I expect EM4 to be equivalent to LPM4.5 on MSP430.
  11. 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.
  12. 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 t
  13. I think it'd depend on duty cycle and requirements, and how much effort gets put into the software design. My impression is MSP430 will be cheaper and EFM32 has more capability and is faster. The Wolverine (e.g. MSP430FR5969) has really low power, comparable to Zero Gecko; I'm seeing 250 nA for LPM3.5 with an EXP430FR5969 application that wakes periodically on RTC alarms. I expect to have numbers from an apples-to-apples comparison between the two in the next week or two.
  14. Not really. The concrete examples simply invoke one of those functions. My intent was just to make you aware of issues that might become important in the future; most people use timers without worrying about these cases. In your original example, the timer is synchronous with MCLK because you're using SMCLK as the source, so you don't have anything to worry about. If you were using an external high-speed clock, you would need to be careful.
  15. No; DATA is an array of uint32_t so the indexing operation multiplies by four.
  16. You've got things swapped around. The address bits specify which bits of the value on the RHS are to be stored. Writing 0xa5 to 0x4002.53fc would turn on bits 0, 3, 5, and 7, and turn off bits 1, 2, 4, and 6. Writing 0xff to 0x4002.5020 would set bit 3 (4U << 3) and not affect any other pins on the port. The way I do it is something like: GPIOF->DATA[1U << PIN] = -1; /* RHS could equivalently be (1U << PIN) since only PIN bit matters */ to turn on only PIN regardless of what value PIN is. In this case DATA is a 256-element uint32_t array that overlays the bi
  17. Yeah, msp430-elf-gcc didn't turn out the way I'd hoped it would when I endorsed that initiative. The compiler is actually pretty good; the problems with expectations and device support aren't Red Hat's fault. I'm really enjoying Cortex-M development, though again TI's software approach for Tiva comes up short relative to my quality expectations. Silicon Labs, though, is getting an A- for the EFM32 line. I mostly figured it was, but I'm finding I'm a bit sensitive since I did put a lot of effort into making sure the CRT stuff in particular (which is in assembly) was both space/t
  18. Yes, that's the best solution if you want to pretend the MCU doesn't have a watchdog timer. It'll only work on mspgcc (not msp430-elf-gcc), and you'll save a whole 18 bytes of code and 2 bytes of RAM. ("Bloat"?) Um, yes. de gustibus non est disputandum and all that.
  19. Nothing short of editing the linker script or providing an alternative definition will affect __watchdog_support. It belongs there. Do not mess with it. To use the built-in watchdog, simply don't add WDTCTL = WDTPW + WDTHOLD; anywhere. That turns the watchdog off. Instead, make sure you invoke __watchdog_clear() every 32ms. Use __set_watchdog_clear_value() to assign a new value (WDTPW + something) that configures the interval you want; even if you do, still invoke __watchdog_clear() at the required frequency. Consult the family user's guide for details on how to determine alterna
  20. BTW: The value in __watchdog_support() is not supposed to be WDTHOLD. If you choose to turn off the watchdog in main() (as your program does), that's fine, but the toolchain should not make that policy decision for you. Instead it preserves the power-up setting, and uses the value it saved on startup to ensure the watchdog does not fire during the startup code.
  21. All your questions relate to mspgcc's runtime support infrastructure and are independent of the program you've compiled. Because the value that needs to get written to the watchdog timer to reset it varies depending on MCU, and the expression computed by __watchdog_support reads the current setting then changes it to be a valid reset that preserves that setting. (Specifically, in some MCU families the bits that produce the power-up default timeout interval are different because of clock differences, so having a constant won't work across all platforms. I didn't want yet another chip-spec
  22. @@Rickta59 has a C++ wrapper that's discussed here. Cortex-M is a much more orthogonal architecture, even across vendors, so if I were to do a C++ peripheral abstraction approach I'd target it. My in-development Cortex-M work will support C++ but my initial attempts at abstraction suggest the language is not quite ready for how I want to use it (at a minimum C++14's extensions to constexpr will be necessary for high performance).
  23. If you look in driverlib/gpio.c GPIOPadConfigSet, you'll see the code setting DR2R, DR4R, DR8R as though these were additive, e.g. to get a 14 mA drive you'd set all three. Or as if it were necessary to explicitly clear the bits in undesired settings. No. Per the datasheet, setting a bit in any one of the three clears that bit in the other two. <x> Similarly, setting PUR clears the PDR bit, and vice-versa, so only one assignment is necessary to enable internal resistance. Two are necessary to clear both; ODR is not coupled to these capabilities. This makes much more sense,
  24. A subset of the lessons I learned today (references are to the TM4C123GH6PM data sheet): 5.2.6 "System Control" specifies a delay of 3 system clocks after a peripheral module clock is enabled in the SYSCTL->RCGCmodule register before the module registers are accessed. (A comment in driverlib/sysctl.c says five clock cycles.) Failure to satisfy this delay results in a HardFault. Unfortunately, gcc-arm doesn't have a __delay_cycles() function. Today was my day to discover commit control (10.2.4) and the need to unlock PC0-PC3, PD7, and PF0 before setting AFSEL or DEN if you actually want
  25. The command file would be something like link_msp430f5529.cmd; the name and location depends on your toolchain. I believe TI often puts them in the same directory holding the device header (msp430f5529.h). Alphabetic port names refer to the 16-bit port interface introduced (I believe) with CPUX MSP430s. PORTA holds PORT1 at even byte offsets and PORT2 at odd byte offsets, allowing simultaneous manipulation of PORT1 and PORT2 registers through the 16-bit PORTA register names. PAIFG_L at address 0x21C is the same as P1IFG, while PAIFG_H at address 0x21D is the same as P2IFG.
×
×
  • Create New...