Jump to content

MSPLife

Members
  • Content Count

    82
  • Joined

  • Last visited


Reputation Activity

  1. Like
    MSPLife reacted to chicken in LDO ic selection   
    Re dual output: use Digikey's parametric search.
    http://www.digikey.com/product-search/en/integrated-circuits-ics/pmic-voltage-regulators-linear/2556290?k=&pkeyword=&FV=fff40027%2Cfff80182%2Cc0007c&mnonly=0&newproducts=0&ColumnSort=0&page=1&stock=1&quantity=0&ptm=0&fid=0&pageSize=25
  2. Like
    MSPLife reacted to cubeberg in Strange voltage on RST pin msp430g2553 TSSOP 20 pin   
    Glad to hear @@MSPLife!
  3. Like
    MSPLife reacted to greeeg in Can not config Pin Osc for capacitive sensing   
    Maybe not useful, but are you running this on a G2 launchpad?
     
    P1.1,P1.2 are connected to the debugger, removing the serial link should isolate them....
     
    But, P1.3 is connected to a switch, and actually has a pull-up and debounce cap (R34/C24) populated on the PCB. this will mess with the capacitive sense, and drain the parasitic capacitance before it can be measured.
  4. Like
    MSPLife reacted to greeeg in structure in Capacitive Touch.   
    See "2.4.2.3 Initializing Structure Members" Here https://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html#Declaring-Structure-Variables-After-Definition
     
    There are a few other ways to assign constant data in structures. It's not normally seen, I'm not sure why. I find it much easier to read/understand.
  5. Like
    MSPLife reacted to roadrunner84 in Problem with msp430g2553   
    Read my signature.
  6. Like
    MSPLife reacted to Fmilburn in LPM and Timer interrup   
    I'm afraid I don't understand your program but if you look in the TI Resource Explorer you will find examples that show how to do it by toggling within the ISR.  For example - msp430g2xx3_ta_02_c. 
  7. Like
    MSPLife reacted to cde in LPM and Timer interrup   
    A timer based delay will not work like you are expecting.
     
    First, every 49 times the code loops, you run Delay(). Which resets the timer (TA1CTL = TACLR). So the interrupt never happens.
     
    Second, You don't do anything in the interrupt. You don't clear the flag. You don't run any code.
     
    Third, your expecting it to block your main code. It won't. It runs in the background, allowing your code to continue. That's why you see most Timer based delays using LPM. LPM stops the main code until the timer interrupt happens, and then starts running the code again.
     
    If you want something to work like that, you need a blocking delay (Like running a large "for" loop), or LPM, or using the interrupt to run the code.
  8. Like
    MSPLife reacted to greeeg in Timer interrupt   
    Your timer currently count to CCR0. CCR0 is set to 49,999 When your timer reaches 49,999 an interrupt occurs. and the next timer value is 0. CCR1 is set to 24,999 When the timer value reaches 24,999 it will cause an interrupt.  
    Hence you're leds blink at the same rate. It takes the timer the same amount of time to count
    from 0 to 49,999  = 50,000 ticks
    and 25,000 to 24,999 = 50,000 ticks.
     
     
     
    How do you fix this. I would recommend the following. (but there are multiple ways.)
     
    Set TA0 to run in continuous mode, instead of up mode. (Your code comments mistakenly say continuous, but you've been setting it to up mode)

     
    When CCR0 ISR fires, you need to add your new period to CCR0 When CCR1 ISR fires, you need to add your new period to CCR1 void TIM_TRIG_ADC_CFG(){   CCTL0 &= ~CCIE;   CCTL1 &= ~CCIE;   TACTL = TASSEL_2 + MC_2; // Set the timer A to SMCLCK, Continuous   TACCR0 = 50000-1;   TACCR1 = 25000-1;   CCTL0 |= CCIE;   CCTL1 |= CCIE;   // Clear the timer and enable timer interrupt   __enable_interrupt(); } #pragma vector=TIMER0_A0_VECTOR __interrupt void Timer_A00 (void) {   CCR0 += 50000;                  // Return in 50,000 cycles   if(!((++timerCount)%32)){     Toggle(1,0);                  //Toggle RED LED   } } #pragma vector=TIMER0_A1_VECTOR __interrupt void Timer_A01 (void) {   switch(__even_in_range( TA0IV, 10)) {   case 0x00:                      // None     break;                           case 0x02:                      // CCR1 IFG     CCR1 += 25000;                // Return in 25,000 cycles     if(!((++timerCount1)%32))       Toggle(1,6);                // Toggle GREEN LED   break;     default:     break;   } } Now most of the time adding large value like this is dangerous, because of integer overflow. But it's okay here, because the timer counter itself is overflowing in exactly the same way.
  9. Like
    MSPLife reacted to greeeg in Timer interrupt   
    Can you tell me which processor you are using, it will make this explanation more specific.
     
    Why we need to check TA0IV.
    First, T0A2 interrupt does not exist. This is the purpose of TA0IV (Timer A0 Interrupt Vector)
     
    Interrupts require a fair amount of hardware (priority encoders, etc). To keep this manageable, the MSP430 are conservative with their interrupts. Lets look at the interrupts inside a MSP430G2955

     
    There is only 15 unique interrupt vectors! Note that the CPU in the G2955 supports 32 interrupt vectors.
     
    Let's look at it's timer. Timer0_A3. This means that this timer contains 3 capture/compare modules. So that means 3 interrupts right? Actually 4, the timer itself has an overflow interrupt. But this timer is only assigned 2 unique interrupt vectors.
    Timer0_A0 handles
    TACCR0 - CCIFG Timer0_A1 handles
    TACCR1 - CCIFG TACCR2 - CCIFG TAIFG (overflow) To differentiate we must check TA0IV to determine the exact source within Timer0_A1
     
    Why not have all 4 separately? This might work on this particular IC, however larger MSP's include Timers with upto 7/8 CCR's There is not enough interrupt vectors to handle all those sources.
     
    Note it's easy to get confused by the vector names. You can check the header file for your MSP430 to see the available vector names.

     
     
    "If I want to use TImer0A2, I need to check TAIV in Timer0A2 ISR as well?"
    This will be part of the Timer0_A1 ISR. but yes, you need to check the TAIV.
    #pragma vector=TIMER0_A1_VECTOR __interrupt void Timer_A01 (void) { switch(__even_in_range( TA0IV, 10)) { case 0x00: // None break; case 0x02: // CCR1 IFG if(!((++timerCount1)%32)) Toggle(1,6); // Toggle GREEN LED break; case 0x04: // CCR2 IFG if(!((++timerCount2)%32)) Toggle(1,0); // Toggle RED LED break; default: break; } } You can find in the family guide, that a value of 2 in TAIV represents CCR1, a value of 4 represents CCR2.

  10. Like
    MSPLife reacted to Fmilburn in Timer interrupt   
    Oops
     
    @@greeeg
     
    Implementing your suggestions on my code seems to work...
    // Written for the F5529 // //***** Include ********************************************************************************* #include <msp430.h> //***** Define ********************************************************************************** #define RED_LED BIT0 // P1.0 is the red LED #define GREEN_LED BIT7 // P4.7 is the green LED //***** Main ************************************************************************************ main() { WDTCTL = WDTPW | WDTHOLD; // Stop watchdog timer P1DIR = RED_LED; // Set red LED to output P4DIR = GREEN_LED; // Set green LED to output TA0CCR0 = 50000; // Timer A0 counts to this number TA0CCR1 = 25000; // Timer A1 counts to this number TA0CTL = TASSEL_2 + MC_1; // Timer A0 using SMCLK, continuous TA0CCTL0 = CCIE; // Enable the interrupt for Timer0_A0 TA0CCTL1 = CCIE; // Enable the interrupt for Timer0_A1 _BIS_SR(GIE); // Global activation of interrupts) while(1); // Wait here for the interrupt } //***** TimerA0 ISR ****************************************************************************** #pragma vector=TIMER0_A0_VECTOR __interrupt void Timer0_ISR (void) { P1OUT = P1OUT ^ RED_LED; // Toggle the red LED } //***** TimerA1 ISR ****************************************************************************** #pragma vector=TIMER0_A1_VECTOR __interrupt void Timer1_ISR (void) { switch(__even_in_range( TA0IV, 10)) { case 0x00: break; // None case 0x02: // CCR1 IFG P4OUT = P4OUT ^ GREEN_LED; // Toggle the green LED default: break; } } Snippet from a TI course....

  11. Like
    MSPLife reacted to greeeg in Timer interrupt   
    @@MSPLife
     
    The only other thing I can think off is regarding your initialization of CCR's
    TACCR0 = 50000-1; TACCR1 += 25000-1; Suppose TACCR1 is not initialized to 0 on reset. Or is TIM_TRIG_ADC_CFG() is called multiple times.
    If TACCR1 > TACCR0 Since you reset the TAR when it reaches CCR0, then it will never reach CCR1.
     
    I would suggest changing these lines to
    TACCR0 = 50000-1; TACCR1 = 25000-1; This might not produce the desired result. Both the interrupts will fire at the same rate, just offset by half a cycle. This is how your original code operated.
    A0 IFG _______^________^_______ A1 IFG ___^_______^________^___
  12. Like
    MSPLife got a reaction from Fmilburn in Timer interrupt   
    Dear greeeg,
    I put a breakpoint in TIMER0_A1_VECTOR, but it doeasn jump to that.
     
  13. Like
    MSPLife reacted to greeeg in MSP430 + 74HC595 trouble   
    You're solution should work. But less about waiting for the transmission to finish (while still important). The 74xx595 will latch it's outputs on the RISING edge. The original code assumes it is latching on the FALLING edge.
  14. Like
    MSPLife reacted to oPossum in MSP430 + 74HC595 trouble   
    Wait for transmission of all bits to complete before latching the outputs
     

    void WriteData(unsigned char data) //SPI {     UCB0TXBUF = data; // Transmit character     while(UCB0STAT & UCBUSY);        // Wait for all bits to finish P2OUT |= LATCH_BIT; // Pulse latch P2OUT &= ~LATCH_BIT; }
  15. Like
    MSPLife reacted to bluehash in Ti promotional not right?   
    Ok.. TI got back to me and looks like the issue has been fixed. It might end today and I think you are ahead of the US...so you might miss it. I've requested an extension. Will let you know if there are any updates.
     
    Edit: Extended till Oct 8th.
  16. Like
    MSPLife got a reaction from tripwire in Ti promotional not right?   
    Today (04/10/2015), I'm going to buy https://store.ti.com/ek-tm4c129exl.aspx, but TI's store does not provide promotional price as they promoted.
    Please help to make me clear.
    Thanks!
  17. Like
    MSPLife reacted to roadrunner84 in How to create text style   
    Figlet, a free and open tool.
  18. Like
    MSPLife reacted to Rickta59 in How to create text style   
    http://patorjk.com/software/taag
  19. Like
    MSPLife reacted to bluehash in Generate .hex file   
    Yes, you can!
    Goto->Project->Properties->Build->MSP430 Hex Utility
     

     
    Also, see the TI wiki here.
     
    One thing to note that, I wan unable to see this on an MSP430 project built with an older version of CCS.
  20. Like
    MSPLife reacted to L.R.A in CCS linker configuration file   
    It seems you have Code in your RAM.
    So SRAM_CODE should be the code you have in the RAM while SRA_DATA is the memory used for variables. You got that from the .MAP?
  21. Like
    MSPLife reacted to bluehash in CCS linker configuration file   
    Yes.. the CC3200 does not have flash. It loads code into SRAM from an external flash chip at boot.
  22. Like
    MSPLife reacted to enl in Prevent reading code   
    You need to explicitly request the fuse be blown (or the flash equivalent on those without the physical fuse). I don't have a MSP-FET, and have never done it on these processors, but I have seen it in the documentation, and done it with other families.
     
    Blowing the fuse is like blowing a fuse in your electrical box: blown is blown. Once the fuse is blown, the JTAG interface is disabled on the device. Forever. It can never be re-enabled, even by reflashing the device via BSL.There is no going back. (see, for example, SLAS722g, page 36, `JTAG Fuse', note (1)-- this is for MSP430g2X12/2X52, but others with the fuse are similar)
     
    In the devices with no fuse (that use an enable code in flash instead), the status is checked at powerup, and the JTAG hardware not enabled unless the status (in flash) is correct. On reprogram  (via BSL), this can be reset.
     
    Again, the device can still be accessed via BSL, so you need to SET THE PASSWORD (32 bytes) to prevent the device memory from unauthorized reads. See SLAU319I, sec 2.7 for details (password is interrupt vector space; any that are not in use can be set freely) This also explains how to enable/disable the automatic memory wipe on incorrect password and/or disable BSL entirely.
     
    Edit: add ref to SLAS722
    Edit 2: ref SLAU319
  23. Like
    MSPLife reacted to KatiePier in Prevent reading code   
    Hi @@MSPLife,
     
    @@enl's summary above is spot on.
     
    One or two more additions about BSL - with the BSL password protection, as @@enl mentioned you cannot read out the part unless you provide the correct 32-byte BSL password. Now, if you provide an incorrect password, the part will do a mass erase which should get rid of the code in the part - that is to try to help against someone brute-forcing your password. After your code is erased, there's not anything for them to read anymore of value. This should all be described in www.ti.com/lit/pdf/slau319
     
    The other point I wanted to make was, that only some parts in the G2xx family have a BSL in hardware - G2xx3/4/5 do, but the earlier G2xx1/2 don't I believe. Make sure to check your device datasheet if you want to use BSL. If you still need to do firmware updates, but also want to blow the JTAG fuse on a G2xx1/2 that does not have BSL, you could look into doing a main/info memory bootloader like discussed in the MSP-BOOT app note SLAA600, or potentially the tiny G2xx loader mentioned at the end of SLAA450.
     
    But as @@enl and others have mentioned, there's not one way to make sure you are 100% safe if someone really has the resources time and motivation trying to break in with some fancy tools - this is true of any IC. But you do what you can to make it harder for someone to do it - it's like locking the door on your car.
     
    Regards,
    Katie
  24. Like
    MSPLife reacted to roadrunner84 in Prevent reading code   
    Depending on how hard you want to make stuff and your scale of production, just clipping/cutting/drilling off the TEST pin after programming might be enough for you...
  25. Like
    MSPLife reacted to enl in Prevent reading code   
    docs are the references above from TI. Google for SLAU319 and 320. This is really not a 30 second, one paragraph thing to answer. The protection is provided via a number of options using the same interfaces that are used for programming.
     
    The option with BSL is to set the password (32 bytes, which is a 256bit password) that will be required for the read command to be used to read the code memory, either via JTAG or BSL. Disabling JTAG reduces the risk of several possible exploits that can get information without an explicit read (see the docs on the CCC website for more info).
     
    NOTHING can provide absolute security. I could decap the IC an use several methods to directly read the code memory if I wanted it bad enough (well, I personally couldn't at this time, but some of my former students could, and I could have when I was still in university, and, now that I think about it, maybe I could now, but I would need several samples to work with, and I wouldn't bet my house on it). More work than in the old days of mask programmed ROM, where you could pretty much read the data with an optical microscope, but still not a major challenge with appropriate gear. ANY security you use can be broken, and the issue is whether it is some guy in his basement, or if it requires equipment that only someone with enough money to reproduce you work from the ground up anyway will have.
     
    Edit: 32*8 is 256 bit password, not 512. I have become too used to working with 16bit words over the last few years....
×
×
  • Create New...