Jump to content
43oh

nbm

Members
  • Content Count

    11
  • Joined

  • Last visited

Posts posted by nbm

  1. Alright, this is weird. After having P1.6 and P1.7 configured as outputs, if I program it with the code I posted I get the results I expect. However, as soon as I power cycle the system, it:

    • pulls SCK and SDA low
    • waits 282 ms
    • then both go high for a quarter of a millisecond
    • SDA goes low while SCK is high (start condition)
    • SCK pulses low for 5μs
    • everything stops, with SDA low and SCK high forever

    Trying it without the accel module next.

     

  2. I've tried with and without. The only difference is the exact voltage (and size of pull up resistor). That makes me suspect it's sinking a lot of current through the SCK pin. With the 4.7k pull ups on the breakout board, that's about 300μA through the pin. I just tried it again with 100k pull ups, and it went to 2.3V. That's about 1μA.

  3. I've got a pretty simple project, connecting an LIS3DH accelerometer to an MSP430G2553 (using MSP-EXP430G2ET). 

    Here's the code:

    #include <stdint.h>
    #include <msp430.h>
    
    #define SLAVE_ADDR 0x19
    
    int main(void)
    {
        WDTCTL = WDTPW + WDTHOLD; // Stop WDT
    
        __disable_interrupt(); // Just polling for now
    
        // Set to 1 MHz operation
        BCSCTL1 = CALBC1_1MHZ;
        DCOCTL = CALDCO_1MHZ;
        
        // Configure P1.6 and P1.7 as I2C SCL and SDA respectively
        P1SEL = 0xc0;
        P1SEL2 = 0xc0;
    
        // This byte is signed for some reason. P1.3 is the button input.
        P1DIR = ~(int8_t)(BIT6 | BIT7 | BIT3);
        P1OUT = 0;
    
        // Initialize I2C subsystem
        UCB0CTL1 |= UCSWRST; // Enable SW reset
        UCB0CTL0 = UCMST + UCMODE_3 + UCSYNC; // I2C Master, synchronous mode
        UCB0CTL1 = UCSSEL_2 + UCSWRST; // Use SMCLK, keep SW reset
        UCB0BR0 = 10; // 1 MHz / 10 = 100 kHz
        UCB0BR1 = 0;
        UCB0I2CSA = SLAVE_ADDR;
        UCB0CTL1 &= ~UCSWRST; // Clear SW reset, resume operation
        IE2 &= ~(UCB0RXIE + UCB0TXIE); // Disable RX and TX interrupt
    
        while (1)
        {
            while (UCB0CTL1 & UCTXSTP); // Wait for stop
            UCB0CTL1 |= UCTXSTT; // Gen start
            while (UCB0CTL1 & UCTXSTT); // Wait until addr clocked out
            UCB0CTL1 |= UCTXSTP; // Gen stop
        }
    }

    I just have the SCL and SDA pins, as well as 3.3V and ground connected to a SparkFun LIS3DH breakout board. My logic analyzer shows a start condition (SDA high->low while SCK high) followed by a single clock pulse (it stays low for about 5μs; half a cycle at 100 kHz) and then it just freezes there. The data line stays pulled low forever while the clock stays high forever.

    However, the clock line's high is about 1.8V even though it's being pulled up to 3.3V (if I disconnect the MSP430, it goes up to 3.3). The data line is a touch under 3.3V when high.

    Here's a screen capture from my logic analyzer.1_8v.thumb.png.010515cb733dec380da6387f0cd2cfb2.png

    If the pin is open drain, I don't see how it drives it to 1.8V. Am I missing something in my setup code? Further, even with the weird 1.8V output, I would expect the above code to at least clock out the address, read bit, and ACK/NACK. I'd expect that even with the accelerometer disconnected.

    So I tried disconnecting the accelerometer entirely, and adding some external pull ups on SDA and SCL, and I see basically the same thing, though my pull ups are larger so I see 1.6V on the clock line. SDA is spot on at 3.3V.

  4. Checked out and tried the latest version of mspdebug.

    Quote

    $ LD_LIBRARY_PATH=~/msp430/energia-1.8.10E23/hardware/tools/DSLite/DebugServer/drivers/ ./mspdebug --allow-fw-update tilib
    MSPDebug version 0.25 - debugging tool for MSP430 MCUs
    Copyright (C) 2009-2017 Daniel Beer <dlbeer@gmail.com>
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
    Chip info database from MSP430.dll v3.15.0.1 Copyright (C) 2013 TI, Inc.

    Using new (SLAC460L+) API
    MSP430_GetNumberOfUsbIfs
    MSP430_GetNameOfUsbIf
    Found FET: HID_FET
    MSP430_Initialize: HID_FET
    FET firmware update is required.
    Starting firmware update (this may take some time)...
    tilib: MSP430_FET_FwUpdate: MSP-FET / eZ-FET recovery failed (error = 73)
    tilib: device initialization failed
     

  5. I got an MSP-EXP430G2ET yesterday, and after installing drivers and Energia (Debian unstable) I plugged it in and opened up the blink example. Energia spat out some messages about the firmware needing updating, and started the process. I don't have the log (it's fallen off my console's buffer) but it did not appear to complete successfully. Now, when I try to use Energia to flash the blink example, I get this:

    Sketch uses 386 bytes (2%) of program storage space. Maximum is 16384 bytes.
    Global variables use 20 bytes (3%) of dynamic memory, leaving 492 bytes for local variables. Maximum is 512 bytes.
    DSLite version 9.3.0.1863
    Configuring Debugger (may take a few minutes on first launch)...
            Initializing Register Database...
            Initializing: MSP430
    error: MSP430: Error initializing emulator: One of the connected MSP-FETs / eZ-FETs debuggers needs recovery. Select 'Recover' to start the recovery process.  Note: Only one MSP-FET / eZ-FET debugger can be connected to your system during recovery.
    Updating Firmware
    error: MSP430: Error: MSP-FET / eZ-FET recovery failed
    Failed: MSP430: Error initializing emulator: MSP-FET / eZ-FET recovery failed
    
    the selected serial port 
     does not exist or your board is not connected

    It's interesting that it says DSLite even though I selected mspdebug through the tools menu.

    So I figured I'd try just compiling a trivial C program and flashing it manually.

    $ mspdebug tilib

    appears to work, as long as I have the appropriate .so file in my dynamic loader's search path. However, this happens when I try to flash anything.

    $ LD_LIBRARY_PATH=energia-1.8.10E23/hardware/tools/DSLite/DebugServer/drivers/ mspdebug tilib
    MSPDebug version 0.22 - debugging tool for MSP430 MCUs
    Copyright (C) 2009-2013 Daniel Beer <dlbeer@gmail.com>
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
    
    MSP430_GetNumberOfUsbIfs
    MSP430_GetNameOfUsbIf
    Found FET: HID_FET
    MSP430_Initialize: HID_FET
    Firmware version is 4294967294
    MSP430_VCC: 3000 mV
    MSP430_OpenDevice
    MSP430_GetFoundDevice
    Device:  (id = 0x0000)
    0 breakpoints available
    MSP430_EEM_Init
    Chip ID data: 02 00
    
    Available commands:
        =           erase       isearch     power       save_raw    simio       
        alias       exit        load        prog        set         step        
        break       fill        load_raw    read        setbreak    sym         
        cgraph      gdb         md          regs        setwatch    verify      
        delbreak    help        mw          reset       setwatch_r  verify_raw  
        dis         hexout      opt         run         setwatch_w  
    
    Available options:
        color                       gdb_loop                    
        enable_bsl_access           gdbc_xfer_size              
        enable_locked_flash_access  iradix                      
        fet_block_size              quiet                       
        gdb_default_port            
    
    Type "help <topic>" for more information.
    Use the "opt" command ("help opt") to set options.
    Press Ctrl+D to quit.
    
    (mspdebug) prog minimal.elf
    Erasing...
    Programming...
    Writing   80 bytes at c000 [section: .text]...
    Writing   32 bytes at ffe0 [section: .vectors]...
    Done, 112 bytes total
    (mspdebug) verify minimal.elf
    Verifying   80 bytes at c000 [section: .text]...
    ERROR: mismatch at c000 (read 00, expected 55)
    (mspdebug) 

    I suspect this is a problem with the on-board debugger. Any information on how to fix this would be appreciated.

×
×
  • Create New...