Jump to content

tripwire

Members
  • Content Count

    193
  • Joined

  • Last visited

  • Days Won

    14

tripwire last won the day on May 2

tripwire had the most liked content!

About tripwire

  • Rank
    Level 2

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. tripwire

    Polling the reset button (S1) on MSP-EXP430G2

    Yes, that's the method described in the blog post I linked. I just posted this as an alternative because I've not seen it before. Indeed, I've seen it claimed that the interrupt handler is the only possible way to track the reset button state. You could do that if you have a spare GPIO and don't mind having a loose switch. Even then, it's only four lines of code to poll the reset button...
  2. I've been working on a project for MSP-EXP430G2 which requires two buttons and hit the problem that S1 is set up as a reset button. Unlike S2 it's not connected to a regular GPIO pin; instead it's connected to the nRST/NMI pin. I looked for information on using the reset button as a user input and found some examples, but they all used the NMI ISR to track rising and falling edges. For example, see this post from the 43oh blog: Using the MSP430G2xx1 nRST NMI Pin as an Input. I really wanted some way to sample the current state of the button directly, which is tricky because there's no PxIN equivalent for the NMI input. Here's a snippet demonstrating the method I ended up using: #include <msp430.h> int main(void) { WDTCTL = WDTPW | WDTHOLD; P1DIR = BIT0; P1OUT = 0; while(1) { // Poll S1 WDTCTL = WDTPW | WDTHOLD | WDTNMI; // Detect NMI rising edges IFG1 &= ~NMIIFG; // Clear latched value WDTCTL = WDTPW | WDTHOLD | WDTNMI | WDTNMIES; // Detect NMI falling edges unsigned char buttonPressed = (IFG1 & NMIIFG) ? 1 : 0; // Read latched value if(buttonPressed) { P1OUT |= BIT0; } else { P1OUT &= ~BIT0; } __delay_cycles(20000); } } The nice thing about this is that the polling code is self-contained and can be dropped in wherever you like. How it works The schematic for the reset/NMI pin in the G2 family looks like this: The output of a rising-edge detector is latched to give the value of NMIIFG. If the WDTNMIIES bit is set an inverter is switched in ahead of the edge detector so it detects falling edges instead. To poll the state of the nRST/NMI pin WDTNMIES is cleared, followed by NMIIFG. Next WDTNMIES is set high and finally NMIIFG is read. When read, the NMIIFG bit will be set if: S1 was pressed between when WDTNMIES went high and NMIIFG was read S1 was released between when NMIIFG was cleared and WDTNMIES went high (ie it was pressed but you just released it) The internal switch controlled by WDTNMIES is used to force an edge transition. This is what lets the edge detector output high even if the button was held down for a long time. Note that NMIIE is not set, so the NMI interrupt is never requested. Warnings These warnings apply to any use of the nRST/NMI pin for user input: S1 cannot be used while SBW debugging is active. You need to disable or "free run" the debugger so the two functions don't interfere with each other If S1 is held down and the MCU crashes or resets it will be held in reset until you release the button.
  3. Another thing that might make this code unreliable is that you aren't setting P1OUT bit 3 high. Setting a bit in PxREN connects the pull resistor to the corresponding pin, but the pull direction is given by the value of the relevant PxOUT bit. The value of PxOUT is unspecified on startup and power-on clear, so you might be getting a pulldown resistor instead of pullup.
  4. Hi, I'm hoping some of you might have had experience of waterproofing sensor nodes or individual sensors, and can make suggestions. I have a project using the SensorTag to measure altitude, and need to seal it up enough that it doesn't fail after the first rain shower. It doesn't need to be completely watertight as it should never be submerged, but it needs to resist heavy and persistent rain. It can't go in a hard-shelled airtight container as that would interfere with the pressure measurements. It would probably be a bad idea to get conformal coating in the sensor port too. I'm not too sure whether conformal coating would protect the coin cell and holder adequately either. To make it even more difficult I have a wire running to an external reed switch that counts wheel revolutions, so that entry point needs sealing too. My current "plan" is to mummify it in plumber's PTFE tape and hope for the best, unless there are any better ideas out there
  5. tripwire

    Bitshift problem

    This is down to the subtleties of integral promotions in C. The standard says this for the bitwise shift operators: "The integral promotions are performed on each of the operands. The type of the result is that of the promoted left operand. If the value of the right operand is negative or is greater than or equal to the width in bits of the promoted left operand, the behavior is undefined." Integral promotion can "widen" a type as far as unsigned int, which is 16 bits on MSP430. The RHS of the shift is 16, so that means undefined behaviour; in this case that seems to mean (100 << 16) == 100.
  6. tripwire

    Program won't fit weirdness

    Either way works (char const * const is equivalent to const char * const). That cdecl site only accepts the latter, however. The const after the * is the one that makes the pointers in the array const. You could get away with omitting the first const in this case, but I tend to just use both.
  7. tripwire

    Compiler optimization traps for the unaware

    If anything I'd have expected: 5, 4, 1, 3, 2, 0 (sorted by key rather than value or insertion order). That's what you'd get out of a std::map in C++. The C++ standard library designers originally avoided the issue of unspecified map iteration order by only permitting ordered maps, and hash-based maps were not officially included until C++11. In terms of performance, it looks like the randomisation in go is a random start offset rather than a complete shuffling of the iteration order. That's just enough to prevent anyone from relying on the order from one iteration to the next. They might also have some random input into the hash function which would jumble the ordering between program runs. Apparently that can also be implemented to defeat hash collision DoS attacks when user-provided values are used as map keys.
  8. tripwire

    RANT: Cloud of this, IoT of that . . .

    Agreed. That's why I'm not delighted by the prospect of IoT-mania encouraging a proliferation of cheap internet-connected devices.
  9. tripwire

    RANT: Cloud of this, IoT of that . . .

    Or the person making the IoT device *DOESN'T* (Yes, this has since been patched out)
  10. tripwire

    RANT: Cloud of this, IoT of that . . .

    That works against remote attacks, but the linux/BSD/non-windows server protecting the wireless device can be bypassed if you're in the vicinity. Then the unsecure wireless device can be exploited to leak your wireless key (for example). The scale of that approach is greatly limited by the need to be near the target, but it means you can't assume a secure router will protect you if the devices are unsecure.
  11. tripwire

    RANT: Cloud of this, IoT of that . . .

    So, yeah: "Designing an internet-facing server with security protection can be a very challenging task" is fair enough. It's not so much that the original title implies the world will end if you don't attend, more that it implies the content is somehow specific to IoT when it's not. What would be nice is if someone came up with a way to deal with the security holes left in the many internet "things" abandoned by their manufacturers without ongoing firmware updates...
  12. Good news! This issue is fixed in the TI Emulators 6.0.228.0 package, which contains the version 2.3.0.1 firmware for XDS110. TI have added support for 2-wire cJTAG debugging, which only uses the TMS and TCK lines. In the 2.3.0.1 firmware they also stopped the emulator from driving TDO, which was blocking access to the SPI. It looks like 2-wire cJTAG is the default mode now too, so debugging SPI flash code should just work like you'd expect.
  13. tripwire

    TI not supporting MSP-EXP430G2 on Mac or Linux?

    Except when the onboard USB hub goes out to lunch
  14. tripwire

    TI not supporting MSP-EXP430G2 on Mac or Linux?

    Strange. I wonder if it has anything to do with the fact that the G2 launchpad has a different emulator to all the others.
  15. tripwire

    Have feedback for TI? Please share here.

    This is one of my pet hates too. I find energy profiling to be an incredibly powerful debugging tool, it's like an ECG for your MCU! Unfortunately the UI in CCS has a lot of bugs and missing features that make it inconvenient to use and a lot less reliable than I'd like. I used to have a long list of requests for features that would make EnergyTrace more informative, now I just be happy with CSV export of the recorded data for offline analysis. This week I looked into using DSS scripting which does support CSV output, but the EnergyTrace DVT API is completely undocumented. I think my next step may be to forget about the EnergyTrace support in CCS and try this instead: http://forum.43oh.com/topic/9674-casio-watch-rebuild-w-msp430/#entry72969
×