Jump to content
43oh

tripwire

Members
  • Content Count

    193
  • Joined

  • Last visited

  • Days Won

    14

Reputation Activity

  1. Like
    tripwire got a reaction from MRose in Clock changing when in debug mode   
    Hmm, that was unexpected...
     
    I've modified the test code to just flash the green LED while the oscillator fault flag is set. The red LED now continues to flash at whatever rate is produced by the timer (even during a fault).
     
    crystal.c
     
    It would be good if you'd try the new code and see what happens. I'm hoping that the green LED will flash rapidly from the moment you run the code, and the red LED will flash every second (approx) with the debugger attached and slower after you terminate debugging.
     
    If you get the expected result then it suggests the crystal is in a rather sensitive state, almost running correctly with the debugger attached but occasionally failing to oscillate. Then when you detach the debugger the problem gets much worse.
     
    I'm wondering whether there might be a hardware problem that's making your crystal susceptible to interference. Just to check, did you solder the crystal's case down to the big pad on the board, or just the two legs?
     
    Assuming you did solder the case, there are a few other possibilities. Some people here have had crystal problems caused by the power supply to the launchpad (through USB). You could try using a different power source or a battery pack. Also the XIN/XOUT pins are connected through to the J2 header, which can pick up interference. The launchpad user guide suggests that you may need to remove resistors R28 and R29 from the board to disconnect the crystal from the header.
  2. Like
    tripwire got a reaction from MRose in Clock changing when in debug mode   
    During debugging the TST and RST lines of the MCU are used for JTAG communication. They happen to be near the XIN/XOUT pins for the crystal, so perhaps there could be some interference or a short there.
     
    Also, remember how the reset button doesn't work when running in the debugger? That's because the RST line is in use. You can get the debugger to temporarily detach from the target MCU by pausing execution, then selecting "Free Run" from the Run menu. After that the reset button will work normally. You should give that a try and see whether selecting Free Run and then pressing the reset button causes the clock slowdown at any point.
     
    I built that example program and gave it a go, by the way. Terminating the debug session had no effect on the flash rate on my launchpad.
     
    Looking at the example, it doesn't have any code to handle the oscillator fault flag. That won't stop it from working, but handling the fault flag properly might give you an indication of whether the crystal is failing to oscillate for some reason. I've taken the oscillator fault code from the launchpad workshop code and grafted it onto the example program:
     
    crystal.c
     
    The change makes the green LED light up whenever the oscillator is not running correctly. On my launchpad I get a momentary flash of the green LED when I start running the program, then the red LED starts to toggle once per second. Terminating the debug session doesn't cause the green LED to light up again. Resetting causes the green flash followed by red LED toggling once per second.
     
     
  3. Like
    tripwire reacted to oPossum in 2^N for real numbers using integer math   
    When working with electronic music (MIDI synth and such) it is sometimes necessary to adjust pitch by units of octaves, semitones, or cents.
     
    An octave is a 2:1 ratio. So the ratio between any number of octaves is 2^N. This is a simple bit shift. Easy.
     
    A semitone is 1/12 of an octave (typically), so the ratio for that is 2^(N/12). A cent is 1/1200 of an octave, so the ratio for that is 2^(N/1200). Can't use bit shifting for that!
     
    The C stdlib provides the pow() function that can be used for these calculations, but it uses rather slow floating point math.
     
    This code will do it with relatively fast fixed point integer math. This code could easily be adapted to almost any base and exponent by changing the look-up tables. It uses the property of exponents that 2 ^ (1 + 2 + 4 + 8) == (2 ^ 1) * (2 ^ 2) * (2 ^ 4) * (2 ^ 8)
     
     
    // // 2 ^ (n / (1200 * 8192)) // // n = 1 / 8,192 cent //   = 1 / 819,200 semitone //   = 1 / 9,830,400 octave // // range of n: -134,217,727 to +78,643,199 //            = -13.65 to +7.99 octaves // // returned value is 8.24 fixed point // // + exponents in 8.24 format static const uint32_t etp[27] = {     0x01000001,                     // 00000001  1.0000000705     0x01000002,                     // 00000002  1.0000001410     0x01000005,                     // 00000004  1.0000002820     0x01000009,                     // 00000008  1.0000005641     0x01000013,                     // 00000010  1.0000011282     0x01000026,                     // 00000020  1.0000022563     0x0100004C,                     // 00000040  1.0000045127     0x01000097,                     // 00000080  1.0000090254     0x0100012F,                     // 00000100  1.0000180509     0x0100025E,                     // 00000200  1.0000361021     0x010004BB,                     // 00000400  1.0000722054     0x01000977,                     // 00000800  1.0001444161     0x010012EE,                     // 00001000  1.0002888530     0x010025DE,                     // 00002000  1.0005777895     0x01004BC1,                     // 00004000  1.0011559129     0x01009798,                     // 00008000  1.0023131618     0x01012F8B,                     // 00010000  1.0046316744     0x0102607D,                     // 00020000  1.0092848012     0x0104C6A1,                     // 00040000  1.0186558100     0x0109A410,                     // 00080000  1.0376596592     0x0113A513,                     // 00100000  1.0767375682     0x0128CC11,                     // 00200000  1.1593637909     0x01581889,                     // 00400000  1.3441243996     0x01CE81F4,                     // 00800000  1.8066704016     0x0343994D,                     // 01000000  3.2640579400     0x0AA77169,                     // 02000000  10.6540742354     0x71826157                      // 04000000  113.5092978129 }; // - exponents in 8.24 format static const uint32_t etn[27] = {     0x00FFFFFF,                     // 00000001  0.9999999295     0x00FFFFFE,                     // 00000002  0.9999998590     0x00FFFFFB,                     // 00000004  0.9999997180     0x00FFFFF7,                     // 00000008  0.9999994359     0x00FFFFED,                     // 00000010  0.9999988718     0x00FFFFDA,                     // 00000020  0.9999977437     0x00FFFFB4,                     // 00000040  0.9999954873     0x00FFFF69,                     // 00000080  0.9999909747     0x00FFFED1,                     // 00000100  0.9999819495     0x00FFFDA2,                     // 00000200  0.9999638992     0x00FFFB45,                     // 00000400  0.9999277998     0x00FFF689,                     // 00000800  0.9998556048     0x00FFED13,                     // 00001000  0.9997112304     0x00FFDA28,                     // 00002000  0.9994225441     0x00FFB455,                     // 00004000  0.9988454217     0x00FF68C1,                     // 00008000  0.9976921765     0x00FED1DC,                     // 00010000  0.9953896791     0x00FDA51C,                     // 00020000  0.9908006133     0x00FB4FC4,                     // 00040000  0.9816858552     0x00F6B582,                     // 00080000  0.9637071184     0x00EDC157,                     // 00100000  0.9287314100     0x00DCCF8E,                     // 00200000  0.8625420320     0x00BE7564,                     // 00400000  0.7439787570     0x008DB277,                     // 00800000  0.5535043908     0x004E6E13,                     // 01000000  0.3063671106     0x00180743,                     // 02000000  0.0938608065     0x0002415D                      // 04000000  0.0088098510 }; uint32_t tpow(int32_t n) {     const uint32_t *et = etp;           // Assume + exponent     if(n < 0) n = -n, et = etn;         // Adjust for - exponent                                         //     uint32_t r = 1L << 24;              // Init result to 1.0 in 8.24 format                                         //     do {                                //         if(n & 1) r = mul824(r, *et);   // Multiply by exponent if lsb of n is 1         ++et;                           // Next exponent     } while(n >>= 1);                   // Next bit, loop until no more 1 bits                                         //     return r;                           // Return result }
  4. Like
    tripwire reacted to cde in SMD leadless soldering with a Butane Torch   
    The Locking headers have every other pin hole offset by a small amount up or down. So it is a bit zig zagged on the board.
     
    You could (kinda) see them on the middle five boards I had made (click to enlarge). See how every other pin in the header is sitting on the silkscreen?
     
     
     
    Well, it provides just enough of a offset that it holds the header in place with friction. The regular header, like I used on the bottom left board, has all the holes equal, so the header falls out unless you hold it.
     
    Here's where I first found out about these, with better pictures: http://www.sparkfun.com/tutorials/114
  5. Like
    tripwire reacted to grodius in F35B JSF Software   
    Tonight on Australian TV there was an investigation into the beleaguered X35/F35B Fighter plane and I couldn't believe my ears at the words of one of the most senior US military officials involved.  The context was such that it wasn't simply an error of detail.  It shows he really has no idea about software development at all.  Whatsoever.
     
    The following is from the formal released transcript:
     
    "LT. GENERAL CHRIS BOGDAN: This is a very software-intensive airplane. There's over 10,000 lines of software code just on the airplane itself and there's another 10 million lines of code for all the off-board systems, the maintenance systems and the mission planning systems that go with it." (By off-board he was talking ground component.)
     
    I have a non-embedded banking software background, but that number is so wide of the mark for one of the most software dependent planes in existence that I laughed out loud.  This is circa a half trillion dollar project and the top military official directly involved doesn't understand software development at all.  I would be disappointed if a sidewinder missile didn't have 10,000 lines of code, let alone a new plane to be finally released 2018 ish.
     
    Some versions of the plane are capable of VTOL, thrust vectoring, entirely computerized console with what appears to be touch screen interface.
     
    PS The Stellaris Launchpad has 256kb flash so shelve those non ambitious, non Jet Fighter projects now. 
     
    Dennis Nedry from Jurassic Park:
     
    "Do you know anyone who can network 8 connection machines and debug 2 million lines of code for what I bid for this job?"
     
  6. Like
    tripwire reacted to yyrkoon in Best information for those new to the MSP430?   
    *puts on web-safe condom*
     
    Seriously though, as software developers of sorts, you would think that "we" could appreciate / and respect copyright laws.
     
    Where I am concerned, GeekDoc, you're preaching to the choir   However, again, I have no qualms checking content out before I spend my own hard earned cash on something. Otherwise, it is me that is being ripped off, and in the end. I may be able to sympathize with someone over their problems, but their problems are not mine. If you catch my meaning.
     
    That said, in this situation I feel that the author( Elecia White ) deserves every dime she can get from that book.
     
    EDIT: 
     
    And apparently based on my link there O'Reilly has made the complete book available for viewing though google books. 
  7. Like
    tripwire reacted to JWoodrell in Using Stop mask for hires graphics   
    In the most recent board for the snes usb board (internal to controller board) and i changed my little logo around to use the stopmask for the guy so he stands out from the spiral better. Ill post a better closeup to see the difference better

    And its surprising how much higher resolution the stopmask is than the silkscreening. So if you need small hires images, use the stomask

    This brings up an interesting option though for 5 color images.

    1-stop mask w/ ground plane = light stopmask color
    2-stop madk w/o ground plane = dark stopmask color
    3-no stopmask w/ ground plane = silver or gold (if ENIG)
    4-no stopmask w/o ground plane = tan raw board color
    5-silkscreen (usually white, but low res)
     
    [edit] new picture, I appologize for the fisheye, but im at the limit of close in focusing on my camera


  8. Like
    tripwire got a reaction from stirlingboy in Embedding breakpoints in C code   
    Hi,
     
    Since I started programming for MSP430 I've been looking for the MSP equivalent of "__asm int 3" (aka DebugBreak). I've come up with this fragment, tested on CCS 5.3.0:
    #ifndef NDEBUG // If debugger is attached and software breakpoints are enabled, DEBUG_BREAK will pause execution #define DEBUG_BREAK _op_code(0x4343) #else // Strip out DEBUG_BREAKs in final/release builds #define DEBUG_BREAK #endif  
    Put this in a header file and you can then embed breakpoints in your code with a DEBUG_BREAK; statement. To reiterate what it says in the comment above: DEBUG_BREAK only halts if the debugger is attached and software breakpoints are enabled!
     
     
    For an example of where it's useful, consider the DCO calibration constants check used in a lot of example programs:
    if(CALBC1_1MHZ == 0xFF || CALDCO_1MHZ == 0xFF) // Check calibration constants weren't erased { DEBUG_BREAK; // Halt program (if debugger is connected) while(1); // Loop forever (as a backup) to prevent use of erased calibration data }  
    As it normally appears (without the DEBUG_BREAK) the CPU just enters an infinite loop if the calibration data is missing. You have to notice that the program isn't progressing and manually pause to see what the problem is. With the addition of a DEBUG_BREAK the program pauses immediately so you can see what went wrong!
     
    They're handy for use in trap ISRs, to pause when an unexpected interrupt fires so you can find out what caused it. In that case you may want to leave out the infinite loop so the program can be resumed afterwards. They're useful for general debugging too, since embedding breakpoints like this has some advantages over breakpoints set in the debugger. More on that later...
     
     
    To understand how it works you need to know some details about how hardware and software breakpoints work. Time for a crash-course in breakpoints
     
    Placing a hardware breakpoint tells the MSP's Embedded Emulation Module (EEM) to halt the CPU whenever an instruction is fetched from the breakpoint's address. The EEM contains trigger modules that spy on the address and data buses inside the chip, and fire when they see a specified value. Once the trigger is set up the MSP runs code as normal until the trigger fires, which makes the EEM halt the CPU and stop all the clocks. This is great because it means hardware breakpoints don't mess up the internal state of the MSP. Unfortunately the EEM has a limited number of triggers (just 2 on the value-line chips), so you can only have two breakpoints!
     
    Software breakpoints work around that limitation by using one of the EEM triggers in a different way. Instead of halting when an instruction is fetched from a specific address, it halts when a specific instruction is fetched from any address. That means you can have as many breakpoints as you like, as long as they're all on the same instruction opcode. The debugger uses 0x4343 (a type of NOP) as its breakpoint opcode. When you place a software breakpoint the debugger first makes a record of the original opcode at that address. Then it overwrites it with 0x4343 in the MSP's flash memory. As before, the MSP runs code as normal until the trigger module detects an instruction fetch of the 0x4343 opcode. The EEM halts the CPU and stops the clocks. Now the debugger has to restore the opcode that it overwrote earlier and make sure it's the next instruction to execute. After you step or resume it needs to put the breakpoint opcode back again, assuming you didn't disable it in the meantime.
     
    All this writing to flash has an overhead, and the bad news is that the clocks need to be restarted during the process. That means that setting and hitting software breakpoints can make the on-chip timer peripherals go haywire.
     
    DEBUG_BREAK makes use of the debugger's trigger setup for software breakpoints, but it doesn't require any runtime flash memory overwrites. The breakpoint is entirely handled by the MSP's EEM like a hardware breakpoint, but you can have as many as you like. The only disadvantage is that you need to rebuild to move them ;-)
  9. Like
    tripwire reacted to GG430 in Boggle Timer with 8 pin MSP430G2230   
    We love to play the game Boggle. It's an analog game ;-)
    It uses a 3 minute sandglass to keep time for one play. Unfortunately one day the sandglass was gone. So I needed a fast solution and made a Dremel-milled PCB to hold the 8 pin MSP430G2230.
    I added a red/green LED, a small speaker and a coin cell battery. The MSP430 is always in LPM4 until the small metal-ball triggers the start by shaking the entire casing. It's just to metal contacts which get shorted.
    Than the green LED keeps flashing for 3 minutes. Once these are over the red LED flashes and a beep sound can be heard.
    It was a rainy afternoon job to build this and we were back in the game for boggling pretty quick.
    Needless to say that we found the original sandglass a couple month later in our daughter's room...
    However we'll stick with the digital solution for the analog game
     

     

  10. Like
    tripwire got a reaction from jsolarski in Embedding breakpoints in C code   
    Hi,
     
    Since I started programming for MSP430 I've been looking for the MSP equivalent of "__asm int 3" (aka DebugBreak). I've come up with this fragment, tested on CCS 5.3.0:
    #ifndef NDEBUG // If debugger is attached and software breakpoints are enabled, DEBUG_BREAK will pause execution #define DEBUG_BREAK _op_code(0x4343) #else // Strip out DEBUG_BREAKs in final/release builds #define DEBUG_BREAK #endif  
    Put this in a header file and you can then embed breakpoints in your code with a DEBUG_BREAK; statement. To reiterate what it says in the comment above: DEBUG_BREAK only halts if the debugger is attached and software breakpoints are enabled!
     
     
    For an example of where it's useful, consider the DCO calibration constants check used in a lot of example programs:
    if(CALBC1_1MHZ == 0xFF || CALDCO_1MHZ == 0xFF) // Check calibration constants weren't erased { DEBUG_BREAK; // Halt program (if debugger is connected) while(1); // Loop forever (as a backup) to prevent use of erased calibration data }  
    As it normally appears (without the DEBUG_BREAK) the CPU just enters an infinite loop if the calibration data is missing. You have to notice that the program isn't progressing and manually pause to see what the problem is. With the addition of a DEBUG_BREAK the program pauses immediately so you can see what went wrong!
     
    They're handy for use in trap ISRs, to pause when an unexpected interrupt fires so you can find out what caused it. In that case you may want to leave out the infinite loop so the program can be resumed afterwards. They're useful for general debugging too, since embedding breakpoints like this has some advantages over breakpoints set in the debugger. More on that later...
     
     
    To understand how it works you need to know some details about how hardware and software breakpoints work. Time for a crash-course in breakpoints
     
    Placing a hardware breakpoint tells the MSP's Embedded Emulation Module (EEM) to halt the CPU whenever an instruction is fetched from the breakpoint's address. The EEM contains trigger modules that spy on the address and data buses inside the chip, and fire when they see a specified value. Once the trigger is set up the MSP runs code as normal until the trigger fires, which makes the EEM halt the CPU and stop all the clocks. This is great because it means hardware breakpoints don't mess up the internal state of the MSP. Unfortunately the EEM has a limited number of triggers (just 2 on the value-line chips), so you can only have two breakpoints!
     
    Software breakpoints work around that limitation by using one of the EEM triggers in a different way. Instead of halting when an instruction is fetched from a specific address, it halts when a specific instruction is fetched from any address. That means you can have as many breakpoints as you like, as long as they're all on the same instruction opcode. The debugger uses 0x4343 (a type of NOP) as its breakpoint opcode. When you place a software breakpoint the debugger first makes a record of the original opcode at that address. Then it overwrites it with 0x4343 in the MSP's flash memory. As before, the MSP runs code as normal until the trigger module detects an instruction fetch of the 0x4343 opcode. The EEM halts the CPU and stops the clocks. Now the debugger has to restore the opcode that it overwrote earlier and make sure it's the next instruction to execute. After you step or resume it needs to put the breakpoint opcode back again, assuming you didn't disable it in the meantime.
     
    All this writing to flash has an overhead, and the bad news is that the clocks need to be restarted during the process. That means that setting and hitting software breakpoints can make the on-chip timer peripherals go haywire.
     
    DEBUG_BREAK makes use of the debugger's trigger setup for software breakpoints, but it doesn't require any runtime flash memory overwrites. The breakpoint is entirely handled by the MSP's EEM like a hardware breakpoint, but you can have as many as you like. The only disadvantage is that you need to rebuild to move them ;-)
  11. Like
    tripwire got a reaction from Automate in Embedding breakpoints in C code   
    Hi,
     
    Since I started programming for MSP430 I've been looking for the MSP equivalent of "__asm int 3" (aka DebugBreak). I've come up with this fragment, tested on CCS 5.3.0:
    #ifndef NDEBUG // If debugger is attached and software breakpoints are enabled, DEBUG_BREAK will pause execution #define DEBUG_BREAK _op_code(0x4343) #else // Strip out DEBUG_BREAKs in final/release builds #define DEBUG_BREAK #endif  
    Put this in a header file and you can then embed breakpoints in your code with a DEBUG_BREAK; statement. To reiterate what it says in the comment above: DEBUG_BREAK only halts if the debugger is attached and software breakpoints are enabled!
     
     
    For an example of where it's useful, consider the DCO calibration constants check used in a lot of example programs:
    if(CALBC1_1MHZ == 0xFF || CALDCO_1MHZ == 0xFF) // Check calibration constants weren't erased { DEBUG_BREAK; // Halt program (if debugger is connected) while(1); // Loop forever (as a backup) to prevent use of erased calibration data }  
    As it normally appears (without the DEBUG_BREAK) the CPU just enters an infinite loop if the calibration data is missing. You have to notice that the program isn't progressing and manually pause to see what the problem is. With the addition of a DEBUG_BREAK the program pauses immediately so you can see what went wrong!
     
    They're handy for use in trap ISRs, to pause when an unexpected interrupt fires so you can find out what caused it. In that case you may want to leave out the infinite loop so the program can be resumed afterwards. They're useful for general debugging too, since embedding breakpoints like this has some advantages over breakpoints set in the debugger. More on that later...
     
     
    To understand how it works you need to know some details about how hardware and software breakpoints work. Time for a crash-course in breakpoints
     
    Placing a hardware breakpoint tells the MSP's Embedded Emulation Module (EEM) to halt the CPU whenever an instruction is fetched from the breakpoint's address. The EEM contains trigger modules that spy on the address and data buses inside the chip, and fire when they see a specified value. Once the trigger is set up the MSP runs code as normal until the trigger fires, which makes the EEM halt the CPU and stop all the clocks. This is great because it means hardware breakpoints don't mess up the internal state of the MSP. Unfortunately the EEM has a limited number of triggers (just 2 on the value-line chips), so you can only have two breakpoints!
     
    Software breakpoints work around that limitation by using one of the EEM triggers in a different way. Instead of halting when an instruction is fetched from a specific address, it halts when a specific instruction is fetched from any address. That means you can have as many breakpoints as you like, as long as they're all on the same instruction opcode. The debugger uses 0x4343 (a type of NOP) as its breakpoint opcode. When you place a software breakpoint the debugger first makes a record of the original opcode at that address. Then it overwrites it with 0x4343 in the MSP's flash memory. As before, the MSP runs code as normal until the trigger module detects an instruction fetch of the 0x4343 opcode. The EEM halts the CPU and stops the clocks. Now the debugger has to restore the opcode that it overwrote earlier and make sure it's the next instruction to execute. After you step or resume it needs to put the breakpoint opcode back again, assuming you didn't disable it in the meantime.
     
    All this writing to flash has an overhead, and the bad news is that the clocks need to be restarted during the process. That means that setting and hitting software breakpoints can make the on-chip timer peripherals go haywire.
     
    DEBUG_BREAK makes use of the debugger's trigger setup for software breakpoints, but it doesn't require any runtime flash memory overwrites. The breakpoint is entirely handled by the MSP's EEM like a hardware breakpoint, but you can have as many as you like. The only disadvantage is that you need to rebuild to move them ;-)
  12. Like
    tripwire got a reaction from roadrunner84 in Embedding breakpoints in C code   
    Hi,
     
    Since I started programming for MSP430 I've been looking for the MSP equivalent of "__asm int 3" (aka DebugBreak). I've come up with this fragment, tested on CCS 5.3.0:
    #ifndef NDEBUG // If debugger is attached and software breakpoints are enabled, DEBUG_BREAK will pause execution #define DEBUG_BREAK _op_code(0x4343) #else // Strip out DEBUG_BREAKs in final/release builds #define DEBUG_BREAK #endif  
    Put this in a header file and you can then embed breakpoints in your code with a DEBUG_BREAK; statement. To reiterate what it says in the comment above: DEBUG_BREAK only halts if the debugger is attached and software breakpoints are enabled!
     
     
    For an example of where it's useful, consider the DCO calibration constants check used in a lot of example programs:
    if(CALBC1_1MHZ == 0xFF || CALDCO_1MHZ == 0xFF) // Check calibration constants weren't erased { DEBUG_BREAK; // Halt program (if debugger is connected) while(1); // Loop forever (as a backup) to prevent use of erased calibration data }  
    As it normally appears (without the DEBUG_BREAK) the CPU just enters an infinite loop if the calibration data is missing. You have to notice that the program isn't progressing and manually pause to see what the problem is. With the addition of a DEBUG_BREAK the program pauses immediately so you can see what went wrong!
     
    They're handy for use in trap ISRs, to pause when an unexpected interrupt fires so you can find out what caused it. In that case you may want to leave out the infinite loop so the program can be resumed afterwards. They're useful for general debugging too, since embedding breakpoints like this has some advantages over breakpoints set in the debugger. More on that later...
     
     
    To understand how it works you need to know some details about how hardware and software breakpoints work. Time for a crash-course in breakpoints
     
    Placing a hardware breakpoint tells the MSP's Embedded Emulation Module (EEM) to halt the CPU whenever an instruction is fetched from the breakpoint's address. The EEM contains trigger modules that spy on the address and data buses inside the chip, and fire when they see a specified value. Once the trigger is set up the MSP runs code as normal until the trigger fires, which makes the EEM halt the CPU and stop all the clocks. This is great because it means hardware breakpoints don't mess up the internal state of the MSP. Unfortunately the EEM has a limited number of triggers (just 2 on the value-line chips), so you can only have two breakpoints!
     
    Software breakpoints work around that limitation by using one of the EEM triggers in a different way. Instead of halting when an instruction is fetched from a specific address, it halts when a specific instruction is fetched from any address. That means you can have as many breakpoints as you like, as long as they're all on the same instruction opcode. The debugger uses 0x4343 (a type of NOP) as its breakpoint opcode. When you place a software breakpoint the debugger first makes a record of the original opcode at that address. Then it overwrites it with 0x4343 in the MSP's flash memory. As before, the MSP runs code as normal until the trigger module detects an instruction fetch of the 0x4343 opcode. The EEM halts the CPU and stops the clocks. Now the debugger has to restore the opcode that it overwrote earlier and make sure it's the next instruction to execute. After you step or resume it needs to put the breakpoint opcode back again, assuming you didn't disable it in the meantime.
     
    All this writing to flash has an overhead, and the bad news is that the clocks need to be restarted during the process. That means that setting and hitting software breakpoints can make the on-chip timer peripherals go haywire.
     
    DEBUG_BREAK makes use of the debugger's trigger setup for software breakpoints, but it doesn't require any runtime flash memory overwrites. The breakpoint is entirely handled by the MSP's EEM like a hardware breakpoint, but you can have as many as you like. The only disadvantage is that you need to rebuild to move them ;-)
  13. Like
    tripwire got a reaction from Rickta59 in Embedding breakpoints in C code   
    Hi,
     
    Since I started programming for MSP430 I've been looking for the MSP equivalent of "__asm int 3" (aka DebugBreak). I've come up with this fragment, tested on CCS 5.3.0:
    #ifndef NDEBUG // If debugger is attached and software breakpoints are enabled, DEBUG_BREAK will pause execution #define DEBUG_BREAK _op_code(0x4343) #else // Strip out DEBUG_BREAKs in final/release builds #define DEBUG_BREAK #endif  
    Put this in a header file and you can then embed breakpoints in your code with a DEBUG_BREAK; statement. To reiterate what it says in the comment above: DEBUG_BREAK only halts if the debugger is attached and software breakpoints are enabled!
     
     
    For an example of where it's useful, consider the DCO calibration constants check used in a lot of example programs:
    if(CALBC1_1MHZ == 0xFF || CALDCO_1MHZ == 0xFF) // Check calibration constants weren't erased { DEBUG_BREAK; // Halt program (if debugger is connected) while(1); // Loop forever (as a backup) to prevent use of erased calibration data }  
    As it normally appears (without the DEBUG_BREAK) the CPU just enters an infinite loop if the calibration data is missing. You have to notice that the program isn't progressing and manually pause to see what the problem is. With the addition of a DEBUG_BREAK the program pauses immediately so you can see what went wrong!
     
    They're handy for use in trap ISRs, to pause when an unexpected interrupt fires so you can find out what caused it. In that case you may want to leave out the infinite loop so the program can be resumed afterwards. They're useful for general debugging too, since embedding breakpoints like this has some advantages over breakpoints set in the debugger. More on that later...
     
     
    To understand how it works you need to know some details about how hardware and software breakpoints work. Time for a crash-course in breakpoints
     
    Placing a hardware breakpoint tells the MSP's Embedded Emulation Module (EEM) to halt the CPU whenever an instruction is fetched from the breakpoint's address. The EEM contains trigger modules that spy on the address and data buses inside the chip, and fire when they see a specified value. Once the trigger is set up the MSP runs code as normal until the trigger fires, which makes the EEM halt the CPU and stop all the clocks. This is great because it means hardware breakpoints don't mess up the internal state of the MSP. Unfortunately the EEM has a limited number of triggers (just 2 on the value-line chips), so you can only have two breakpoints!
     
    Software breakpoints work around that limitation by using one of the EEM triggers in a different way. Instead of halting when an instruction is fetched from a specific address, it halts when a specific instruction is fetched from any address. That means you can have as many breakpoints as you like, as long as they're all on the same instruction opcode. The debugger uses 0x4343 (a type of NOP) as its breakpoint opcode. When you place a software breakpoint the debugger first makes a record of the original opcode at that address. Then it overwrites it with 0x4343 in the MSP's flash memory. As before, the MSP runs code as normal until the trigger module detects an instruction fetch of the 0x4343 opcode. The EEM halts the CPU and stops the clocks. Now the debugger has to restore the opcode that it overwrote earlier and make sure it's the next instruction to execute. After you step or resume it needs to put the breakpoint opcode back again, assuming you didn't disable it in the meantime.
     
    All this writing to flash has an overhead, and the bad news is that the clocks need to be restarted during the process. That means that setting and hitting software breakpoints can make the on-chip timer peripherals go haywire.
     
    DEBUG_BREAK makes use of the debugger's trigger setup for software breakpoints, but it doesn't require any runtime flash memory overwrites. The breakpoint is entirely handled by the MSP's EEM like a hardware breakpoint, but you can have as many as you like. The only disadvantage is that you need to rebuild to move them ;-)
  14. Like
    tripwire got a reaction from gwdeveloper in Embedding breakpoints in C code   
    Hi,
     
    Since I started programming for MSP430 I've been looking for the MSP equivalent of "__asm int 3" (aka DebugBreak). I've come up with this fragment, tested on CCS 5.3.0:
    #ifndef NDEBUG // If debugger is attached and software breakpoints are enabled, DEBUG_BREAK will pause execution #define DEBUG_BREAK _op_code(0x4343) #else // Strip out DEBUG_BREAKs in final/release builds #define DEBUG_BREAK #endif  
    Put this in a header file and you can then embed breakpoints in your code with a DEBUG_BREAK; statement. To reiterate what it says in the comment above: DEBUG_BREAK only halts if the debugger is attached and software breakpoints are enabled!
     
     
    For an example of where it's useful, consider the DCO calibration constants check used in a lot of example programs:
    if(CALBC1_1MHZ == 0xFF || CALDCO_1MHZ == 0xFF) // Check calibration constants weren't erased { DEBUG_BREAK; // Halt program (if debugger is connected) while(1); // Loop forever (as a backup) to prevent use of erased calibration data }  
    As it normally appears (without the DEBUG_BREAK) the CPU just enters an infinite loop if the calibration data is missing. You have to notice that the program isn't progressing and manually pause to see what the problem is. With the addition of a DEBUG_BREAK the program pauses immediately so you can see what went wrong!
     
    They're handy for use in trap ISRs, to pause when an unexpected interrupt fires so you can find out what caused it. In that case you may want to leave out the infinite loop so the program can be resumed afterwards. They're useful for general debugging too, since embedding breakpoints like this has some advantages over breakpoints set in the debugger. More on that later...
     
     
    To understand how it works you need to know some details about how hardware and software breakpoints work. Time for a crash-course in breakpoints
     
    Placing a hardware breakpoint tells the MSP's Embedded Emulation Module (EEM) to halt the CPU whenever an instruction is fetched from the breakpoint's address. The EEM contains trigger modules that spy on the address and data buses inside the chip, and fire when they see a specified value. Once the trigger is set up the MSP runs code as normal until the trigger fires, which makes the EEM halt the CPU and stop all the clocks. This is great because it means hardware breakpoints don't mess up the internal state of the MSP. Unfortunately the EEM has a limited number of triggers (just 2 on the value-line chips), so you can only have two breakpoints!
     
    Software breakpoints work around that limitation by using one of the EEM triggers in a different way. Instead of halting when an instruction is fetched from a specific address, it halts when a specific instruction is fetched from any address. That means you can have as many breakpoints as you like, as long as they're all on the same instruction opcode. The debugger uses 0x4343 (a type of NOP) as its breakpoint opcode. When you place a software breakpoint the debugger first makes a record of the original opcode at that address. Then it overwrites it with 0x4343 in the MSP's flash memory. As before, the MSP runs code as normal until the trigger module detects an instruction fetch of the 0x4343 opcode. The EEM halts the CPU and stops the clocks. Now the debugger has to restore the opcode that it overwrote earlier and make sure it's the next instruction to execute. After you step or resume it needs to put the breakpoint opcode back again, assuming you didn't disable it in the meantime.
     
    All this writing to flash has an overhead, and the bad news is that the clocks need to be restarted during the process. That means that setting and hitting software breakpoints can make the on-chip timer peripherals go haywire.
     
    DEBUG_BREAK makes use of the debugger's trigger setup for software breakpoints, but it doesn't require any runtime flash memory overwrites. The breakpoint is entirely handled by the MSP's EEM like a hardware breakpoint, but you can have as many as you like. The only disadvantage is that you need to rebuild to move them ;-)
  15. Like
    tripwire reacted to GG430 in Sundial - Kids Clock with LEDs   
    Thanks! I'd be curious on the other project, do you have a link to the project on Adafruit?
     
    Today we figured out that 7am is too late for the sun. My daughter was sitting in bed at 6:30 and waiting for the sun. Actually the 7am was an agreement to work for all days. Now I have to split it up to working days and weekend, means I have to add a weekday counter too.
    I think I'm going to shift it at least to 7:30 for the weekends ;-)
  16. Like
    tripwire reacted to zeke in Howto: Launchpad as External Programmer   
    Hi Guys,
     
    I just fought my way through the process of getting a Launchpad to operate as a standalone programmer on a virgin windows machine. I didn't want to install CCS5.1 to get this to work. I want the bare minimum install footprint because this is going on a production line computer.
     
    Follow this process and it should work for you too.
     
    1. Install the FET430UIF Low-Level USB VCP Drivers.
    2. Plug in the Launcpad to the PC and let the PC assign the drivers to the Launchpad.
    3. Open up a command console and enter the command "devmgmt.msc".
    4. Verify the "MSP430 Application UART" is present under Ports (Com & LPT).
    5. Download and Install the FET Pro430 Lite from Elpotronics.
    6. Open up FETPro430 and click on Setup->Connection/DeviceReset.
    7. Verify that the COM Port is USB (Automatic)
    8. Open code file and select your TI .out or Intel .hex file.
    9. Select the Microcontroller group and target ie: MSP430G2xx, MSP430G2553
    10. Connect GND, TEST and RESET (at minimum) to your target board. Make sure there's power applied to your circuit in this case.
    11. Click on AUTO PROG. and watch your target get programmed.
     
    This should work on your windows PC that does has never had CCS installed on it. And you won't have to resort to installing it either.
     
    Also, this should work with any version of Launchpad.
  17. Like
    tripwire reacted to bluehash in "LaunchPad- Why Male Headers?" - video moved   
    Link fixed. Thanks.
  18. Like
    tripwire got a reaction from igor in CCS custom project template (cycle count listing)   
    Hi,
     
    Although I don't program 430's in assembly (yet ;-)) I was particularly interested in this post about naken430asm in the tips section. Naken430util's disassembly listing with per-instruction cycle counts looked like a useful optimisation tool, and a good way to keep tabs on the compiler. I tried it out and liked it so much that I wanted to integrate it into my future CCS projects as standard.
     
    After poking around in the CCS install folder and reading TI's instructions I managed to make a plugin that adds a new project template. It's based on the standard "Empty project with main.c" template, but adds a post build step that generates a .hex file and naken430util cycle listing.
     
    To set up the plugin:
    1) Download naken430asm and install wherever you like
    2) Download ProjectTemplate.zip
    3) Copy the com.ti.ccstudio.custom.project.templates_1.0.3.201302072330 folder from the .zip into the ccsv5\eclipse\plugins folder of your CCS install
    4) Run CCS. You need to be signed in to a user account that can write to the CCS install folder! (CCS writes there when it finds a new plugin)
    5) Select the Window>Preferences menu option and navigate to C++>Build>Build Variables in the Preferences window
    6) Add a new build variable called CG_TOOL_NKA_UTIL, select "File" type and enter the path to naken430util.exe
     
    Once you've done all that you should have a new template in the "Empty Projects" template group when you try to make a new CCS project. Projects based on this template will save <ProjectName>.hex and <ProjectName>_cyc.txt to the output folder after every build.
     
    Hope that's of use/interest to someone!
  19. Like
    tripwire got a reaction from oPossum in CCS custom project template (cycle count listing)   
    Hi,
     
    Although I don't program 430's in assembly (yet ;-)) I was particularly interested in this post about naken430asm in the tips section. Naken430util's disassembly listing with per-instruction cycle counts looked like a useful optimisation tool, and a good way to keep tabs on the compiler. I tried it out and liked it so much that I wanted to integrate it into my future CCS projects as standard.
     
    After poking around in the CCS install folder and reading TI's instructions I managed to make a plugin that adds a new project template. It's based on the standard "Empty project with main.c" template, but adds a post build step that generates a .hex file and naken430util cycle listing.
     
    To set up the plugin:
    1) Download naken430asm and install wherever you like
    2) Download ProjectTemplate.zip
    3) Copy the com.ti.ccstudio.custom.project.templates_1.0.3.201302072330 folder from the .zip into the ccsv5\eclipse\plugins folder of your CCS install
    4) Run CCS. You need to be signed in to a user account that can write to the CCS install folder! (CCS writes there when it finds a new plugin)
    5) Select the Window>Preferences menu option and navigate to C++>Build>Build Variables in the Preferences window
    6) Add a new build variable called CG_TOOL_NKA_UTIL, select "File" type and enter the path to naken430util.exe
     
    Once you've done all that you should have a new template in the "Empty Projects" template group when you try to make a new CCS project. Projects based on this template will save <ProjectName>.hex and <ProjectName>_cyc.txt to the output folder after every build.
     
    Hope that's of use/interest to someone!
  20. Like
    tripwire reacted to abecedarian in [ ENDED ] Nov-Dec 2012 - 43oh Project of the Month Contest   
    I'll offer up (mostly) the same thing I did on stellarisiti.com:
     
    1) I will contribute $10 US to the prize, be it a gift certificate to whichever online source or cash prize, at a minimum, assuming the winner uses an MSP430 Launchpad.
    ... OR ...
    2) I will contribute $20 US to the prize, if the project also includes a C2000, Stellaris Launchpad or a 2nd MSP430.
    ... OR ...
    3) I will contribute $40 US to the prize, if the project includes an MSP430 Launchpad and at least two of the following: MSP430, C2000 or Stellaris processor.
     
    The criteria are mutually exclusive- if the winner meets the criteria for [3], the winner can't claim [2] and [1], for example.
     
     
    I will entertain, pending community opinion of course, the idea of "runner ups", provided those meet certain other standards. A runner up cannot get a prize above the winner: for instance if the winner doesn't meet the [3] criteria, neither can the runner up, right? Therefore the runner up(s) would win the prize(s) below the winner... catch my drift? Anyone could hook up a few MCU's and make some lights blink, but it's more about doing the most with the hardware and software than just hooking things up and making lights blink.
     
    I will stipulate that if you enter the same project here, on 43oh.com as well on stellarisiti.com, you cannot claim a prize from both, should you win.
     
     
    (My wife is going to hate me for doing this... :grin:)
  21. Like
    tripwire reacted to pabigot in MSPGCC and C++?   
    No qualms with anything Rick said; he qualifies as an expert.
     
    Folks interested in using C++ on embedded platforms might find the Joint Strike Fighter Air Vehicle Coding Standards of interest. Stroustrup was involved in this thing; a talk he and Herb Sutter gave at Software Development East a few years ago convinced me that C++ is a great way to get compact and efficient code on embedded platforms, especially using templates.
     
    All that depends on the compiler being solid, though. I've found nine reportable bugs in binutils in the last three days, just from doing a code walkthrough. I fully expect to discover the same sort of issues if/when I ever look carefully at how C++ is operating.
  22. Like
    tripwire reacted to Rickta59 in MSPGCC and C++?   
    I'm using c++ code with msp430-gcc with great results. I'm getting small code with readable syntax. My msp430-gcc was built with C++ support using gordon's fetcher/builder script. To compile c++ code I just use:
     

    msp430-gcc -Os -g -mmcu=msp430g2553 -o test.elf test.cpp
     
    There are some C++ things you probably want to avoid:
     
    1.) libc++ - dynamic memory on micros is a recipe for disaster. Avoid new and delete unless used with placement new.
    2.) new and delete ( reason already stated above )
    3,) exceptions and rtti - you don't want the overhead associated with these features. Turn them off with -fno-exceptions and -fno-rtti
    4.) virtual functions - extra pointers just make slower code. look into using templates
    5.) STL - relies on dynamic memory allocation
     
    Things you want to use:
     
    1.) Templates - moves runtime code to compile time and creates optimized code size See GPIO Template Nokia C++ Template
    2.) Use "-Wl,--gc-sections" and "-ffunction-sections" - let the linker figure out which functions you are really using and which can be tossed. This will cut down on the size of your code.
    3.) msp430-objdump -S test.elf - Always look at your generated code and make sure it is generating the best code it can
     
    -rick
  23. Like
    tripwire reacted to RobG in MSP430 Analog read - potentiometer value floating   
    unsigned int sensor4Valor; void setup() { Serial.begin(9600); } void loop() { sensor4Valor = analogRead(A7) >> 3; Serial.print("Pot 1 value = "); Serial.print(sensor4Valor); Serial.println(" | "); delay(1); } or
     
    unsigned int sensor4Valor = 0; unsigned int adc = 0; unsigned int adcMin = 0; unsigned int adcMax = 0; void setup() { Serial.begin(9600); } void loop() { adc = analogRead(A7); if( adc > adcHigh || adc < adcLow) { adcHigh = adc + 2; adcLow = adc - 2; sensor4Valor = adc >> 3; // divide 10 bit to get 7bit, MIDI uses 0-127 } Serial.print("Pot 1 value = "); Serial.print(sensor4Valor); Serial.println(" | "); delay(1); }  
  24. Like
    tripwire reacted to gwdeveloper in Customize Templates in CCS v5.1   
    I don't know if anyone has really noticed, but the default MSP430 template for CCS v5.1 is lacking a few details.
     
    It didn't take much to track down the blank main.c file. In my case, it was located:
    \Texas Instruments\CCSv5\ccsv5\eclipse\plugins\com.ti.ccstudio.project.templates_5.1.0.201110281600\resources\empty
     
    Just edit the main.c file to include any needed information. Most importantly, add:

    #include
  25. Like
    tripwire reacted to roadrunner84 in Is This a decent way to prevent EMP damage on a electronic?   
    You want electronics that are immune to EMP?
    May I suggest?
    *drum roll*
    the vacuum tube!
     
    All and any semiconductor material will die in an EMP, that is, all diodes and transistors (and maybe thyristors too).
    Vacuum tubes (at least when not powered) are not semiconductors. They are just a bunch of wires in a vacuum glass bulb. The semicundutor like behaviour (thermo electric effect) happens only when the cathode in the tube is heated (that's why those sweeties glow); electrons travel easier from the hot cathode to the cold anode, literally hot and cold! Electrons are negative charged particles, so the electrical current is opposite to this; current travels better from anode to cathode than the other way around. All vacuum tubes except diode tubes also contain fine metal meshes, known as grids or gates. You find the name gate in field effect transistors (FETs), and is similar to the base in bipolar junction transistors (BJTs or "normal" transistors).

×
×
  • Create New...