Jump to content

Search the Community

Showing results for tags 'debug'.

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.

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



Website URL





Found 14 results

  1. Hi Everybody, I've been developing some code on Linux using CCSV7.2 and I already know that CCS will not program the g2553 like it would on a Windows box. But, I know that you guys are clever! How have you been programming and debugging the g2553 on Linux these days? Are you using a different LaunchPad and hot wiring it over to the G2553 LaunchPad?
  2. Hello all! So, this is happening on BOTH my Ubuntu 16.04 AND Windows 8.1 systems. This is for a TM4C1294NCPDT. To reduce potential variables, I've reverted to using the EK-TM4C1294XL Development Board. To reproduce: Fresh install of CCSv7.1, Fresh install of Energia 18. Open CCSv7, Create a new workspace, select 'Project > New Energia Sketch', Energia Version set to 18, select 'Built-in Examples > 01.Basics > Blink.ino', selected device: 'LaunchPad (Tiva C) w/ tm4c129 (120MHz), select 'Finish'. Right Click 'Blink" project in the Project Explorer, select "Build Project'. Project builds fine. Push F11 (or select 'Debug Blink' from the toolbar). Code is uploaded, but the debug 'Resume' button is grayed out. LED does not blink. Note: 'Blink' runs fine in the Energia IDE itself. What happened in the update to CCSv7? I'm taking a shot in the dark here, but I think the memory map is b0rked. If I disable "On a program load or restart" in the 'Debug > Auto Run and Launch Options' and then attempt to debug, CCS starts the debugger at "void ResetISR(void) {" in startup_gcc.c. See attached image for disassembly view. I think (IIRC) that the two ldr calls in assembly are usually right below that 'push', but my memory ain't what it used to be. Anyhow, if I try to 'Step Into' with F5, I immediately get a dreaded "No source available for "0xfffffffe" ... So, any idea what the hell happened? This shoots me dead until this is resolved... I figured TI would at least test Energia GCC debugging before releasing v7, though I do tend to err with my assumptions quite often. If you need anything, just holler. EDIT: For posterity, here's my TI E2E forum post on the same: https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/586137
  3. Hi, I needed a way to see how much of my C++ stack was being consumed in my MSP application - the traditional way is to "poison" the stack with a known pattern, and then to see how much of it gets burnt away. So I wrote the following - hope folk find it useful: The following code allows you to simply do this and to check at any point how much of the pre-allocated stack was consumed during peak usage, i.e. how close your app got to the bottom of the stack, or indeed, whether it over-ran. The TI CCS documentation is completely wrong in the names it gives for the global symbols that define the size and start of the stack - needs to be updated, Stick this code (or similar) wherever you want to report on/check stack usage <smallest number of byes left free on the stack since initialisation>/<configured size of the stack>. #if defined(STACK_CHECK) std::printf( "Stack: %d/%d\n", stackMinFreeCount(), stackMaxSize() ); #endif and then, in your main code you need to poison the stack as early as possible and then define the reporting routines: // Define STACK_CHECK to include stack usage diagnostics #define STACK_CHECK #if defined(STACK_CHECK) #define STACK_INIT 0xBEEF // Pattern to use to initially poison the stack extern uint16_t _stack; // Start of stack (low address) uint16_t stackMinFreeCount(void); uint16_t stackMaxSize(void); #endif #if defined(__cplusplus) extern "C" { #endif #if defined(__TI_COMPILER_VERSION__) || \ defined(__GNUC__) int _system_pre_init( void ) #elif defined(__IAR_SYSTEMS_ICC__) int __low_level_init( void ) #endif { //... stuff... #if defined(STACK_CHECK) // // Poison the stack, word by word, with a defined pattern // // Note that _system_pre_init is the earliest that we can // do this and that it may not be possible in TI-RTOS // // When we call the __get_SP_register intrinsic (same on IAR & CCS), it will return the address // of the RET address for the caller of this routine. Make sure that we don't trash it!! // register uint16_t *stack = &_stack; // Address of lowest address in .stack section register uint16_t *stack_top = reinterpret_cast<uint16_t *>(__get_SP_register()); do { *stack++ = STACK_INIT; // Poison stack addresses } while (stack < stack_top); // Stop before top of stack to leave RET address #endif return 1; } #if defined(__cplusplus) } #endif #if defined(STACK_CHECK) /** * Check how deep the stack usage has been * * \return \c uint16_t Minimum number of bytes to bottom of stack */ extern uint16_t __STACK_END; // End of data extern uint16_t __STACK_SIZE; // Linker-set size of stack uint16_t stackMinFreeCount(void) { const uint16_t *stack = &_stack; uint16_t freeCount = 0; while (*stack == STACK_INIT && stack++ <= &__STACK_END) { freeCount++; } return freeCount << 1; } /** * Return size of C++ stack * * Set by the linker --stack_size option * * \return \c uint16_t Configued maximum size of the stack in bytes */ uint16_t stackMaxSize(void) { return static_cast<uint16_t>( _symval(&__STACK_SIZE) ); } #endif int main(void) { ... stuff #if defined(STACK_CHECK) std::printf( "Stack: %d/%d\n", stackMinFreeCount(), stackMaxSize() ); #endif ...stuff }
  4. Good morning. I've been using the MSP430 launchpad and programming it using Energia 18. Anyway, for the whole time I've been using Energia, it very often have to unplug and plug back in my device in order to send it another build. Have any of you seen this problem before? Sometimes it works without having to unplug the hardware, however, over 50% of the time, I have to unplug the LaunchPad in order to upload new code to it from Energia. It seems to get hung while attempting the upload. So, to overcome this, I unplug the Launchpad, click the Upload button again, usually get an error, so I click Upload again and then it seems to start working. Another problem I've been having is that half the time, the Serial Debug output window doesn't show any output. I usually have to close it and re-open it in order to see the output. Also, sometimes, it just doesn't show any output no matter how many times I close and re-open it. Is this just me, or is it a bit iffy with the debug window and the upload? I'm doing all this on a Windows 8 box and have the latest Energia 18 on it. Any ideas to make it so I don't have to keep on unplugging/plugging in my device with each upload? Thanks much, Curtis
  5. Hi All, A few days ago we release a new version of the free Visual Micro plugin for Energia 0014 and Visual Studio 2013 Community Edition. Currently build and upload appears to work identically to the Energia Ide but it would be useful for others to test. One windows users report the upload not working which we guess is related to the start path that Visual Micro uses when running the upload command. It would be really useful for a few others to test especially with the cc3200. http://www.visualmicro.com/ Here is a screen-shot from earlier Energia releases in Visual Studio 2010. We will make some new screen shots for 0014 and VS2013 as soon as we get the thumbs up from a few users. Some historic notes from earlier Energia releases are here http://www.visualmicro.com/post/2013/08/02/Energia-Getting-Started.aspx Your help will really be appreciated. Either in this forum or in the Visual Micro forum. Thanks The Visual Micro Team
  6. Hi, I am trying to learn debugging Stellaris launchpad using gcc. I am using the GCC arm embedded toolchain. And I am trying to debug the blinky example project in the stellarisware. But GDB complains that it can't find the debuggin symbols. I have tried defining the symbol "DEBUG" in the source code, but that failed. Please tell me how I can fix this issue? Akhils-MacBook-Pro:blinky akhil$ arm-none-eabi-gdb gcc/blinky.axf GNU gdb (GNU Tools for ARM Embedded Processors) Copyright (C) 2013 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=x86_64-apple-darwin10 --target=arm-none-eabi". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /Users/akhil/work/blinky/gcc/blinky.axf...(no debugging symbols found)...done.
  7. Hi all, I am trying to debug the bootloader example in eclipse with the jlink debugger. And I am not sure about how to configure the jlink plugin in eclipse correctly, where to point the stack and the pc register due to the fact that the gcc linker script uses the VMA and the LMA for the sections and the bootcode is copied into RAM in the reset handler. The download seems to work correctly, but breakpoints are not reached correctly. I would like to start debugging at the beginning in the assembler code, to see the first steps of copying the bootloader code into RAM. Is it possible to debug assembler code at this stage (in the reset handler) at all? In the debugger plugin in eclipse I choose to break e.g. in ResetISR, but it stops somewhere else. Can anyone give me a hint what I am doin wrong, how to correctly setup the debugger for this project? Thanks in advance, Andreas
  8. Hi 43oh folks! I wrote a quick blog post & tutorial on the www.energia.nu website. I wanted to walk through the process of setting up Code Composer Studio v6 to enable Energia sketch imports. This is a cool new feature that takes full advantage of the on-board hardware debugger that is available on our LaunchPad kits & allows developers to go beyond Serial.print(). This provides a nice migration path from Energia to CCS. Energia is great for rapid prototyping, but there are times when a true debugger could be helpful. With CCSv6, we can now import Energia sketches & get full debug features such as: - Hardware breakpoints - Watching variables - Stepping through code line-by-line - More! You can see my blog post & tutorial @ http://energia.nu/go-beyond-serial-print-put-the-launchpads-on-board-debugger-to-work-import-energia-sketches-into-ccsv6/ Thanks! Adrian
  9. Hi all, I use TI's Debug Interface Box MSP-FET430UIF with a MSP430G2252. On the spy Bi wire I/O line is the High and Low level of the data. What I cannot understand is, why no a low level does not generate a RST of the controller. Can anyone give me an answer? Kindly Regards Ulrich.
  10. So you now build all of your projects on breadboard, and the Launchpad just gets used as a progammer/debugger adaptor. The 20 pin DIP socket gahters dust. I have put this to use by writing a SPI-UART adaptor that runs on a 2553 in the DIP socket, while using the Launchpad to debug my project. The project code can thus output console data using a bit-banged SPI output. This only consumes port pins, no timers or UARTS, and is not timing-critical, as the data output is synchronous. This shows how you would use it: ... and here it is on my desk... Code is at https://github.com/shufflebits/SPI-Adaptor-2553 The code incorporates a self-test mode, so you can check that the UART link is working correctly. Just put links on where I have blue links here: This enables a test output on P1.4 and P1.6. Set the COM port to 9600,n,8,1. In normal operation, the red LED on P1.0 indicates when data is being received, and the green LEN on P1.6 indicates when the SPI input is reset. To explain: Since with a synchronous link, a single missed clock pulse will screw up all data received in the future, the code resets the SPI receiver after a second of idle time. This idle time-out is shortened by pressing S2 (P1.3). You may find it worth while to add a pull-down resistor on your target on the SPI clock out, as when it floats on reset you get spurious data. Code for the bit-banged SPI output can be found in printf.c and printf.h. Edit printf.h to define which ports will be used for output. Props to opossum for the original printf code, which I'm sure has been copied by just about everybody!
  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
  12. Is there any chance to implement debugging with Energia? The manual procedure works fine with Terminal windows on Mac OS X, although everything is manual. One of the unparalleled key feature of the LaunchPad is the built-in hardware debugger. Alas, how to use in an easy way? I'd like to set breakpoint and monitor variables. Here's the manual procedure. On a first Terminal window, launch /Applications/Energia.app/Contents/Resources/Java/hardware/tools/msp430/mspdebug/mspdebug rf2500 gdb On a second Terminal window, launch /Applications/Energia.app/Contents/Resources/Java/hardware/tools/msp430/bin/msp430-gdb /var/folders/kd/70m4ltxn14l086ddy860ff3c0000gn/T/build2770014008396495792.tmp/mySketch.cpp.elf with mySketch being the name of the sketch on Energia and /var/folders/kd/70m4ltxn14l086ddy860ff3c0000gn/T/build2770014008396495792.tmp/ the name of the path. To know the name of the path, check the Show verbose output during compilation on the preference pane of Energia and have a look at the console. Something like /var/folders/kd/70m4ltxn14l086ddy860ff3c0000gn/T/build2770014008396495792.tmp/mySketch.cpp.elf should appear at the end after a successful compilation. On the second window of the Terminal, a prompts appears: (gdb) Type (gdb) tar rem localhost:2000 Now you can type commands like (gdb) list For more information about the gdb commands, please refer to the manual available at the http://sourceware.org/gdb/download/onlinedocs/'>GDB: The GNU Project Debugger
  13. Hi, Since I started programming for MSP430 I've been looking for the MSP equivalent of "__asm int 3" (aka DebugBreak). I've come up with this fragment, tested on CCS 5.3.0: #ifndef NDEBUG // If debugger is attached and software breakpoints are enabled, DEBUG_BREAK will pause execution #define DEBUG_BREAK _op_code(0x4343) #else // Strip out DEBUG_BREAKs in final/release builds #define DEBUG_BREAK #endif Put this in a header file and you can then embed breakpoints in your code with a DEBUG_BREAK; statement. To reiterate what it says in the comment above: DEBUG_BREAK only halts if the debugger is attached and software breakpoints are enabled! For an example of where it's useful, consider the DCO calibration constants check used in a lot of example programs: if(CALBC1_1MHZ == 0xFF || CALDCO_1MHZ == 0xFF) // Check calibration constants weren't erased { DEBUG_BREAK; // Halt program (if debugger is connected) while(1); // Loop forever (as a backup) to prevent use of erased calibration data } As it normally appears (without the DEBUG_BREAK) the CPU just enters an infinite loop if the calibration data is missing. You have to notice that the program isn't progressing and manually pause to see what the problem is. With the addition of a DEBUG_BREAK the program pauses immediately so you can see what went wrong! They're handy for use in trap ISRs, to pause when an unexpected interrupt fires so you can find out what caused it. In that case you may want to leave out the infinite loop so the program can be resumed afterwards. They're useful for general debugging too, since embedding breakpoints like this has some advantages over breakpoints set in the debugger. More on that later... To understand how it works you need to know some details about how hardware and software breakpoints work. Time for a crash-course in breakpoints Placing a hardware breakpoint tells the MSP's Embedded Emulation Module (EEM) to halt the CPU whenever an instruction is fetched from the breakpoint's address. The EEM contains trigger modules that spy on the address and data buses inside the chip, and fire when they see a specified value. Once the trigger is set up the MSP runs code as normal until the trigger fires, which makes the EEM halt the CPU and stop all the clocks. This is great because it means hardware breakpoints don't mess up the internal state of the MSP. Unfortunately the EEM has a limited number of triggers (just 2 on the value-line chips), so you can only have two breakpoints! Software breakpoints work around that limitation by using one of the EEM triggers in a different way. Instead of halting when an instruction is fetched from a specific address, it halts when a specific instruction is fetched from any address. That means you can have as many breakpoints as you like, as long as they're all on the same instruction opcode. The debugger uses 0x4343 (a type of NOP) as its breakpoint opcode. When you place a software breakpoint the debugger first makes a record of the original opcode at that address. Then it overwrites it with 0x4343 in the MSP's flash memory. As before, the MSP runs code as normal until the trigger module detects an instruction fetch of the 0x4343 opcode. The EEM halts the CPU and stops the clocks. Now the debugger has to restore the opcode that it overwrote earlier and make sure it's the next instruction to execute. After you step or resume it needs to put the breakpoint opcode back again, assuming you didn't disable it in the meantime. All this writing to flash has an overhead, and the bad news is that the clocks need to be restarted during the process. That means that setting and hitting software breakpoints can make the on-chip timer peripherals go haywire. DEBUG_BREAK makes use of the debugger's trigger setup for software breakpoints, but it doesn't require any runtime flash memory overwrites. The breakpoint is entirely handled by the MSP's EEM like a hardware breakpoint, but you can have as many as you like. The only disadvantage is that you need to rebuild to move them ;-)
  14. Hi, what do people suggest to use for debugging on Mac OSX when writing programs in Energia? Is using MSPDebug with the embedded msp430-gcc the best way to go? Or is perhaps a more complete solution like bsp430 a better way to go, with more controllable makefiles, etc? Cheers, H
  • Create New...