nbm
-
Content Count
11 -
Joined
-
Last visited
Posts posted by nbm
-
-
I just realized that the red LED on the EXP430G2ET is connected to SCK. That would explain why it's drawing power.
-
Yep, without the module I get a nice train of NACKs on the address. Looks like the accelerometer is stretching my clock.
-
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.
-
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.
-
When I take the pull ups out of the circuit, I can drive SCK and SDA in a nice square wave between 0 and about 3.2V.
-
I haven't looked in CCS specifically, but I have found code samples from TI; the above is the smallest program I could make that seemed like it should work.
-
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.
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.
-
Found a solution that works, given a Windows machine: https://blog.kutej.net/2019/03/msp-exp430g2et-linux
This is a pretty serious bug if you want to claim to have Linux support.
-
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
-
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.
I2C Clock driven to 1.8V, bus seems borked
in General
Posted
And with J7 removed, everything works just fine. Note to the future: if trying to do I2C on EXP430G2ET, remove J7. It probably says that somewhere in the user guide.