Jump to content

freshfeesh

Members
  • Content Count

    1
  • Joined

  • Last visited


Reputation Activity

  1. Like
    freshfeesh reacted to Rickta59 in 1K serial gdb_bootloader   
    Inspiration:
    So I'm looking at making a small msp430fr5739 based board. I was thinking that I would be able to use the msp430 launchpad to program them. However, I hit a snag in that they don't seem to recognize the msp430fr5739 as a valid device. I can use my FRAM boards to program them but not the $10 launchpad. Then there was all the hubbub about the new msp430g2955 chips and it got me thinking. Why should I let Texas Instruments determine how I program my chips?

    Investigation:
    I got to looking at BSL and then got discouraged trying to find a client that works on windows, linux and OSX. It mostly seemed like it was going to be a hassle. Then I got to thinking about just using GDB and its Remote Serial Protocol. If you use msp430-gdb and mspdebug, you use this interface over a local server socket. However, an often unnoticed feature of this protocol is that it can also be used with a regular serial port.

    Solution:
    I decided to implement a gdb stub server that you load once on your msp430 chip. You can think of it as a bootloader that happpens to use the Remote Serial Protocol. This allows you to load new programs on that chip without the need for a launchpad or an FET. All you need is a usb->serial port dongle. You can find these on ebay from $2-$10. They all go faster than the 9600 baud the virtual serial port the msp430 launchpad provides. It is likely you probably have one of these already. This scheme doesn't allow you to debug using msp430-gdb, but it does provide a way to load new code without having to deal with BSL or having to write any host side code.

    How it works:
    This version targets the msp430g2553 so that people can easily try it out. I'm guessing that most people don't have an msp430fr5739.  Load the attached code below to an msp430g2553 using your launchpad one time. At this point, you could remove that chip from your launchpad and throw it on a breadboard. You just need power, the caps and a pull up resistor. Then connect TX and RX to a serial to USB converter (ftdi, cp102, pl2303hx, etc..). For simplicity, we can just test with the launchpad itself and ignore the fact that there is an FET on the board and just use /dev/ttyACM0 or COM1: on windows.

    At reset time, the code looks at the state of the P1.3 button on the msp430g2553. If you are holding it down, the code starts a gdb bootload/server running on the msp430g2553. On your linux box, just start up msp430-gdb to connect to the chip over a serial port. You can't debug, but what you can do is erase your flash and load a new program. The gdb server code sits at memory 0xfa00 -> 0xfdff so you do lose some of your flash. *I've done some optimization see later posts in this thread *


    Loadable hex file:
    The gdb_bootloader.hex file from the zip file must be loaded on an msp430g2553. I'll post code and support for other chips at a later date. I'm excited about this concept and wanted to let people try it out.

    To load the gdb_stub firmware ( do this one time )
    $ mspdebug rf2500 "prog gdb_bootloader.hex" MSPDebug version 0.21 - debugging tool for MSP430 MCUs Copyright (C) 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. Trying to open interface 1 on 057 rf2500: warning: can't detach kernel driver: No data available Initializing FET... FET protocol version is 30066536 Set Vcc: 3000 mV Configured for Spy-Bi-Wire fet: FET returned error code 4 (Could not find device or device not supported) fet: command C_IDENT1 failed fet: identify failed Trying again... Initializing FET... FET protocol version is 30066536 Set Vcc: 3000 mV Configured for Spy-Bi-Wire Sending reset... Device ID: 0x2553 Code start address: 0xc000 Code size : 16384 byte = 16 kb RAM start address: 0x200 RAM end address: 0x3ff RAM size : 512 byte = 0 kb Device: MSP430G2553/G2403 Number of breakpoints: 2 fet: FET returned NAK warning: device does not support power profiling Chip ID data: 25 53 Erasing... Programming... Writing 970 bytes at fa00... Writing 32 bytes at ffe0... Done, 1002 bytes total OK. Once you have that installed, you no longer need to use your launchpad to load new code. To load programs on your chip now, just connect a usb->serial dongle up to the msp430g2553 directly and connect to that via msp430-gdb. Here are the steps to load a blink program using msp430-gdb via the serial port:
    $ msp430-gdb blink.elf GNU gdb (GDB) 7.2 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=msp430". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home2/kimballr/github/msp430_code/fabooh/examples/basic/blink/blink.elf...done. (gdb) set remotebaud 9600 (gdb) target remote /dev/ttyACM0 Remote debugging using /dev/ttyACM0 _reset_vector__ () at ../../../gcc/gcc/config/msp430/crt0.S:103 103 ../../../gcc/gcc/config/msp430/crt0.S: No such file or directory. in ../../../gcc/gcc/config/msp430/crt0.S (gdb) erase Erasing all flash memory complete (gdb) load Loading section .text, size 0x96 lma 0xc000 Loading section .vectors, size 0x20 lma 0xffe0 Start address 0xc000, load size 182 Transfer rate: 264 bytes/sec, 16 bytes/write. (gdb) quit A debugging session is active. Inferior 1 [Remote target] will be killed. Quit anyway? (y or n) y OK, now there are two things on your msp430g2553 chip. At 0xfa00 there is the boot loader, it is run first before your blink.elf code. It checks the button to see if you are holding it down. If not, then it runs the blink.elf code. If you are holding it down, it runs the gdb server instead and allows you to reload code. So just press reset to start the blink. Press and hold the P1.3 switch down and press reset to start the gdb stub server.

    Pretty simple huh? I think so.

    -rick

    The files in the attached zip only work with the msp430g2553 at this time:

    [Edit: Updated version 04-07-2013 3:43 PM]


    Source Code:
    ... fast track to how to get started ...

    http://forum.43oh.com/topic/3661-1k-serial-gdb-bootloader/?p=33112

    I'm actively optimizing this code. I only started on this project on Thursday and posted what I had late Friday. It was 1950 bytes the first pass. But I was so excited about this concept, I just had to share. Saturday, I spent the day on it and got the code size down to less than 1k.

    The code is written in C++ using my fabooh framework. I've been trying to find a good app to use as the fabooh debut project. I think this will be it. This type of code needs to be small but needs the flexibility to use various UART implementations. This code personifies what fabooh does well. So expect to see it real soon now, in the fabooh source tree.

    You can get yourself in a good position to use this code if you grab fabooh from github.com and take a look at it. https://github.com/RickKimball/msp430_code
  2. Like
    freshfeesh reacted to ivanc in Scan Interface Applications - Five Members Win A Target Board And An MSP-FET   
    @@chicken
     
    Your high level description of the ESI module is spot on. I will like to add my two cents to the description.
     
     
    Each AFE has two types of inputs (ESICIx and ESICHx), The main difference is that with ESICHx you can excite sensors (AFE1 and AFE2 use the same excitation logic)  and ESICIx inputs are not connected to the excitation logic.
     
     
    In addition to ACLK, SMCLK or 32KHz oscillator you can also use ESICLK which has a nominal frequency of 4.8 MHz but can be tunned to operate between 2.3 -7.9 MHz in ~78 KHz increments. Also, the ESI module allows you to divde your low frequency clock source by a wide number of dividers (refer to Table 28-25 in SLAU367)
     
     
    Correct, you can program up to 127 states and the state transition are driven by output of PPU(PPUS1, PPU2,PPUS3) and bit Q6. Note: if you are using PPUS3 and bit Q6 for next PSM state transition you need to properly configure the ESIPSM register for such operation.
  3. Like
    freshfeesh reacted to Foghorn in Scan Interface Applications - Five Members Win A Target Board And An MSP-FET   
    I must admit that this peripheral looks like a jack-of-all-trades kind. It's like an ADC, DMA, Comparator, Timer, and Processor all rolled into one.
     
    From what I gather, what makes this peripheral extra special is its configurable state machine.
     
    Correct me if I'm wrong, but this peripheral seems to act "generally" in this way:
    1) Takes an ADC sample.
    2) Stores it in dedicated RAM.
    3) Configured state machine processes that data and stores results. Sets up for the next measurement.
    4) State machine may or may not check/change its timer running in capture mode depending on the measurements being taken.
    5) May generate Interrupt.
    6) Repeat
     
    A lot of this can be easily replicated in software by lots of microcontrollers, but the advantage of this peripheral is that all of the sampling and processing takes place in the background without processor intervention and allows the processor to sleep longer and save more power.
     
    So, the ultimate benefit of this peripheral is to save power in applications that requires the processor to supervise the measurement-taking process. This is especially important in battery applications that require constant measurement taking.
     
    I can see why some of the applications would be flow metering and fitness tracking (they both require lots of measurements).
     
    My submission for this contest would be battery-powered auto-balancing applications. Auto-balancing requires constant sampling of motion sensors and sometimes combines optical data to aid in balancing by detecting the distance of a sensor relative to the ground. If the auto-balancing device moves, a quadrature encoder's velocity data would supplement the acceleration data of an accelerometer and angular velocity of a gyroscope. 
  4. Like
    freshfeesh reacted to chicken in Scan Interface Applications - Five Members Win A Target Board And An MSP-FET   
    @@Foghorn that's what I mean, my interpretation is a bit different
     
    two analog front ends (AFE) with multiple inputs, a few outputs to stimulate sensors, and a multiplexer/DAC/comparator combo to compare inputs to a given voltage, including programmable hysteresis the binary result of the comparator can either drive a timer or be further processed by the ESI a pre-processing unit (PPU) that can store sequences of comparator results a timing state machine (TSM) that is programmed with a timed sequence of up to 32 states that controls AFE, PPU and PSM (see 6), e.g. which input to compare to what value when and what to pass on to PPU, timer or PSM the TSM can be driven by ACLK, SMCLK or external 32KHz oscillator, enabling operation in most (all?) LPM modes a processing state machine (PSM) that is programmable with up to 127(?) states, with state transitions driven by output of the PPU the PSM controls three 16bit counters and can raise MCU interrupts when a certain state is reached Once TSM and PSM are programmed, the above runs independent of the MCU There is no ADC, only sample-and-hold logic before the comparator. Your balancing project will have to work with comparator thresholds (DAC values) instead of numbers and math.. which might be perfectly viable.
     
  5. Like
    freshfeesh reacted to pkowalski in MultiSerial Example Not working   
    Hello,
     
    I am just getting started with the MSP-EXP430G2 development board so that I can use it for a project. For this project I need to receive/send serial commands on one port and then send/receive them on another. I pulled up the MultiSerial example to get me a quick example and I get an error when trying to compile:
     
     
  6. Like
    freshfeesh reacted to abc in What is Energia from cpp perspective?   
    Hi,
     
    I am sorry if this has been answered elsewhere. 
     
    My understanding is that Energia is a combination of the following:
     
    1) an IDE 
     
    2) a run-time library (digitalWrite, Serial, etc.)
     
    4) a directory convention
     
    5) a simple preprocessor that 
        5.1. merges files that don't have an extension;
        5.2. adds #include statements (but apparently not all?)
     
    3) a very simple harness that goes like this and, I think, turns Energia from a library into a framework:
    int main(void) { init(); setup(); for (; { loop();   if (serialEventRun) serialEventRun(); } return 0; } 4) a coding convention which simplifies C++ programming (while allowing plain C++)
     
    5) a makefile that builds all that.
     
    Did I get that right? And if I did - is it possible to use Energia just as a a run-time library? I.e with my own main(). 
×
×
  • Create New...