Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by calin

  1. Oh right, i used my same address and same gmail mail address I used before. But I listed as "Independent Designer" as company and None as company URL. This time the order was given the OK and shows up completed and shipped.


    I don't mind they limted the number of samples - if I fry 2 or 3 or 5 chips they provide as samples then shame on me


    Thanks guys.. valuable info as always !!!


    PS: Probably I should take the time to set that damn domain I have with GoDaddy .... but pool side life is too nice now in summer :)

  2. Oddly enough , not sure but did TI's samples policy changed lately? I probably order some samples maybe 3-4 times in a year but for example this year I've put my second only order and it got rejected - no company mail ... bla bla ....


    Also I noticed that now you have to list a company name no matters what when I place an order. I am not complaining don't get me wrong but I was seeing TI as one of the few electronics company that had an reasonable approach to chip samples ... did they really go on the "cheap side" ?!!!   



  3. Weird, I guess it does overshoot .. but I find it indeed odd. I guess may be the a very sharp rise that cause the scope overshoot. But heck all of 3 scopes ... one scope is an 1Ghz capable Agilent scope (I am sampling a lousy few kz signal .. how fast can it rise :) The sample shots are from a 100Mhz Owon SDS7102 I have @ home. 


    I find it odd still because as you can see attached a 1MHZ 3v Pk to Pk  from sig gen. and not even a hint of overshoot - so probe is pretty well calibrated. 


    Anyways, the PWM works so I will move into putting this one on a final board ad call it done. 






  4. I have 3 scopes, signal generator also ... unless everything has gone crazy and all 3 overshoot.


    I tried 5-6 chips, MSP430G2231 and an 2553 - two different Launchpads ... same all of them. Each transition is one nasty spike. 

    I am starting to regret I took MSP430 for this tiny project :smile:.  But it is the right pick for this kind of job (a simple temperature controlled fan with PID) and I want to use new stuff also.

  5. Circuit is literally just the launchpad with nothing attached. PWM output on P1.6. Hooked up to my computer USB (so powered by USB). So no motor no load no nothing. And I am 100% my scope does not overshoot :smile:


    BTW, I did tested with the motor and the 2222 attached also .. exactly same ringing. Yeah I have the fly-back diode etc on. The annoying thing is that this ringing cause really weird things on the transistor switching. 


    Attached are some data captures from my scope.  Scale is 2V/Div . Time base is 20uS - not matching the code above because I was playing with duty cycles.





  6. I am doing a fan controller using PWM. All nice, things work good etc. but I noticed something really odd on PWM output the transition has an super nasty ringing happening which is almost 5V peak to peak. It overshoots really nasty in both directions/transitions. I used the sample code from TI with just the launchpad nothing else connected except the scope. Tried different pins instead of 1.6 also .. same.


    Normally the output should swing smoother - a ring from 3.6V to 5V is huge. Did you guys ever noticed something like that ? pretty nasty.


    BTW ... with a simple 1uF cap to ground i reduced the spike/ring to 4.12 and it settles very fast but still I find this annoying. Especially when you switch transistors the spike does not very nice things down the line.


    #include  <msp430g2231.h>
    void main(void)
      WDTCTL = WDTPW + WDTHOLD;                 // Stop WDT
      P1DIR |= BIT6;                            // P1.6
      P1SEL |= BIT6;                            // P1.6 TA1/2 options
      CCR0 = 512-1;                             // PWM Period
      CCTL1 = OUTMOD_7;                         // CCR1 reset/set
      CCR1 = 384;                               // CCR1 PWM duty cycle
      TACTL = TASSEL_2 + MC_1;                  // SMCLK, up mode
      _BIS_SR(CPUOFF);                          // Enter LPM0
  7. Man thanks for the tip .. I built the patched kernel module and the UART works a treat now.


    BTW here is the link to the thread that has the references to the patch. http://www.43oh.com/forum/viewtopic.php?f=38&t=2866#p21040


    The link to the file is http://www8.zippyshare.com/v/10251460/file.html - if you have to re-build the module make sure you do first a dos2unix on all files - looks like the zip was created on Windows and all endlines are "broken" in the driver files. In rest all good

  8. I think I may have answered my own question ... Clearly something is hosed with the cdc_acm module. Just after posting I realized that I still have around few older kernels on my machine. So a quick reboot into


    Linux obellix 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux


    and I managed to connect successfully, then plug unplug killed the serial again.

  9. It seems that something bad has happened with latest kernel on linux - at least on the version I am using. Looks like the cdc_acm driver is completely busted in the latest version. See bellow logs ..


    Does anyone has this issue? I am 100% is not the launchpad, works under Windowz. Also I am 10% is not something stupid like permissions :) . I want to check first, if anyone else has it then I-ll ding the linuxusb-dev group to check with them.


    I use Ubuntu 12.04 64 bit - uname =

    Linux obellix 3.2.0-27-generic #43-Ubuntu SMP Fri Jul 6 14:25:57 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux


    The picocom session is this


    calin@obellix:~$ sudo picocom /dev/ttyACM0 
    picocom v1.4
    port is        : /dev/ttyACM0
    flowcontrol    : none
    baudrate is    : 9600
    parity is      : none
    databits are   : 8
    escape is      : C-a
    noinit is      : no
    noreset is     : no
    nolock is      : no
    send_cmd is    : ascii_xfr -s -v -l10
    receive_cmd is : rz -vv
    FATAL: cannot open /dev/ttyACM0: Input/output error


    The FATAL matches the "tty_port_close_start: tty->count = 1 port count = 0." in dmesg .


    Jul 25 23:04:05 obellix kernel: [ 3635.690997] usb 7-1: new full-speed USB device number 5 using uhci_hcd
    Jul 25 23:04:05 obellix kernel: [ 3635.902227] cdc_acm 7-1:1.0: This device cannot do calls on its own. It is not a modem.
    Jul 25 23:04:05 obellix kernel: [ 3635.902232] cdc_acm 7-1:1.0: No union descriptor, testing for castrated device
    Jul 25 23:04:05 obellix kernel: [ 3635.902251] cdc_acm 7-1:1.0: ttyACM0: USB ACM device
    Jul 25 23:04:15 obellix kernel: [ 3645.949792] generic-usb 0003:0451:F432.000C: usb_submit_urb(ctrl) failed
    Jul 25 23:04:15 obellix kernel: [ 3645.949805] generic-usb 0003:0451:F432.000C: timeout initializing reports
    Jul 25 23:04:15 obellix kernel: [ 3645.950374] generic-usb 0003:0451:F432.000C: hiddev0,hidraw2: USB HID v1.01 Device [Texas Instruments Texas Instruments MSP-FET430UIF] on usb-0000:00:1d.1-1/input1
    Jul 25 23:07:09 obellix kernel: [ 3820.261188] tty_port_close_start: tty->count = 1 port count = 0.

  10. Here it is .. nothing fancy about it.


    WDTCTL = WDTPW + WDTHOLD; // Disable watchdog
    /* Set all pins - note that P1.1/BIT1 is set in analog mode by ADC_init() */
    P1DIR = 0x00;
    P1OUT = 0x00;
          /* init ADC */ 
    ADC10CTL0 &= ~ENC; //disable first to make the ADC is in a known state before setup
    ADC10CTL0 = SREF_0 + ADC10SHT_2 + ADC10ON + ADC10IE; // Use Vcc/Vss for Up/Low Refs, 16 x ADC10CLKs, turn on ADC with interrupts
    ADC10CTL0 &= ~REFOUT;
    ADC10CTL1 = INCH_1 + SHS_0 + ADC10SSEL_0 + ADC10DIV_7 + CONSEQ_0; // A1 input, use ADC10CLK div 1, single channel mode, ADC10CLK/16
    ADC10AE0 |= BIT1; // Enable ADC input on P1.1
        // main loop  ---------------------------------------------------
       while(1) {
    	ADC10CTL0 |= ENC + ADC10SC; // start a new conversion
    	__bis_SR_register(CPUOFF + GIE); //LPM0 with interrupts continue on interrupt 
    	ADC10CTL0 &= ~ENC;
    	volts = ADC10MEM * 0.003519062; // 		
    	// doing something with volts here 
                 delayMiliseconds(998); //make one measurement per second

    delays and the interrupt

    inline void delayMicroseconds(unsigned int time) {
    TACCR0 = time - 1; // Upper limit of count for TAR
    TACTL = MC_1 | ID_0 | TASSEL_2 | TACLR; // Set up and start Timer A
    while ((TACTL & TAIFG) == 0) {
    } // doing nothing
    TACTL &= (~TAIFG); // Clear overflow flag
    inline void delayMilliseconds(unsigned int delay) {
    while (delay > 60) {
    	delay -= 60;
    if (delay)
    	delayMicroseconds((delay << 10) - (delay << 4) - (delay << 3));
    #pragma vector=ADC10_VECTOR
    __interrupt void ADC10_ISR(void) {
    __bic_SR_register_on_exit(CPUOFF);// Return to active mode

  11. BTW , sorry Rob I feel like I hijacked this thread.


    Yes it is always recommended .. but if you choose to save few cents for an opamp :) ... a divider is good.


    BTW, I definitely have the circuits wired right, reading and all code right but I am still puzzled why is the input resistance influencing voltage on this chip. For a sanity check I used an arduino to do the same thing, the measured voltage doe not get influenced in any way. Also as per the equivalent schematic given by TI of the ADC pin Ri should not influence the voltage in any way ... this thing is very weird and contradicts all I know about electronics :)


    Here is an equivalent input circuit as I have it now:

    Vin --+      /--------
         |      | MSP430
         4.7K   |
         |    A1| 
         +------|-Ri/2k--+--ADC sampler
         |      |        |
      1k      |      Ci/27pf
         |      |        |
    GND --+      |        |
                \        |


    Now as the schematic with the equivalent shows Ri is decoupled from GND by Ci, therefore it should not influence the input voltage on the divider in any way. That is what theory says ... Now do you have any idea why the MSP430 is doing this. I even changed few chips to make sure is not a bad one .. all do the same.


    Any idea , good sense says it should work this way with no issues.

  12. I used initially a 51k/10k divider .. but then as you said I've read the MSP430G2553 data sheet and realised that the input resistance says is around 1K and 27pF capacitance. So I switched to a 4.7K/1k divider which seems to be doing it just right 0-20V becomes a 0-3.5 ish . With these values thing are looking much more normal.


    To that extent the 1K figure in the data sheet is not exactly true .. (if you look at the TI data sheet for MSP430G2553 @ page 37 says Ri = 1000 ohm) .. from where did you got the approx 2K figure?


    I am leaning towards using an high impedance precision opamp on inputs ... something like CA3130 or TLE2141.

  13. Nice project ... I like it. I was playing with something similar for a bench power supply I am building.


    I have one question. While working on my meter I noticed that the ADC on the MSP430 has an habit of influencing the "measured" circuit with its impedance. For example in my case a simple voltage divider that brings 0-20V to 0-3.3V is influenced by the ADC input impedance in quite nasty ways.


    I do not see anything special in the input channel circuits you have in the schematics that would deal with this issue. Or am I missing something obvious as a novice that I am :) ?

  • Create New...