Search the Community

Showing results for tags 'bsl'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • News
    • Announcements
    • Suggestions
    • New users say Hi!
  • Spotlight!
    • Sponsor Spotlight
    • Sponsor Giveaways
  • Energia
    • Energia - MSP
    • Energia - TivaC/CC3XXX
    • Energia - C2000
    • Energia Libraries
  • MSP Technical Forums
    • General
    • Compilers and IDEs
    • Development Kits
    • Programmers and Debuggers
    • Code vault
    • Projects
    • Booster Packs
    • Energia
  • Tiva-C, Hercules, CCXXXX ARM Technical Forums
    • General
    • SensorTag
    • Tiva-C, Hercules, CC3XXX Launchpad Booster Packs
    • Code Vault
    • Projects
    • Compilers and IDEs
    • Development Kits and Custom Boards
  • Beagle ARM Cortex A8 Technical Forums
    • General
    • Code Snippets and Scripts
    • Cases, Capes and Plugin Boards
    • Projects
  • General Electronics Forum
    • General Electronics
    • Other Microcontrollers
  • Connect
    • Embedded Systems/Test Equipment Deals
    • Buy, Trade and Sell
    • The 43oh Store
    • Community Projects
    • Fireside Chat
  • C2000 Technical Forums
    • General
    • Development Kits
    • Code Vault
    • Projects
    • BoosterPacks


There are no results to display.

Found 7 results

  1. I have a G2553 set up on a breadboard, and am using a USB-to-UART adapter for BSL flashing. TI provides BSLDEMO2.exe on the Windows side to do the flashing, but I've been unable to get it to work. If I use the special signalling pattern on /RST and Test, I get a "synchromization failed" error, and if I boot directly into the cold start vector of BSL, I get a "communications error". So I just wondered if anyone here has actually done this successfully? The two ends talk to each other, but it always errors out.
  2. [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 <> 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 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? $ ./ --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 <> 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)
  3. Why on earth would TI engineers use random GPIO pins for the built-in UART BSL instead of RXD/TXD of one of the USCI peripherals?? I mean, in 90% of real world use cases, the likely source of a firmware update, i.e. computer, USB bridge, blue-tooth modem etc., will be hanging on one of the UARTs. Instead they picked 2 pins on the side of the package where all the I/Os are nicely lined up and which therefore most likely would be wired up to all the other stuff. Oh yes, and of course those two pins are exactly on the opposite side of the TEST / BSL enable pin. /rant
  4. Hello all, I have been trying to understand the importance of the BSL. From the TI doc, "Programming with the BSL" I realize that BSL is used to access Memory, during the different phases of the controller. My question is: why do we need this BSL? is it required to calibrate the controller? like setting the temperature and operating conditions, before the controller takes the program execution address from the reset vector? Generally, from my understanding and usage: we used the JTAG, FET tool to download the code onto the controller, to debug the code. Then why do we need the BSL? Thanks a lot for sharing your experiences! Vin43
  5. Hi, We need some advice on updating MSP430F5529 program using USB BSL. We want to add/update a small part of data to the current firmware through USB BSL. But the problem is the BSL automatically performs a mass erase, TI's Appl note(SLAA452B) mentions that the BSL password reside at addresses 0xFFE0 to 0xFFFF which changes for every new program and fixing the ISR locations solves the problem of MASS Erase. But we don't know how exactly do we Fix the ISR locations. Could you please let me know if there is a reference or example on how to Fix the MSP430 ISR locations. Regards Paddu
  6. Hi - I've been trying to find the source of the RF-BSL used by the Chronos watch - probably looking in the wrong place as I'm a bit new to this... Anyone know if it was released and if so, where can I find it? (the source, that is...) Thanks Nick
  7. hey people, i am new to the msp430 family and, as the title reads, i am trying to program a simple blinky bin(txt) created with ccs on a g2955. here is the catch, i dont have access to any of the regular tools you guys use(fets and stuff), because of where i live. in fact im using the 430 because of TI`s very generous sample program. i am using a com to 3v3 adapter similar to this one but im having a hard time finding software to do the upload. i read this post where it says that its possible to do with mspdebug. thing is i could not compile it on ubuntu (i get a 404 when trying to install libusb-dev dont know why) and even compiled it under win7 but i dont know how to specify a device when unsing the -d option to use BSL. if anyone can shed any light on this, or point me in the right direction, it would be greatly appreciated. thanks!