Jump to content

Search the Community

Showing results for tags 'mspdebug'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • 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

Calendars

There are no results to display.


Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Location


Interests


Sparkfun


Github

Found 11 results

  1. I'm trying to bring up a CLI/Makefile based toolset under Ubuntu. Ubuntu version 17.04 MSPDebug version 0.24 My two Launchpads are both MSP-EXP430G2, Rev1.5, and are about three years old. One has a 2553 chip and the other is a 2452. Result of 'mspdebug --usb-list' includes: Devices on bus 001: 001:010 0451:f432 eZ430-RF2500 [serial: FEFF467AF9CB2548] Running mspdebug gives: randy@corvette: mspdebug/0.24$ ./mspdebug -U '001:010' rf2500 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. Trying to open interface 1 on 010 rf2500: warning: can't detach kernel driver: No data available Initializing FET... rf2500: can't send data: Resource temporarily unavailable fet: open failed Trying again... Initializing FET... rf2500: can't send data: Resource temporarily unavailable fet: open failed After I plug the Launchpad into USB, dmesg shows: [80373.763698] usb 1-9.3: USB disconnect, device number 10 [80387.054044] usb 1-9.3: new full-speed USB device number 11 using xhci_hcd [80387.363746] usb 1-9.3: New USB device found, idVendor=0451, idProduct=f432 [80387.363749] usb 1-9.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [80387.363751] usb 1-9.3: Product: Texas Instruments MSP-FET430UIF [80387.363752] usb 1-9.3: Manufacturer: Texas Instruments [80387.363753] usb 1-9.3: SerialNumber: FEFF467AF9CB2548 [80387.389816] cdc_acm 1-9.3:1.0: No union descriptor, testing for castrated device [80387.389829] cdc_acm 1-9.3:1.0: ttyACM0: USB ACM device [80397.690445] hid-generic 0003:0451:F432.000A: usb_submit_urb(ctrl) failed: -1 [80397.690462] hid-generic 0003:0451:F432.000A: timeout initializing reports [80397.696344] hid-generic 0003:0451:F432.000A: hiddev0,hidraw4: USB HID v1.01 Device [Texas Instruments Texas Instruments MSP-FET430UIF] on usb-0000:03:00.0-9.3/input1 I've installed and activated the udev rules in /etc/udev/rules.d/71-ti-permissions.rules This feels like a driver problem to me. I haven't been able to find any information on what drivers are used, just vague and unhelpful statements like 'if you are running a current version of Linux it probably has the correct drivers already installed.' I've tried running as root to bypass any permissions issues with no change in results. I've installed energia, it uses mspdebug for it's connection so it gives the same result. I've run out of things to try. The MSP430 is a nice processor to work with but if I can't get the tools to work I'll have to pick a different MCU. Thanks All Randy
  2. 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)
  3. [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)
  4. When I run mspdebug from the command line I get this failure: ____ Microsoft Windows [Version 6.0.6002] Copyright © 2006 Microsoft Corporation. All rights reserved. C:\Users\Mark>mspdebug You need to specify a driver. Try --help for a list. C:\Users\Mark>mspdebug rf2500 MSPDebug version 0.20 - debugging tool for MSP430 MCUs Copyright © 2009-2012 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. rf2500: failed to open RF2500 device. ____ But mspdebug can see the Launchpad: _______ C:\Users\Mark>mspdebug --usb-list Devices on bus 000: 000:000 0451:f432 eZ430-RF2500 [serial: 56FF42047150410A] C:\Users\Mark> ___________________________ Running testlibusb-win.exe gives me this: ___________ DLL version: 1.2.6.0 Driver version: 1.2.6.0 bus/device idVendor/idProduct bus-0/\\.\libusb0-0001--0x0451-0xf432 0451/F432 - Manufacturer : Texas Instruments - Product : MSP430 Application UART - Serial Number: 56FF42047150410A bLength: 18 bDescriptorType: 01h bcdUSB: 0110h bDeviceClass: 00h bDeviceSubClass: 00h bDeviceProtocol: 00h bMaxPacketSize0: 08h idVendor: 0451h idProduct: F432h bcdDevice: 0100h iManufacturer: 1 iProduct: 5 iSerialNumber: 3 bNumConfigurations: 1 wTotalLength: 53 bNumInterfaces: 1 bConfigurationValue: 1 iConfiguration: 0 bmAttributes: 80h MaxPower: 50 bInterfaceNumber: 0 bAlternateSetting: 0 bNumEndpoints: 3 bInterfaceClass: 2 bInterfaceSubClass: 2 bInterfaceProtocol: 1 iInterface: 5 bEndpointAddress: 82h bmAttributes: 03h wMaxPacketSize: 64 bInterval: 255 bRefresh: 0 bSynchAddress: 0 bEndpointAddress: 03h bmAttributes: 02h wMaxPacketSize: 64 bInterval: 255 bRefresh: 0 bSynchAddress: 0 bEndpointAddress: 83h bmAttributes: 02h wMaxPacketSize: 64 bInterval: 255 bRefresh: 0 bSynchAddress: 0 ______________ So it looks like libusb-win32 is installed right. It also looks right in Device Manager. This is on Vista64. The Launch pad has the 2553 installed but I backed up to the original chip that I had used under gdb in a previous msp430 tool chain I know worked, same error. The mspdebug I am using is from the pre compiled MSP chain XPG provides, just to limit the variables. I have tried forcing the serial number but that made no difference. Do I need another version of mspdebug than the current (0.20?) that's in the provided chain? Any ideas on what to do next? If there are any logs that would be useful in figuring this out just ask. After going back over the install several times and reading posts till my eyes are blurry I am still stumped. Help! Mark
  5. I'm trying to set up an eclipse / gcc / gdb / mspdebug based development environment to work on a custom msp430 based board that the company I work for produce. I have set up eclipse with the tools which come with ubuntu 15.04, and it's almost working apart from a weird bug in the debugger. When you watch a local variable in the main function, eclipse displays an incorrect value. This bug has been around for a while, as I've noticed it before (see this and the following page: http://forum.43oh.com/topic/1419-eclipse-plugin-for-mspdebug-and-msp430-gcc/page-3). The bug has been fixed in the most recent version of mspgcc from the old sourceforge site, but this is 2 years out of date now, and the development has moved to a project hosted by texas instruments: http://www.ti.com/tool/msp430-gcc-opensource . I would like to use the most recent version from ti if possible; I've tried compiling it and it builds OK, but I can't find a compatible libc and set of device specific header files which will work with it. When I try to use the libc that comes with ubuntu, it says it's incompatible. Also, when I pass the flag '-mmcu=msp430f5510', which used to work before, msp430-gcc throws an error. I've also noticed that the msp430 support appears to have been merged back into the upstream mspgcc (and presumably the other gnu tools), which is another way I've thought of going. So my question is, given all this, what's the best way to go to set up an up to date open source toolchain for the msp430? I could just compile the most recent version from the old sourceforge project, but would rather use something more up to date if that is possible.
  6. Hello all! If anyone else is interested in devops tools like ansible/vagrant/docker or linux administration this project might interest you. I recently started learning about ansible a tool used to configure/orchestrate servers. So I thought I would try and use that to push firmware updates out to MSP430s. I came up with a solution that allows me to run a command on my machine which then copies the firmware to Rapsberry Pis and then flashes any MSP430 LaunchPads connected to them. I first had to compile the msp430 dll and the latest version of mspdebug for the ARM architecture (rather than x86). Essentially this allows me to program MSP430s from a Raspberry Pi using mspdebug. I talk about the steps here: http://zacklalanne.me/automated-deployment-of-msp430-firmware-part1/ Then I wrote an ansible playbook to automatically deploy the dll and mspdebug as well as the firmware to the connected Raspberry Pis which then push the firmware to the MSP430s. http://zacklalanne.me/automated-deployment-of-msp430-firmware-part2/ Don't think this is too realistic for an actual production environment but getting it all to run was a good learning exercise in compiling code on linux and system administration.
  7. Hello all, I am trying to use mspdebug with Olimex MSP430-JTAG-ISO-MK2 on Ubuntu 14.04 and it is extremely slow, takes 3 minutes progragram ~80K. The MSP-FET430UIF takes less then 30 seconds to program the same application. Is there something that I am doing wrong? Thanks...
  8. Hello everebody. I am new in this field and i cannot connect msp430f5529LP with mspdebug. This is my code: $ dmesg ..... [ 5799.999208] usb 1-2: new full-speed USB device number 8 using xhci_hcd [ 5800.015833] usb 1-2: New USB device found, idVendor=0451, idProduct=2046 [ 5800.015842] usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 5800.016156] usb 1-2: ep 0x81 - rounding interval to 1024 microframes, ep desc says 2040 microframes [ 5800.016464] hub 1-2:1.0: USB hub found [ 5800.016570] hub 1-2:1.0: 4 ports detected [ 5800.571488] usb 1-2.2: new full-speed USB device number 9 using xhci_hcd [ 5800.591067] usb 1-2.2: New USB device found, idVendor=2047, idProduct=0013 [ 5800.591075] usb 1-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 5800.591079] usb 1-2.2: Product: MSP Tools Driver [ 5800.591082] usb 1-2.2: Manufacturer: Texas Instruments [ 5800.591085] usb 1-2.2: SerialNumber: 644F0C4716002000 [ 5800.591367] usb 1-2.2: ep 0x81 - rounding interval to 1024 microframes, ep desc says 2040 microframes [ 5800.591406] usb 1-2.2: ep 0x83 - rounding interval to 1024 microframes, ep desc says 2040 microframes [ 5800.592584] cdc_acm 1-2.2:1.0: This device cannot do calls on its own. It is not a modem. [ 5800.592631] cdc_acm 1-2.2:1.0: ttyACM0: USB ACM device [ 5800.593641] cdc_acm 1-2.2:1.2: This device cannot do calls on its own. It is not a modem. [ 5800.593694] cdc_acm 1-2.2:1.2: ttyACM1: USB ACM device and biotin@debian:~/mikro$ mspdebug --usb-list Devices on bus 004: 004:002 8087:0024 004:001 1d6b:0002 Devices on bus 003: 003:004 0489:e056 003:003 0bda:0129 [serial: 20100201396000000] 003:002 8087:0024 003:001 1d6b:0002 Devices on bus 002: 002:001 1d6b:0003 Devices on bus 001: 001:009 2047:0013 001:008 0451:2046 001:003 04f2:b33b 001:002 046d:c52f 001:001 1d6b:0002 biotin@debian:~/mikro$ connect attempt with debugger: 1) biotin@debian:~/mikro$ mspdebug uif -d /dev/ttyACM1 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. Trying to open /dev/ttyACM1 at 460800 bps... Initializing FET... comport: read error: Connection timed out fet: open failed Trying again... Initializing FET... comport: read error: Connection timed out fet: open failed biotin@debian:~/mikro$ 2) biotin@debian:~/mikro$ mspdebug rf2500 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. usbutil: unable to find a device matching 0451:f432 3) biotin@debian:~/mikro$ 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. tilib: can't find libmsp430.so: libmsp430.so: cannot open shared object file: No such file or directory Which driver is Correct? What is wrong? With Energia everything is ok. Thank you guys.
  9. I received my MSP-FET yesterday-- thank you TI! I was so excited to try out everything. I was deflated to find out that my package only contained the programmer-- hopefully the target board and MSP430FR6989s will arrive soon. It almost felt like Christmas morning-- only to find out the batteries were not included! I wanted to test out my new toy so I hooked up the MSP-FET to some MSP430 chips I hand nearby. I hooked up the MSP-FET to a MSP430G2231 and started Energia on Mac OS X 10.9.4. Although the MSP-FET is seen by the OS, I can't seem to connect to it. On System Info, the vendor/product ID are 0x2047/0x0014 with a description of "MSP Tools Driver." Here are my issues 1) Energia can't connect. If I use File -> Upload, or File -> Upload using programmer, I get "usbutil: unable to find a device matching 0451:f432" 2) If I use mspdebug, I can't connect using tilib or uif. $ mspdebug --usb-list Devices on bus 250: 250:006 2047:0014 [serial: EFF2blahblah] 250:005 05ac:0245 250:002 0424:2513 250:001 05ac:8006 Devices on bus 253: 253:001 05ac:8006 $ 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 No unused FET found. $mspdebug uif 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. usbutil: unable to find a device matching 0451:f430 I tried specifying the USB device by adding -U 250:006 but no improvement. Does mspdebug v 0.22 not work with the MSP-FET? Is this a libmsp430.so issue? I was using the one supplied with the latest version of Energia (E0013). 3) If I run CCS6 under VirtualBox, things sort of work. When I start a debug session, I get a message "Error initializing emulator: A firmware update is required for the MSP430 Debug Interface (MSP-FET430UIF / MSP-FET / eZ-FET). Click the "Update" button to update the firmware and launch your debug session (this may require several update steps). DO NOT UNPLUG THE INTERFACE DURING THE UPDATE." If I click UPDATE, the MSP-FET gets bjorked. Probably because of the way virtualbox hands off USB devices between host and guest OSs. I am thinking the USB VID and/or PID are being altered during the update. Regardless, things don't work afterwards and I can't seem to unbjork things without using a physical Windows computer running CCS6. The physical WIndows computer can update the MSP-FET firmware. Curious thing is that after updating the firmware, CCS6 running on virtualized Windows, still wants to upgrade the firmware with the same message above. If on the other hand, I choose the button to IGNORE the firmware update, things start OK and I can start a debug session. Problem is that sometimes I get a error message "MSP430: Trouble Halting Target CPU: Internal error." Things don't work so well afterwards but nothing that a unplug, replug won't fix. 4) I know the MSP-FET is working OK because if I use it on a physical Windows machine, I can program a device, set breakpoints, stop/resume, see energy usage, etc. It works flawlessly. It's a bit disappointing I can't seem to get it to work with mspdebug or virtualized Windows running CCS6.
  10. I'm currently working on cross platform build tool named PlatformIO. It has pre-built MSP430 GCC toolchain & mspdebug for Mac, Linux 32/64 & Windows OS. 1. How often do you use external standalone toolchain to build your code? In which case? 2. What is your favourite IDE+Toolchain? 3. What would you like to have in paltformio tool? Thanks a lot for answers! P.S: The main idea of this tool is to compile code with different platforms. See Wiring Framework (Arduino + Energia) Blink Example.
  11. Hello, I am using mspgcc to develop code and mspdebug to load to mcu. Now, I am trying to debug some code, and it seems to me that it is very hard to step through lines of code and set breakpoints on C code with mspdebug and console. I was wondering if there is a way to debug the mcu with some kind of debugging software with a UI such as the Hi-wave debugger. I would love to be able to develop my code using gVim and if possible also debug it with gVim. Thanks
×