Jump to content
Forum sending old emails Read more... ×

jp430bb

Members
  • Content Count

    38
  • Joined

  • Last visited

  • Days Won

    1

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) jtag_rst_clr(p); p->f->jtdev_power_on(p); - jtag_tst_set(p); jtag_tdi_set(p); jtag_tms_set(p); jtag_tck_set(p); jtag_tclk_set(p); + + jtag_rst_set(p); + jtag_tst_clr(p); + + jtag_tst_set(p); jtag_rst_clr(p); + jtag_tst_clr(p); + + jtag_tst_set(p); + p->f->jtdev_connect(p); jtag_rst_set(p); jtag_reset_tap(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 gpio driver supports the reset and test pins got it working. The patch is here: https://github.com/johnp789/mspdebug/tree/gpiojtag Now, I only need a Raspberry Pi Zero, Debian Jessie with the USB ethernet gadget configured on a micro SD card, a USB cable, and 7 jumper wires to flash and debug 4-wire JTAG MSP430 devices. The Pi Zero might be the lowest-cost 4-wire MSP430 JTAG debugger available! $ sudo ./mspdebug -j -d "tdi=3 tdo=2 tms=4 tck=17 rst=22 tst=27" gpio MSPDebug version 0.24 - debugging tool for MSP430 MCUs Copyright (C) 2009-2016 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.3.1.4 Copyright (C) 2013 TI, Inc. gpio tms= 4 gpio tdi= 3 gpio tdo= 2 gpio tck= 17 gpio rst= 22 gpio tst= 27 Starting JTAG JTAG_power on JTAG_connct led green JTAG ID: 0x89 Chip ID data: ver_id: 49f4 ver_sub_id: 0000 revision: 01 fab: 40 self: 0000 config: 00 Device: MSP430F44x Available commands: ! fill power setwatch_r = gdb prog setwatch_w alias help read simio blow_jtag_fuse hexout regs step break isearch reset sym blow_jtag_fuse hexout regs step break isearch reset sym cgraph load run verify delbreak load_raw save_raw verify_raw dis md set erase mw setbreak exit opt setwatch Available options: color gdb_default_port enable_bsl_access gdb_loop enable_fuse_blow gdbc_xfer_size enable_locked_flash_access iradix fet_block_size quiet Type "help <topic>" for more information. Use the "opt" command ("help opt") to set options. Press Ctrl+D to quit. (mspdebug) prog fet440_1.c.hex led green Erasing... led red led red Programming... Writing 74 bytes at 1100... led red led red Writing 32 bytes at ffe0... led red led red Done, 106 bytes total (mspdebug)
  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 that the mass erase failed. $ mspdebug -d /dev/ttyUSB0 --bsl-entry-sequence="Dr,R,r,R,r,d,R:Dr,dr," --long-password flash-bsl MSPDebug version 0.24 - debugging tool for MSP430 MCUs Copyright (C) 2009-2016 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.3.1.4 Copyright (C) 2013 TI, Inc. flash_bsl: unknown unknown error flash_bsl_erase: failed to send erase command flash_bsl_unlock: warning: erase failed flash_bsl: unknown unknown error flash_bsl_unlock: send password failed I also tried the python msp430-bsl.py utility, after making a few changes to run in my python environment, but it also failed. It at least seemed to sync successfully. I see more traffic on the BSL transmit and receive lines before they stop pulsing. In both cases, the BSL transmit pulses seem to stop when the TEST pin goes high. Could it be that the flasher tools need to hold the TEST pin low until all BSL activity is completed? $ ./msp430-bsl.py --port=/dev/ttyUSB0 --invert-reset -eEvvvV fet120_wdt_01.c.hex Debug is False Verbosity level set to 4 Python version: 2.7.12 (default, Jun 28 2016, 08:31:05) [GCC 6.1.1 20160602] pySerial version: 3.1.1 action list: mass_erase() erase_check_by_file() verify_by_file() reset() 2016-11-05 15:22:55,546 Opening serial port '/dev/ttyUSB0' 2016-11-05 15:22:55,568 ROM-BSL start pulse pattern Erase check by file... Erase check segment at 0xe000 68 bytes Erase check segment at 0xffe4 4 bytes Erase check segment at 0xffea 12 bytes Erase check segment at 0xfffc 4 bytes Erase check by file: OK Verify by file... Verify segment at 0xe000 68 bytes An error occurred: verify failed at 0xe000 Cleaning up after error... 2016-11-05 15:22:56,821 closing serial port [Edit: here's what a successful run looks like.] $ mspdebug -d /dev/ttyUSB0 --long-password rom-bsl MSPDebug version 0.24 - debugging tool for MSP430 MCUs Copyright (C) 2009-2016 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.3.1.4 Copyright (C) 2013 TI, Inc. BSL version is 60.01 Performing mass erase... Sending password... Chip ID data: ver_id: 3212 ver_sub_id: 0000 revision: 10 fab: 40 self: 0000 config: 00 Device: MSP430F12x2/F11x2 Available commands: ! fill power setwatch_r = gdb prog setwatch_w alias help read simio blow_jtag_fuse hexout regs step break isearch reset sym cgraph load run verify delbreak load_raw save_raw verify_raw dis md set erase mw setbreak exit opt setwatch Available options: color gdb_default_port enable_bsl_access gdb_loop enable_fuse_blow gdbc_xfer_size enable_locked_flash_access iradix fet_block_size quiet Type "help <topic>" for more information. Use the "opt" command ("help opt") to set options. Press Ctrl+D to quit. (mspdebug) prog fet120_wdt_01.c.hex Erasing... Programming... Writing 68 bytes at e000... Writing 4 bytes at ffe4... Writing 12 bytes at ffea... Writing 4 bytes at fffc... Done, 88 bytes total (mspdebug) Now, the only issue I'm running into is that my MSP430F1232 firmware won't run until I change the DTR status. I use the following python program to get my firmware to run, but it halts again once the 10s sleep is done. Is there any way to tell Linux to leave this pin in the proper state? [Edit 2: after a reboot, I no longer have to do this. Curious why.] #!/usr/bin/env python import serial import time s = serial.Serial('/dev/ttyUSB0') s.setDTR(False) time.sleep(10)
  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. jp430bb

    Act of god chip decapping.

    "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 a debugger for the CC2650STK, connectors notwithstanding? If so, I'd rather add an MSP432 LaunchPad to my collection.
  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 Motion Data come through with a 1000ms period, and then the Motion Data freezes.
  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; // ADS1118 chip select const int BUZZER = 2; // ADS1118 buzzer pin #define ADSCON_CH0 (0x8B8A) #define ADS1118_TS (0x0010) uint16_t ADS1118_config = (ADSCON_CH0 + ADS1118_TS) | 0x8000; void setup() { Serial.begin(9600); Serial.println("-+-+- RESET -+-+-"); SPI.begin(); SPI.setModule(2); SPI.setClockDivider(SPI_CLOCK_DIV64); // MSBFIRST is the default pinMode(BUZZER, INPUT_PULLUP); // initialize the ADS1118 pinMode(ADS1118_CS, OUTPUT); // initialize the LCD pinMode(LCD_RS, OUTPUT); pinMode(LCD_CS, OUTPUT); delay(2); writecom(0x30); // wake up writecom(0x30); // wake up writecom(0x30); // wake up writecom(0x39); // function set writecom(0x14); // internal osc frequency writecom(0x70); // contrast writecom(0x56); // power control writecom(0x6D); // follower control delay(2); writecom(0x0C); // display on writecom(0x01); // clear delay(5); writecom(0x06); // entry mode delay(10); } int counter = 0; void loop() { Serial.print("# loop "); Serial.println(counter++); // make a temperature reading // TODO: this doesn't work! digitalWrite(ADS1118_CS, LOW); delay(2); SPI.setDataMode(0); int msb = SPI.transfer(ADS1118_config >> 8); Serial.print(msb); // prints 128 every time Serial.print(" "); int lsb = SPI.transfer(ADS1118_config & 0xff); Serial.println(lsb); // prints 0 every time msb = (msb << 8) | lsb; int dummy = SPI.transfer(ADS1118_config >> 8); dummy = SPI.transfer(ADS1118_config & 0xff); digitalWrite(ADS1118_CS, HIGH); Serial.println(msb); // prints 32768 every time lcdMoveTo(0x00); // 1st line, 1st column if(counter % 2 == 0) lcdPrintChar(' '); else lcdPrintChar('+'); lcdPrintChar(' '); lcdPrintInt(msb); lcdMoveTo(0x40); // 2nd line, 1st column lcdPrintInt(counter); lcdPrintChar(' '); int now = millis(); lcdPrintInt(now); now = millis(); if(1000 - (now % 1000) > 100) sleep(1000 - (now % 1000)); else sleep((now + 1000) % 1000); } void lcdClear() { writecom(0x01); delay(2); } void lcdMoveTo(byte x) { writecom(0x80 + (x & 0x7f)); delay(1); } void lcdPrintInt(int x) { lcdPrintChar('0' + (x / 100000) % 10); lcdPrintChar('0' + (x / 10000) % 10); lcdPrintChar('0' + (x / 1000) % 10); lcdPrintChar('0' + (x / 100) % 10); lcdPrintChar('0' + (x / 10) % 10); lcdPrintChar('0' + x % 10); } void lcdPrintString(char *s) { while(*s != 0) { lcdPrintChar(*s++); } } void lcdPrintChar(char c) { writedata((byte)c); delay(1); } void writecom(byte d) { digitalWrite(LCD_CS, LOW); digitalWrite(LCD_RS, LOW); // LOW = command SPI.setDataMode(SPI_MODE3); SPI.transfer(d); digitalWrite(LCD_CS, HIGH); delay(1); } void writedata(byte d) { digitalWrite(LCD_CS, LOW); digitalWrite(LCD_RS, HIGH); // HIGH = data SPI.setDataMode(SPI_MODE3); SPI.transfer(d); digitalWrite(LCD_CS, HIGH); delay(1); }
  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 0 to 3 would interfere with JTAG. However, I couldn't see where my Energia sketch or the SPI library would be doing anything to those PORTC pins. I'm using SPI.setModule(2) to select the Stellaris SPI module which is connected to the proper pins for this Booster Pack. If I flash another Energia sketch which does not use the SPI library, then I can flash over and over again with lm4flash without disconnecting and reconnecting the USB cable. Can someone point me to the problem? Here's what I see if I do the flashing from a MinGW command line: $ # TI Stellaris ICDI/JTAG/SWD Interface driver 2.0.7922.0 $ # Windows 7, 64-bit $ # Just plugged in the Stellaris LaunchPad $ /c/energia-0101E0015/hardware/tools/lm4f/bin/lm4flash.exe -V LM4Flash version 0.1.3 - Flasher for Stellaris Launchpad ICDI boards Copyright (C) 2012 Fabio Utzig <fabio@[member="utzig"].net> Copyright (C) 2012 Peter Stuge <peter@stuge.se> This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ /c/energia-0101E0015/hardware/tools/lm4f/bin/lm4flash.exe -v Stellaris_ADS1118_2.cpp.bin Found ICDI device with serial: 0E1011C2 ICDI version: 9270 $ # completed quickly, no problem, sketch is running OK $ /c/energia-0101E0015/hardware/tools/lm4f/bin/lm4flash.exe -v Stellaris_ADS1118_2.cpp.bin Found ICDI device with serial: 0E1011C2 ICDI version: 9270 [output stops here for several seconds, unplug USB cable] Error receiving data -9 Error transmitting data -9 Error transmitting data -9 Error transmitting data -9 Error transmitting data -9 Error transmitting data -9 Error transmitting data -9 Error transmitting data -9 Error transmitting data -9 Error transmitting data -9 Error transmitting data -9 Error transmitting data -9 Error transmitting data -9 Error transmitting data -9 Error transmitting data -9 Error transmitting data -9 Error transmitting data -9 Error transmitting data -9 Error transmitting data -9 Error transmitting data -9 Error transmitting data -9 Error verifying flash Error transmitting data -9
×