Disable pagination: `set pagination off`

Source: https://sourceware.org/gdb/onlinedocs/gdb/Screen-Size.html

This is a rather simple question but I haven&#39;t been able to find an answer.

I have a large number of jobs running in a cluster (&gt;20) and I&#39;d like to delete them all and start over.

According to [this site](https://wiki.duke.edu/display/SCSC/Using+qdel) I should be able to just do:

    qdel -u netid

to get rid of them all, but in my case that returns:

    qdel: invalid option -- &#39;u&#39;
    usage: qdel [{ -a | -c | -p | -t | -W delay | -m message}] [&lt;JOBID&gt;[&lt;JOBID&gt;]|&#39;all&#39;|&#39;ALL&#39;]...
       -a -c, -m, -p, -t, and -W are mutually exclusive

which obviously indicates that the command does not work.

Just to check, I did:

    qstat -u &lt;username&gt;

and I do get a list of all my jobs, but:

    qdel -u &lt;username&gt;

also fails.

Use qdel to delete all my jobs at once, not one at a time

Is it possible to resize an image using FFMPEG?

I have this so far:

    ffmpeg. -i 1.jpg -vf scale=360:240 &gt; 2.jpg

I get the error message that &#39;At least one output file must be specified&#39;

Is it possible?


Use ffmpeg to resize image

I want to automatise _gdb_, and waiting for the user input is undesirable. How to disable the message `&quot;Type &lt;return&gt; to continue, or q &lt;return&gt; to quit&quot;` in _gdb_?

How to disable &quot;Type &lt;return&gt; to continue, or q &lt;return&gt; to quit&quot; in gdb?

I want to automatise gdb, and waiting for the user input is undesirable. How to disable the message <code>"Type &#x3C;return> to continue, or q &#x3C;return> to quit"</code> in gdb?

At the moment I&#39;m developing an Android app that is based on third party code. I started to set breakpoints for understanding the code and soon ran into a problem. Suddenly I couldn&#39;t get Android Studio to stop at breakpoints anymore.

I tried to set the breakpoints within `onCreate` methods, within buttons&#39; `OnClickListener`s - nothing worked. Now I found out that the only place it works is inside the app module. As the project just has one single activity class in the app module and everything else is provided within library modules in fact I can&#39;t debug at all.

I assume there&#39;s something wrong in the AndroidManifest.xml or more likely in the build.gradle file. As I just switched from Eclipse to Android Studio, all of this gradle stuff is pretty new to me. 

If I hover over a library breakpoint while the app is running, it tells me that &quot;no executable code [is] found at line ...&quot;. I assume this is the cause of my problem, but I have no idea about how to fix it.

Are there any &quot;usual suspects&quot; among the entries in build.gradle that could cause my problem?

I already did clean my project and invalidated the cache without success. I even tried the suggestion to add `&lt;activity&gt;` entries inside the library module for the fragments inside.

**Edit**: I&#39;m using the most current version of Android Studio (version 1.1.0 from February 18) which should have the similar bug fixed that existed some time ago.

The contents of build.gradle in the app module:

	apply plugin: &#39;com.android.application&#39;

	android {
	    compileSdkVersion 19
	    buildToolsVersion project.ANDROID_BUILD_TOOLS_VERSION

	    defaultConfig {
	        minSdkVersion Integer.parseInt(project.MIN_SDK)
	        targetSdkVersion  Integer.parseInt(project.ANDROID_BUILD_TARGET_SDK_VERSION)
	    }

	    signingConfigs {
	        release {
	            keyAlias &#39;xxx&#39;
	            keyPassword &#39;xxx&#39;
	            storeFile file(&#39;xxx&#39;)
	            storePassword &#39;xxx&#39;
	        }
	    }

	    buildTypes {
	        release {
	            minifyEnabled false
	            proguardFiles getDefaultProguardFile(&#39;proguard-android.txt&#39;), &#39;proguard-rules.txt&#39;
	            signingConfig signingConfigs.release
	            debuggable false
	            jniDebuggable false
	            zipAlignEnabled true
	        }
            debug {
                minifyEnabled false
                debuggable true
            }
	    }

	    packagingOptions {
	        exclude &#39;META-INF/DEPENDENCIES&#39;
	        exclude &#39;META-INF/NOTICE&#39;
	        exclude &#39;META-INF/LICENSE&#39;
	        exclude &#39;META-INF/LICENSE.txt&#39;
	        exclude &#39;META-INF/NOTICE.txt&#39;
	    }
	    productFlavors {
	    }
	}

	dependencies {
	    compile fileTree(dir: &#39;libs&#39;, include: [&#39;*.jar&#39;])
	    compile project(&#39;:firebase_plugin&#39;)
	}

And the build.gradle of library module:

    apply plugin: &#39;com.android.library&#39;
	android {

	    compileSdkVersion 19
	    buildToolsVersion project.ANDROID_BUILD_TOOLS_VERSION
	    defaultConfig {
	        minSdkVersion Integer.parseInt(project.MIN_SDK)
	        targetSdkVersion Integer.parseInt(project.ANDROID_BUILD_TARGET_SDK_VERSION)
	    }

	    buildTypes {
	        release {
	            minifyEnabled true
	            zipAlignEnabled true
	            proguardFiles getDefaultProguardFile(&#39;proguard-android.txt&#39;), &#39;proguard-rules.txt&#39;
	        }
            debug {
                minifyEnabled false
                debuggable true
            }
	    }

	    productFlavors {
	    }

	}

	dependencies {
	    // Facebook SDK
	    compile project(&#39;:facebook&#39;)

	    // Used for StringUtils
	    compile files(&#39;libs/commons-lang3-3.3.2.jar&#39;)
	    // Bug tracking
	    compile files(&#39;libs/bugsense-3.6.1.jar&#39;)
	    compile fileTree(include: [&#39;*.jar&#39;], dir: &#39;libs&#39;)
	    //Google Play Services - For Google Maps
	    compile(&#39;com.google.android.gms:play-services:5.0.89&#39;) {
	        exclude group: &#39;com.google.android&#39;, module: &#39;support-v4&#39;
	    }
	    // Support Library.
	    compile &#39;com.android.support:support-v13:18.0.+&#39;

	    compile(&#39;com.android.support:appcompat-v7:19.1.0&#39;) {
	        exclude group: &#39;com.google.android&#39;, module: &#39;support-v4&#39;
	    }
	    // Volley - Networking library from google.
	    compile(&#39;com.mcxiaoke.volley:library:1.0.0&#39;) {
	        exclude group: &#39;com.google.android&#39;, module: &#39;support-v4&#39;
	    }
	    // Has is own support library in it so need to exclude it so no TOP_LEVEL_EXCEPTION will occur.
	    compile(&#39;de.greenrobot:greendao:1.3.0&#39;) {
	        exclude group: &#39;com.google.android&#39;, module: &#39;support-v4&#39;
	    }
	    // Firebase
	    compile(&#39;com.firebase:firebase-simple-login:1.4.2&#39;) {
	        exclude group: &#39;com.android.support&#39;, module: &#39;support-v4&#39;
	    }
	    // Super Toast
	    compile(&#39;com.github.johnpersano:supertoasts:1.3.4@aar&#39;) {
	        exclude group: &#39;com.android.support&#39;, module: &#39;support-v4&#39;
	    }
	    // Croping images
	    compile(&#39;com.soundcloud.android:android-crop:0.9.10@aar&#39;) {
	        exclude group: &#39;com.android.support&#39;, module: &#39;support-v4&#39;
	    }
	    compile(&#39;com.github.chrisbanes.actionbarpulltorefresh:library:0.9.9&#39;) {
	        exclude group: &#39;com.android.support&#39;, module: &#39;support-v4&#39;
	    }
	}


	    packagingOptions {
	        exclude &#39;META-INF/DEPENDENCIES&#39;
	        exclude &#39;META-INF/NOTICE&#39;
	        exclude &#39;META-INF/LICENSE&#39;
	        exclude &#39;META-INF/LICENSE.txt&#39;
	        exclude &#39;META-INF/NOTICE.txt&#39;
	    }
	    productFlavors {
	    }
	}

	dependencies {
	    compile fileTree(dir: &#39;libs&#39;, include: [&#39;*.jar&#39;])
	    compile project(&#39;:firebase_plugin&#39;)
	}

![enter image description here][1]


  [1]: http://i.stack.imgur.com/c7fuC.png

Android Studio&#39;s debugger not stopping at breakpoints within library modules

I&#39;ve recently started getting this error:

    2015-03-23 11:35:48.902 run[60036:1047011] Crashlytics.framework/run 1.3.14
    2015-03-23 11:35:48.911 run[60036:1047011] 
    
    Crashlytics: dSYM Error
    
    Unable to process &lt;your app&gt;.app.dSYM at path /path/to/&lt;your app&gt;.app.dSYM
    Make sure your project build settings are generating a dSYM file. DEBUG_INFORMATION_FORMAT should be set to dwarf-with-dsym for all configurations. This could also be a timing issue, make sure the Crashlytics run script build phase is the last build phase and no other scripts have moved the dSYM from the location Xcode generated it.
    
    Command /bin/sh failed with exit code 1

I tried this answer https://stackoverflow.com/questions/4466095/unable-to-copy-dsym-file-into-archive but all my `Generate Debug Symbols` are set to `YES` 

Any further suggestions?



Make sure your project build settings are generating a dSYM file. DEBUG_INFORMATION_FORMAT should be set to dwarf-with-dsym for all configurations

I&#39;ve been having trouble debugging a multithreaded app with Android Studio 1.1. It seems as if when a breakpoint is hit all other threads also stop, not just the one with the breakpoint. I created a simple test app with the following method in the Activity&#39;s onCreate. 

    @Override
	protected void onCreate(Bundle savedInstanceState) {
		super.onCreate(savedInstanceState);
		setContentView(R.layout.activity_main);

		Thread a = new Thread(&quot;thread-a&quot;) {
			@Override
			public void run() {
				Log.v(&quot;thread&quot;, &quot;thread-a&quot;);
			}
		};

		Thread b = new Thread(&quot;thread-b&quot;) {
			@Override
			public void run() {
				Log.v(&quot;thread&quot;, &quot;thread-b&quot;);
			}
		};

		a.start();
		b.start();
	}

I set breakpoints at the Log.v lines in thread-a and thread-b and then I run it in debug mode on my Lollipop Nexus 5.

When the app starts it hits the breakpoint in thread-a but the first problem I notice is that the app&#39;s UI is blank as if the main thread is paused. Next I went to see that the breakpoint in thread-b is also hit so I pull up the Threads view in Android Studio&#39;s debugger but when I go to expand the thread-b arrow there&#39;s nothing there. When I expand the main thread it shows it is paused somewhere in onStart().

![Android Studio screenshot][1]

Am I doing something wrong or is this debugger incapable of debugging multiple threads at once?


  [1]: http://i.stack.imgur.com/79t8m.png

Android Studio threaded debugging

How does one debug their React code with React Native while the app is running in app simulator? 

How do you debug React Native?

I’ve just upgraded Android Studio from version 1.0 to 1.2 beta and I can no longer perform any kind of debug operation. If I set a break point, Android Studio hangs and it can’t resolve the command: 

    Waiting until last debugger command completes

but it never completes.

So, is it possible to downgrade to the previous stable version (1.0) without downloading again?

Thanks!

Android Studio 1.2 beta version hangs on debugging

what have i done wrong (or didn&#39;t do) that `gdb` is not working properly for me?

    root@6be3d60ab7c6:/# cat minimal.c 
    int main()
    {
      int i = 1337;
      return 0;
    }
    root@6be3d60ab7c6:/# gcc -g minimal.c -o minimal
    root@6be3d60ab7c6:/# gdb minimal
    GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
    .
    .
    .
    Reading symbols from minimal...done.
    (gdb) break main
    Breakpoint 1 at 0x4004f1: file minimal.c, line 3.
    (gdb) run
    Starting program: /minimal 
    warning: Error disabling address space randomization: Operation not permitted
    During startup program exited normally.
    (gdb) 
    (gdb) print i   
    No symbol &quot;i&quot; in current context.



warning: Error disabling address space randomization: Operation not permitted

The standard (low-cost) way to program ARM microcontrollers is using Eclipse with a complex toolchain plugged into it. Eclipse has definitely its merits, but I&#39;d like to feel independent from this IDE. I&#39;d like to discover what happens behind the scenes when I build (compile - link - flash) my software, and when I run a debug session. To get such deeper understanding, it would be wonderful to run the whole procedure from the command line.

Note: I&#39;m using 64-bit Windows 10. But most stuff explained here also applies on Linux systems. Please open all the command terminals with admin rights. This can save you lots of problems.

**1. Building the software**

The first &#39;mission&#39; is accomplished. I am now able to compile and link my software into a binary `.bin` and a `.elf` image through the command line. The key to success was finding out where Eclipse puts its make-files for a specific project. Once you know where they are, all you&#39;ve got to do is opening a command terminal, and type the `GNU make` command.

[![enter image description here][1]][1]

You don&#39;t need Eclipse anymore for that! Especially if you can read (and understand) the makefile and tweak it to your needs when your project advances.

Note that I found the GNU tools (compiler, linker, make utility, GDB, ...) in the following folder, after installing SW4STM32 (System Workbench for STM32):

    C:\Ac6\SystemWorkbench\plugins\fr.ac6.mcu.externaltools.arm-none.win32_1.7.0.201602121829\tools\compiler\

Next I made a new folder on my harddrive and copied all these GNU tools into it:

    C:\Apps\AC6GCC
               |-&gt; arm-none-eabi
               |-&gt; bin
               &#39;-&gt; lib

And I add these entries to the &quot;Environment Path variable&quot;:

     - C:\Apps\AC6GCC\bin
     - C:\Apps\AC6GCC\lib\gcc\arm-none-eabi\5.2.1

Huray, now I got all the GNU tools up and running on my system! I put the following `build.bat` file in the same folder as the `makefile`:

    @echo off
    echo.
    echo.&quot;--------------------------------&quot;
    echo.&quot;-           BUILD              -&quot;
    echo.&quot;--------------------------------&quot;
    echo.
    
    make -j8 -f makefile all
    
    echo.

Running this bat-file should do the job! If all goes well, you get one `.bin` and one `.elf` binary file as the result of the compilation.

**2. Flashing and debugging the firmware**

The natural following step is flashing the firmware to the chip and start a debug session. In Eclipse it&#39;s just one &#39;click on a button&#39; - at least if Eclipse is configured correctly for your microcontroller. But what happens behind the scenes?
I&#39;ve read (part of) the Master Thesis from Dominic Rath - the developer of OpenOCD. You can find it here: http://openocd.net/ . This is what I learned:

- Eclipse starts the OpenOCD software when you click the &#39;debug&#39; icon. Eclipse also provides some configuration files to OpenOCD - such that OpenOCD knows how to connect to your microcontroller. &#39;How to connect&#39; is not a trivial thing. OpenOCD needs to find the proper USB driver to connect to the JTAG adapter (for example STLink). Both the JTAG adapter and its USB driver are usually delivered by your chip manufacturer (for example STMicroelectronics). Eclipse also hands over a configuration file to OpenOCD that describes the specifications of the microcontroller. Once OpenOCD knows about all these things, it can make a reliable JTAG connection to the target device.

- OpenOCD starts two servers. The first one is a Telnet server on TCP port 4444. It gives access to the OpenOCD CLI (Command Line Interface). A Telnet client can connect and send commands to OpenOCD. Those commands can be a simple &#39;stop&#39;, &#39;run&#39;, &#39;set breakpoint&#39;, ... 

- Such commands could be sufficient for debugging your microcontroller, but many people were already familiar with the Gnu Debugger (GDB). This is why OpenOCD also starts a GDB server on TCP port 3333. A GDB client can connect to that port, and start debugging the microcontroller!

- The Gnu Debugger is a command line software. Many people prefer a visual interface. That is exactly what Eclipse does. Eclipse starts a GDB client that connects to OpenOCD - but that is all hidden to the user. Eclipse provides a graphical interface that interacts with the GDB client behind the scenes.

I&#39;ve made a figure to explain all these things:

[![enter image description here][2]][2]


**&gt;&gt; Starting up OpenOCD**

I managed to start up OpenOCD from the command line. I&#39;ll explain how.

 1. First make sure that your STLink-V2 JTAG programmer is properly installed. You can test the installation with the &quot;STLink Utility tool&quot; from STMicroelectronics. It has a nice GUI, and you simply click the connect button.
[![enter image description here][3]][3]
 1. Next download the OpenOCD software executable from this website: http://gnutoolchains.com/arm-eabi/openocd/ . Install it, and put it in a folder on your harddrive, like &quot;C:\Apps\&quot;.
 2. Open a command terminal, and start OpenOCD. You will need to give OpenOCD a few configuration files, such that it knows where to look for your microcontroller. Typically you need to give a configuration file that describes the JTAG programmer, and a configuration file that defines your microcontroller. Pass those files to OpenOCD with the `-f` argument in the command line. You will also need to give OpenOCD access to the `scripts` folder, by passing it with the `-s` argument. This is how I start OpenOCD on my computer with the command line:


        &gt; &quot;C:\Apps\OpenOCD-0.9.0-Win32\bin\openocd&quot; -f &quot;C:\Apps\OpenOCD-0.9.0-Win32\share\openocd\scripts\interface\stlink-v2.cfg&quot; -f &quot;C:\Apps\OpenOCD-0.9.0-Win32\share\openocd\scripts\target\stm32f7x.cfg&quot; -s &quot;C:\Apps\OpenOCD-0.9.0-Win32\share\openocd\scripts&quot;


 3. If you started OpenOCD properly (with the correct arguments), it will startup with the following message:

        Open On-Chip Debugger 0.9.0 (2015-08-15-12:41)
        Licensed under GNU GPL v2
        For bug reports, read
                http://openocd.org/doc/doxygen/bugs.html
        Info : auto-selecting first available session transport &quot;hla_swd&quot;. To override use &#39;transport select &lt;transport&gt;&#39;.
        Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
        adapter speed: 2000 kHz
        adapter_nsrst_delay: 100
        srst_only separate srst_nogate srst_open_drain connect_deassert_srst
        Info : Unable to match requested speed 2000 kHz, using 1800 kHz
        Info : Unable to match requested speed 2000 kHz, using 1800 kHz
        Info : clock speed 1800 kHz
        Info : STLINK v2 JTAG v24 API v2 SWIM v4 VID 0x0483 PID 0x3748
        Info : using stlink api v2
        Info : Target voltage: 3.231496
        Info : stm32f7x.cpu: hardware has 8 breakpoints, 4 watchpoints
        Info : accepting &#39;gdb&#39; connection on tcp/3333
        Info : flash size probed value 1024

 4. Notice that your terminal window is now blocked. You can no longer type commands. But that&#39;s normal. OpenOCD is running in the background, and it blocks the terminal. Now you&#39;ve got two options to interact with OpenOCD: you start a Telnet session in another terminal, and you log on to TCP port `localhost:4444`, so you can give commands to OpenOCD and receive feedback. Or you start a GDB client session, and connect it to TCP port `localhost:3333`.

**&gt;&gt; Starting up a Telnet session to interact with OpenOCD**

This is how you start a Telnet session to interact with the running OpenOCD program:

    &gt; dism /online /Enable-Feature /FeatureName:TelnetClient
    
    &gt; telnet 127.0.0.1 4444

If it works well, you&#39;ll get the following message on your terminal:

    Open On-Chip Debugger
    &gt; ..

And you&#39;re ready to send commmands to OpenOCD! But I&#39;ll now switch to the GDB session, since that&#39;s the most convenient way to interact with OpenOCD.

**&gt;&gt; Starting up a GDB client session to interact with OpenOCD**

Open yet another terminal window, and type the following command:

    &gt; &quot;C:\Apps\AC6GCC\bin\arm-none-eabi-gdb.exe&quot;

This command simply starts the `arm-none-eabi-gdb.exe` GDB client. If all goes well, GDB starts up with the following message:

        GNU gdb (GNU Tools for ARM Embedded Processors) 7.10.1.20151217-cvs
        Copyright (C) 2015 Free Software Foundation, Inc.
        License GPLv3+: GNU GPL version 3 or later &lt;http://gnu.org/licenses/gpl.html&gt;
        This is free software: you are free to change and redistribute it.
        There is NO WARRANTY, to the extent permitted by law.  Type &quot;show copying&quot;
        and &quot;show warranty&quot; for details.
        This GDB was configured as &quot;--host=i686-w64-mingw32 --target=arm-none-eabi&quot;.
        Type &quot;show configuration&quot; for configuration details.
        For bug reporting instructions, please see:
        &lt;http://www.gnu.org/software/gdb/bugs/&gt;.
        Find the GDB manual and other documentation resources online at:
        &lt;http://www.gnu.org/software/gdb/documentation/&gt;.
        For help, type &quot;help&quot;.
        Type &quot;apropos word&quot; to search for commands related to &quot;word&quot;.
        (gdb)..

Now connect this GDB client to the GDB server inside OpenOCD:

        (gdb) target remote localhost:3333

Now you&#39;re connected to OpenOCD! Good to know: if you want to use a native OpenOCD command (just like you would do in a Telnet session), just precede the command with the keyword `monitor`. This way the GDB server inside OpenOCD will not handle the command himself, but pass it on to the native OpenOCD deamon.

So, now it is time to reset the chip, erase it and halt it:

        (gdb) monitor reset halt
           target state: halted
           target halted due to debug-request, current mode: Thread
           xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
        (gdb) monitor halt
        
        (gdb) monitor flash erase_address 0x08000000 0x00100000
           erased address 0x08000000 (length 1048576) in 8.899024s (115.069 KiB/s)
        (gdb) monitor reset halt
           target state: halted
           target halted due to debug-request, current mode: Thread
           xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
        (gdb) monitor halt

The chip is now ready to get some instructions from us. First we will tell the chip that its flash sections 0 to 7 (that&#39;s all the flash sections in my 1Mb chip) should not be protected:

        (gdb) monitor flash protect 0 0 7 off
        
        (gdb) monitor flash info 0
           #0 : stm32f7x at 0x08000000, size 0x00100000, buswidth 0, chipwidth 0
                #  0: 0x00000000 (0x8000 32kB) not protected
                #  1: 0x00008000 (0x8000 32kB) not protected
                #  2: 0x00010000 (0x8000 32kB) not protected
                #  3: 0x00018000 (0x8000 32kB) not protected
                #  4: 0x00020000 (0x20000 128kB) not protected
                #  5: 0x00040000 (0x40000 256kB) not protected
                #  6: 0x00080000 (0x40000 256kB) not protected
                #  7: 0x000c0000 (0x40000 256kB) not protected

Next I halt the chip again. Just to be sure..

        (gdb) monitor halt

Finally I hand over the binary `.elf` file to GDB:

        (gdb) file C:\\..\\myProgram.elf
           A program is being debugged already.
           Are you sure you want to change the file? (y or n) y
           Reading symbols from C:\..\myProgram.elf ...done.

Now is the moment of truth. I ask GDB to load this binary into the chip. Fingers crossed:

        (gdb) load
           Loading section .isr_vector, size 0x1c8 lma 0x8000000
           Loading section .text, size 0x39e0 lma 0x80001c8
           Loading section .rodata, size 0x34 lma 0x8003ba8
           Loading section .init_array, size 0x4 lma 0x8003bdc
           Loading section .fini_array, size 0x4 lma 0x8003be0
           Loading section .data, size 0x38 lma 0x8003be4
           Error finishing flash operation

Sadly it was not successful. I get the following message in OpenOCD:

        Error: error waiting for target flash write algorithm
        Error: error writing to flash at address 0x08000000 at offset 0x00000000

------------------------------

**EDIT : Hardware issue fixed.**

Apparently it was a hardware issue. I had never thought that my chip would be defect, since loading the binary onto the chip with the STLink Utility tool worked without problem. Only OpenOCD was complaining and giving errors. So naturally I blamed OpenOCD - and not the chip itself. See my answer below for more details.

------------------------------

**EDIT : Alternative elegant way to flash the chip - using makefile!**

As the issue got fixed, I will now focus on an alternative way to execute the flash and debug of the chip. I believe this is really interesting for the community!

You might have noticed that I used Windows cmd commands to execute all the necessary steps. This can be automated in a batch file. But there is a more elegant way: to automate everything in a makefile!
Mr./Mss. Othane has suggested the following makefile for his/her Cortex-M? chip. I suppose that the procedure for a Cortex-M7 chip is very similar:

                #################################################
                #        MAKEFILE FOR BUILDING THE BINARY       #
                #        AND EVEN FLASHING THE CHIP!            #
                # Author: Othane                                #
                #################################################
                
		# setup compiler and flags for stm32f373 build 
		SELF_DIR := $(dir $(lastword $(MAKEFILE_LIST))) 
		 
		 
		CROSS_COMPILE ?= arm-none-eabi- 
		export CC = $(CROSS_COMPILE)gcc 
		export AS = $(CROSS_COMPILE)gcc -x assembler-with-cpp 
		export AR = $(CROSS_COMPILE)ar 
		export LD = $(CROSS_COMPILE)ld 
		export OD   = $(CROSS_COMPILE)objdump 
		export BIN  = $(CROSS_COMPILE)objcopy -O ihex 
		export SIZE = $(CROSS_COMPILE)size 
		export GDB = $(CROSS_COMPILE)gdb 

		 
		MCU = cortex-m4 
		FPU = -mfloat-abi=hard -mfpu=fpv4-sp-d16 -D__FPU_USED=1 -D__FPU_PRESENT=1 -DARM_MATH_CM4 
		DEFS = -DUSE_STDPERIPH_DRIVER -DSTM32F37X -DRUN_FROM_FLASH=1 -DHSE_VALUE=8000000 
		OPT ?= -O0  
		MCFLAGS = -mthumb -mcpu=$(MCU) $(FPU) 

		 
		export ASFLAGS  = $(MCFLAGS) $(OPT) -g -gdwarf-2 $(ADEFS) 
		CPFLAGS += $(MCFLAGS) $(OPT) -gdwarf-2 -Wall -Wno-attributes -fverbose-asm  
		CPFLAGS += -ffunction-sections -fdata-sections $(DEFS) 
		export CPFLAGS 
		export CFLAGS += $(CPFLAGS) 

		 
		export LDFLAGS  = $(MCFLAGS) -nostartfiles -Wl,--cref,--gc-sections,--no-warn-mismatch $(LIBDIR) 

		 
		HINCDIR += ./STM32F37x_DSP_StdPeriph_Lib_V1.0.0/Libraries/CMSIS/Include/ \ 
			./STM32F37x_DSP_StdPeriph_Lib_V1.0.0/Libraries/CMSIS/Device/ST/STM32F37x/Include/ \ 
			./STM32F37x_DSP_StdPeriph_Lib_V1.0.0/Libraries/STM32F37x_StdPeriph_Driver/inc/ \ 
			./ 
		export INCDIR = $(patsubst %,$(SELF_DIR)%,$(HINCDIR)) 

		 

		 
		# openocd variables and targets 
		OPENOCD_PATH ?= /usr/local/share/openocd/ 
		export OPENOCD_BIN = openocd 
		export OPENOCD_INTERFACE = $(OPENOCD_PATH)/scripts/interface/stlink-v2.cfg 
		export OPENOCD_TARGET = $(OPENOCD_PATH)/scripts/target/stm32f3x_stlink.cfg 

		 
		OPENOCD_FLASH_CMDS = &#39;&#39; 
		OPENOCD_FLASH_CMDS += -c &#39;reset halt&#39; 
		OPENOCD_FLASH_CMDS += -c &#39;sleep 10&#39;  
		OPENOCD_FLASH_CMDS += -c &#39;stm32f1x unlock 0&#39; 
		OPENOCD_FLASH_CMDS += -c &#39;flash write_image erase $(PRJ_FULL) 0 ihex&#39; 
		OPENOCD_FLASH_CMDS += -c shutdown 
		export OPENOCD_FLASH_CMDS 

		 
		OPENOCD_ERASE_CMDS = &#39;&#39; 
		OPENOCD_ERASE_CMDS += -c &#39;reset halt&#39; 
		OPENOCD_ERASE_CMDS += -c &#39;sleep 10&#39;  
		OPENOCD_ERASE_CMDS += -c &#39;sleep 10&#39;  
		OPENOCD_ERASE_CMDS += -c &#39;stm32f1x mass_erase 0&#39; 
		OPENOCD_ERASE_CMDS += -c shutdown 
		export OPENOCD_ERASE_CMDS 

		 
		OPENOCD_RUN_CMDS = &#39;&#39; 
		OPENOCD_RUN_CMDS += -c &#39;reset halt&#39; 
		OPENOCD_RUN_CMDS += -c &#39;sleep 10&#39; 
		OPENOCD_RUN_CMDS += -c &#39;reset run&#39; 
		OPENOCD_RUN_CMDS += -c &#39;sleep 10&#39;  
		OPENOCD_RUN_CMDS += -c shutdown 
		export OPENOCD_RUN_CMDS 

		 
		OPENOCD_DEBUG_CMDS = &#39;&#39; 
		OPENOCD_DEBUG_CMDS += -c &#39;halt&#39; 
		OPENOCD_DEBUG_CMDS += -c &#39;sleep 10&#39; 

		 
		.flash: 
			$(OPENOCD_BIN) -f $(OPENOCD_INTERFACE) -f $(OPENOCD_TARGET) -c init $(OPENOCD_FLASH_CMDS) 

		 
		.erase: 
			$(OPENOCD_BIN) -f $(OPENOCD_INTERFACE) -f $(OPENOCD_TARGET) -c init $(OPENOCD_ERASE_CMDS) 

		 
		.run: 
			$(OPENOCD_BIN) -f $(OPENOCD_INTERFACE) -f $(OPENOCD_TARGET) -c init $(OPENOCD_RUN_CMDS) 

		 
		.debug: 
			$(OPENOCD_BIN) -f $(OPENOCD_INTERFACE) -f $(OPENOCD_TARGET) -c init $(OPENOCD_DEBUG_CMDS) 

		 
Dear Mr./Mss. Othane, could you explain how to use this makefile for the following steps:

 - Build the binary from the source code
 - Flash the chip

I know some basics about makefiles, but your makefile is really going quite deep. You seem to use quite some features of the GNU make utility. Please give us some more explanation, and I&#39;ll grant you the bonus ;-)

------------------------------
------------------------------


  [1]: http://i.stack.imgur.com/zY6lR.png
  [2]: http://i.stack.imgur.com/LMxKN.png
  [3]: http://i.stack.imgur.com/cHn7P.png

Content Type	Original Author	Original Content on Stackoverflow
Question	Fábio Perez	View Question on Stackoverflow
Solution 1 - Debugging	Fábio Perez	View Answer on Stackoverflow

How to disable "Type <return> to continue, or q <return> to quit" in gdb?

Debugging Problem Overview

Debugging Solutions

Solution 1 - Debugging

Use ffmpeg to resize image

Use qdel to delete all my jobs at once, not one at a time

Attributions