Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


jp430bb last won the day on November 20 2016

jp430bb had the most liked content!

About jp430bb

  • Rank
    Advanced Member
  1. I just confirmed that the patch above still works OK with the MSP430F449.
  2. 4-wire JTAG with this setup did not work for me with an MSP430G2452. Mspdebug gave me a response that it read 0xFF for a device ID and exited. However, looking at the JTAG entry sequence on my scope, it didn't look quite right. I patched mspdebug again, and now I get a connection to the MSP430G2452. I haven't changed my wiring back to try it with the 'F449 yet, so I may have broken that. $ git diff diff --git a/drivers/jtaglib.c b/drivers/jtaglib.c index 1161606..17975ce 100644 --- a/drivers/jtaglib.c +++ b/drivers/jtaglib.c @@ -386,12 +386,20 @@ unsigned int jtag_init(struct jtdev *p)
  3. Having a small collection of older F1xx and F4xx MSP430 devices, I've been looking for a convenient way to flash and debug them. The devices I have don't support Spy By Wire, so they require 4-wire JTAG. They also have their JTAG pins shared with other functions, so the test and reset pins have to be used to put them into JTAG mode. While I do have an Olimex parallel-port JTAG adapter, the computer I use most of the time has no parallel port. A Raspberry Pi running Debian Jessie and mspdebug with its gpio driver looked like a good option. Adding a patch to mspdebug so that the g
  4. [Edit: after posting this, I found out I needed to use the rom-bsl driver for mspdebug. That works!] [Edit 2: after a reboot, I no longer have to do anything to toggle the RTS line.] I have a tube of old MSP430F1232 bare chips in the SOIC-28 package, and I thought I'd make an attempt to flash one using a USB CP2102 serial adapter. However, I haven't been able to flash the chip yet. The TEST and /RST pins are connected to RTS and DTR, respectively. Comparing my scope trace with the timing diagram in SLAU319L Figure 2, the sequence looks right. However, mspdebug reports
  5. I managed to get a SensorTag2 Debugger Devpack rev. 1.3.0 and use CCS Cloud to flash the sample stack and application v. 1.2 to my CC2650STK. Using the Android app (still no update since Summer, 2015), I still have the problem with the accelerometer/gyro/magnetometer freezing after about 10 readings. Should this FW and Android app combination be expected to work? By the way, the ambient temperature went up almost 10C above ambient while connected to the debugger. No melted plastic, though, fortunately. I checked the voltage at the BAT+ BAT- pads and saw 2.983V.
  6. "Absolute maximum ratings exceeded" I lost an ethernet chip to a lightning strike once. The rest of the motherboard worked fine for years afterwards.
  7. Sounds like I should add the Debug DevPack to my to-buy list! By the way, I'm seeing other places that the IMU freezes are commonly seen with the version of the firmware and Android app I have. Hopefully, TI issues an update soon.
  8. I checked the battery voltage at the two exposed pads on the PCB, and the lowest reading I saw while connected to my phone was 3.011V. My Fluke 77-IV is only so fast, so it's possible there are dips a bit below that. Anyway, low battery voltage doesn't seem to be a likely cause, and I'm leaning toward a firmware 1.12 bug. Unfortunately, I didn't buy the SensorTag DevPack, so I can only update the firmware via Bluetooth and the Android app. Hopefully, TI will update the app soon. About the SensorTag DevPack---can the XDS-110ET included on the MSP432 LaunchPad possibly be used as
  9. The SensorTag shipped with a plastic film over the battery, so it shouldn't have run down already, unless that original firmware was *really* power hungry. Was the power consumption fixed in the 1.12 firmware? I tried a replacement battery, and I did see a few updates in the Motion Data section, with accelerometer, gyro, and magnetometer all showing some non-zero values, but then they all froze. After disconnecting and reconnecting, it's back to showing all zeros under Motion Data. Removing the battery and putting it back in again, I get the same behavior. It looks like 9 updates of
  10. My CC2650STK just arrived, and I'm checking it out with the TI demo Android app. The humidity, noncontact temperature, barometric pressure, and lux sensors all behave like they should, but the app doesn't show sensible data for acceleration, rotation, or magnetic fields. All those fields show zero. I've updated the CC2650STK firmware to revision 1.12 (Jun 23 2015) using the Android app. The Android app is revision 2.3. I'm running it on a 1st-gen Moto X with Android 4.4.4. Is this a known software issue, or do I have bad SensorTag hardware?
  11. Those don't have SBW, but their boot strap loader might be an option.
  12. I'm not getting meaningful data from the ADS1118 on the Booster Pack with the Stellaris LaunchPad and the Energia sketch below. I think the Booster Pack is OK, as it functions normally on an MSP430 Value Line Launch Pad with the demo MSP430G2553 MCU. The LCD stuff in the sketch below works fine with the Stellaris LaunchPad. Any pointers on what I'm doing wrong? // Stellaris LaunchPad with ADS1118 Booster Pack #include <SPI.h> const int LCD_RS = 12; // Register Select const int LCD_CS = 13; // LCD chip select const int ADS1118_CS = 8;
  13. The ADS1118 Booster Pack is a 20-pin design, so it doesn't connect to any Stellaris GPIO Port C pins.
  14. I've added a pinMode(2, INPUT_PULLUP) after the SPI stuff in setup() to stop the buzzer from sounding. Except for what looks like a conflict with the JTAG pins, I've got SPI writing to the ADS1118 Booster Pack LCD OK now.
  15. I'm back with another issue with my Stellaris LaunchPad. I have a short Energia sketch which uses the SPI library to write to the serial LCD on the ADS1118 Booster Pack. The sketch works as expected. The problem is that it somehow leaves the Stellaris in a state in which it cannot be flashed successfully by lm4flash. I have to connect the Stellaris LaunchPad, flash it (works fine the first time), disconnect the USB cable, reconnect, flash again, and so on. The symptoms seem to match what a TI employee posted on the E2E Community back in 2011, where changing the function of PORTC pins
  • Create New...