Giter Site home page Giter Site logo

stm32flash's People

Contributors

alenyashka avatar armint avatar borneoa avatar bsilver8192 avatar equinox0815 avatar georgwebdyn avatar jepler avatar ku3i avatar lfrodrigues avatar paulfertser avatar reubendowle avatar tormodvolden avatar wild-wild-boar avatar xdandys avatar

stm32flash's Issues

[PATCH] add support for flash writes not starting at offset 0 

I'm doing some fancy image generation and flashing; effectively using three 
firmware images (a "bootloader" and two "firmware" images) that need to be 
flashed (and more importantly, erased) independently.  

The attached patch adds support for specifying a page offset into the flash, 
for reads, erases, and writes.  

The patch also fixes an off-by-one error in the erase function -- the byte 
after the erase command is "number of pages -1" ie a value of 12 means that 13 
pages will be erased. (see pg 21 of ST's AN3155 "USART Protocol used in the 
STM32 bootloader" rev 2)

Original issue reported on code.google.com by [email protected] on 8 Aug 2011 at 2:01

Attachments:

code cleanups 

I tried building the code with arm-linux-gnueabihf-gcc 4.7.2 with some warnings 
enabled and found some things that look wrong. Attached are 2 patches that fix 
these:
1: C98 (and probably some other versions) don't allow forward-declaring an 
enum. GCC 4.7.2 for ARM gives an error for this, and it's a trivial fix.
2: There were lots of place const was used where it shouldn't be, and a few 
places it needed to be added. It still compiles, so it shouldn't have any 
functional effect, except for possibly the windows code which I didn't try 
compiling.

Original issue reported on code.google.com by [email protected] on 18 Dec 2013 at 1:50

Attachments:

Support STM32F0 devices 

Even though AN2606 doesn't list F0, the same data (except for the memory used 
by the bootloader) is obtainable from the datasheet.

With the attached patch it's possible to work with the device manually 
resetting it after each invocation (probably armv6-m vs armv7-m differences).

Original issue reported on code.google.com by [email protected] on 5 Jul 2012 at 10:46

Attachments:

support for stm32L151 

{0x416, "stm32L151"       , 0x20000800, 0x20004000, 0x08000000, 0x08020000, 16, 
256, 0x1FF80000, 0x1FF80020, 0x1FF00000, 0x1FF02000}, // from STM32 AN2606

Original issue reported on code.google.com by [email protected] on 21 Sep 2012 at 1:10

More then two bytes sent 

I built the tool on a mc tonight.
When I run it against a couple of STM32 boards I have here, for each I get the 
same result:

stm32flash - http://stm32flash.googlecode.com/

Serial Config: 57600 8E1
More then two bytes sent in the PID, unknown/unsupported device

the Python loader script works just fine on the same devices.

Any ideas?

Original issue reported on code.google.com by [email protected] on 27 Jul 2011 at 12:01

stm32flash fails on FreeBSD - fix included 

What steps will reproduce the problem?
1. compile stm32flash on FreeBSD
2. Try to use it with a stm32 board, like ./stm32flash /dev/cuaU0
3.

What is the expected output? What do you see instead?
Instead of giving device info, I get:
tingo@kg-core1$ ./stm32flash /dev/cuaU0
stm32flash - http://stm32flash.googlecode.com/

/dev/cuaU0: No such file or directory


What version of the product are you using? On what operating system?
Valid for both the one for download here, and the one from 
https://gitorious.org/stm32flash
I'm using FreeBSD:
tingo@kg-core1$ uname -a
FreeBSD kg-core1.kg4.no 8.4-STABLE FreeBSD 8.4-STABLE #0 r253646: Thu Jul 25 
10:12:31 UTC 2013
     [email protected]:/usr/obj/usr/src/sys/GENERIC  amd64

Please provide any additional information below.
The problem is that INPCK is a input flag in FreeBSD, not a control flag (not 
sure how it is in Linux), so when the code in serial_setup adds that to the 
control flags, written and read control flags differ, and the code fails.
Fix below (I fiddled with 'git format-patch' but didn't grok it):

tingo@kg-core1$ git diff
diff --git a/serial_posix.c b/serial_posix.c
index f4097b4..3cca7e1 100644
--- a/serial_posix.c
+++ b/serial_posix.c
@@ -105,8 +105,8 @@ serial_err_t serial_setup(serial_t *h, const serial_baud_t 
baud, const serial_bi

        switch(parity) {
                case SERIAL_PARITY_NONE: port_parity = 0;                       break;
-               case SERIAL_PARITY_EVEN: port_parity = INPCK | PARENB;          
break;
-               case SERIAL_PARITY_ODD : port_parity = INPCK | PARENB | PARODD; 
break;
+               case SERIAL_PARITY_EVEN: port_parity = PARENB;          break;
+               case SERIAL_PARITY_ODD : port_parity = PARENB | PARODD; break;

                default:
                        return SERIAL_ERR_INVALID_PARITY;

Original issue reported on code.google.com by [email protected] on 27 Sep 2013 at 10:42

Fails to detect the STM32L15xxx range of ultra-low power MCUs 

There's no entry in stm32.c for the EnergyLite range (STM32L15xxx), so the 
search performed in stm32_init() returns a null value, pointing to 
uninitialised memory.

It should probably handle this case, and admit it is an unknown device, and 
unsafe to program.

Looking at the datasheet, page 40, suggest these values should be correct:

{0x416, "Energylite", 0x20000000, 0x20004000, 0x08000000, 0x08020000, 4, 1024, 
0x1FF80000, 0x1FF8001F, 0x1FF00000, 0x1FF00FFF},

The entry for fl_end seems at odds with the datasheets. Looks like an 
off-by-one error, as to get the right result (as seen below) you have to give 
the next address up, and not the real end address, which is 0x0801FFFF.

This chip is used in the STM32L-Discovery demo board.

When compiled with the line above added in, we get:

stm32flash - http://stm32flash.googlecode.com/

Serial Config: 57600 8E1
Version      : 0x30
Option 1     : 0x00
Option 2     : 0x00
Device ID    : 0x0416 (Energylite)
RAM          : 16KiB  (0b reserved by bootloader)
Flash        : 128KiB (sector size: 4x1024)
Option RAM   : 31b
System RAM   : 3KiB

Resetting device... failed.

Original issue reported on code.google.com by [email protected] on 15 Jun 2011 at 12:56

[patch]MinGW compile 

Hi,

and thanks for stm32flash. A small patch is needed for compiling stm32flash 
with MinGW (Windows 7)

The resulting .exe is able to read and write a controller:) :)
There are a few minor glitches though:

a) specifying a non-existant (or in-use) com port does not give an error (see 
"ad a)" below).
b) trying to read from a device if it is not in bootloader mode sometimes 
causes an assert (see "ad b)" below).
c) the control sequences for the progress indicator don't match (seems CR is 
not seen).

Greetings,
Frieder





---8<----------------------------------------------
ad a)
c:\tmp\stm32flash>stm32flash.exe -r testfile COM22:
stm32flash - http://stm32flash.googlecode.com/

COM22:: No error


ad b)
c:\tmp\stm32flash>stm32flash.exe -r testfile COM4:
stm32flash - http://stm32flash.googlecode.com/

Serial Config: 57600 8E1
read_byte: No error
Assertion failed: 0, file stm32.c, line 92

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.


ad c)
Option RAM   : 15b
System RAM   : 4KiB

←[s←[uRead address 0x08000100 (0.20%) ←[uRead address 0x08000200 (0.39%) 
←[uRead address 0x08000300 (0.59%) ←[uRead address 0x08000400 (0.78%) 
←[uRead address 0x08000500 (0.98%) ←[uRead address 0x0800
0600 (1.17%) ←[uRead address 0x08000700 (1.37%)

Original issue reported on code.google.com by [email protected] on 4 Nov 2011 at 4:30

Attachments:

On Windows version COMn > COM9 init does not work 

What steps will reproduce the problem?
1. try to use COM10 or bigger as serial port


What version of the product are you using? On what operating system?
* Win-XP32, Win7

Please provide any additional information below.
* I already fixed that bug and would provide the change - just tell me how to 
commit or patch that code snippet into serial_w32.c...

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
serial_t* serial_open(const char *device) 
{
    unsigned char i=0;
    COMMTIMEOUTS timeouts = {MAXDWORD, 0, 0, 0, 0};
    serial_t *h = calloc(sizeof(serial_t), 1);

    /* Fix the device name if required for COM10..99 */
    char tmp[11];
    if (strlen(device) > 4 && device[0] != '\\')
    {
        while(device[i] && i<=10)
        {
            tmp[i] = device[i];
            i++;
        }
        if (i<11)
            tmp[i] = 0x00;
        else
            tmp[10] = 0x00;

        sprintf(device, "\\\\.\\%s", tmp);
    }

    /* Create file handle for port */
    h->fd = CreateFile(device, GENERIC_READ | GENERIC_WRITE, 
            0, /* Exclusive access */
            NULL, /* No security */
            OPEN_EXISTING,
            0, //FILE_FLAG_OVERLAPPED,
            NULL);

    if(h->fd == INVALID_HANDLE_VALUE)
    {
        fprintf(stderr, "Could not open Comport: %s", device);
        return NULL;
    }

    SetupComm(h->fd, 4096, 4096); /* Set input and output buffer size */

    SetCommTimeouts(h->fd, &timeouts);

    SetCommMask(h->fd, EV_ERR); /* Notify us of error events */

    GetCommState(h->fd, &h->oldtio); /* Retrieve port parameters */
    GetCommState(h->fd, &h->newtio); /* Retrieve port parameters */

    return h;
}

Original issue reported on code.google.com by [email protected] on 15 Aug 2013 at 5:38

  • Merged into: #5

stm->dev->name get NULL value 

What steps will reproduce the problem?
1. Switch MCU to bootloader mode
2. start stm32flash : stm32flash /dev/ttyUSB0
3. get Device ID    : 0x0413 ((NULL))
What version of the product are you using? On what operating system?
I use ubuntu 13.10

Please provide any additional information below.
I think something went wrong with stm32.c 181. row where the while () tries 
identify device by  PID.

Original issue reported on code.google.com by [email protected] on 11 Nov 2013 at 9:01

Toggle RTS option [patch] 

It would be useful to be able to toggle the RTS pin before programming to issue 
a reset on the device, and I have created a patch that does just that. This 
option is described in the help text as well.

I have not implemented this on the windows part, nor am I planning to or have 
any possibility do so, but I have added a stub in the windows serial port 
driver and a few #ifdefs, so someone else can do it if they want to (it should 
still compile, but the option is not available).

I have made a simple circuit with one transistor, one diode and a few resistors 
and capacitors that creates the following behaviour:

* When reset using a power cycle, the normal program will start.
* When reset using a reset input (not directly connected to the reset pin), the 
bootloader will start. When the bootloader resets the mcu afterwards, the 
normal program will start.

Thus, when the reset input is used, boot0 will be connected to vcc and reset to 
gnd. When the reset input is released, the boot0 pin is pulled down to gnd 
slower than the reset pin, so the bootloader will read it as one and start, and 
a few milliseconds later it will be pulled to zero. This is really useful for 
remote-programming with e.g. an RN41 based bluetooth-to-serial module, such as 
this one: https://www.sparkfun.com/products/10268

/Benjamin

Original issue reported on code.google.com by [email protected] on 26 Dec 2012 at 2:41

  • Merged into: #37

Attachments:

Flashing to incorrect address because ihex field type 0x05 not parsed 

What steps will reproduce the problem?
1. build program that placed at 0x08002000(not at default address - 0x08000000)
2. generate ihex with arm-elf-objcopy
3. try to write that .hex by stm32flash

What is the expected output?
flashing at address 0x08002000.

What do you see instead?
flashing at address 0x08000000.

What version of the product are you using?
last version from june 2011

On what operating system?
Linux, Arch, i686

Please provide any additional information below.
hex file and linker script attached

Original issue reported on code.google.com by [email protected] on 15 Jan 2012 at 11:14

Attachments:

Support for STM32W 

What steps will reproduce the problem?
1. Connect an STM32W board to Linux box (MB851)
2. Determine serial port to be /dev/ttyUSB0
3. Run stm32flash /dev/ttyUSB0

What is the expected output? What do you see instead?
Is is supposed to return the device information, but it doesn't.

What version of the product are you using? On what operating system?
Using current version of the code on OpenSUSE 11.4.

Please provide any additional information below.
I have changed the code so that it talks with the stm32w108cb that I have on 
hand. I was able to read the device information, read the flash to a file, and 
flash the device after it was placed in nBoot mode manually. To get it into the 
boot loader, just ground pin PA5.

Attached is a patch with the changes I made, the biggest difference is that 
this processor uses parity none and does not return write protection commands 
when 0x00 is sent to it. Hope this helps the improvement of the tool and that 
somehow it can be an argument to define if its an stm32w or not.

Great job so far.

Original issue reported on code.google.com by [email protected] on 31 Aug 2011 at 9:43

Attachments:

Broken link in http://code.google.com/p/stm32flash/ 

What steps will reproduce the problem?
1. Read http://code.google.com/p/stm32flash/
2. Follow link to http://stm32.spacevs.com/
3. get blank page

What is the expected output? What do you see instead?
"how to use this tool, or how to use the STM32 under Linux" <-> blank page

Original issue reported on code.google.com by [email protected] on 10 Jul 2012 at 10:25

erasing individual pages doesn't work on STM32F205 

What steps will reproduce the problem?
1. Try downloading to an STM32F205 chip (bootloader version 0x31) with the -S 
argument.

What is the expected output? What do you see instead?
It says "Page-by-page erase failed. Check the maximum pages your device 
supports." and then doesn't work. I am giving it a valid address.

What version of the product are you using? On what operating system?
16fbfe6e5854dc36f41712f60b2282cde7571afd Linux

Please provide any additional information below.
The attached patch fixes it.

Original issue reported on code.google.com by [email protected] on 18 Dec 2013 at 12:47

Attachments:

Does not support reading/writing stdin/stdout 

The stm32flash tool does not currently support reading to/from the stdout/stdin 
streams.

To use stdin/stdout, specify '-' as the filename. For device writes, the size 
of the input stream must be specified.

See attached patch that adds support for this behavior.

Original issue reported on code.google.com by [email protected] on 5 Jan 2012 at 8:09

Attachments:

Compilation under QNX 

There is one small issue when compiling this project under QNX 6.3.
QNX does not have non-posix CRTSCTS flag for setting hardware flow control. It 
has 2 flags "IHFLOW" and "OHFLOW" (input & output hardware control acordingly) 
instead.
To fix the issue you need to replace line 134 in file serial_posix.c
from 

h->newtio.c_cflag &= ~(CSIZE | CRTSCTS);

to

#ifdef __QNXNTO__
    h->newtio.c_cflag &= ~(CSIZE | IHFLOW | OHFLOW);
#else
    h->newtio.c_cflag &= ~(CSIZE | CRTSCTS);
#endif

Hope this helps someone.

Original issue reported on code.google.com by [email protected] on 26 Aug 2013 at 7:58

Add support for Readout Unprotect command 

Please consider adding support for the Readout Unprotect command. It is needed 
to program parts that have readout protection activated. E.g. needed to flash 
an ST-Link's chip.

To perform it one needs to send 0x92, 0x6D and then two ACKs should be returned.

Original issue reported on code.google.com by [email protected] on 27 Jul 2012 at 9:12

hangs if writing binary file on windows 

What steps will reproduce the problem?
1. flash a binary into fsm32 on win32
2.
3.

What is the expected output? What do you see instead?

stm32flash hangs in binary_read(), I think it's because 
read(st->fd, data, left) return 0 when it meets ctrl-Z(EOF char)

What version of the product are you using? On what operating system?

all versions on win32

Please provide any additional information below.

can simply fixed it by adding O_BINARY flag to open.

binary.c:46
st->fd = open(filename, O_RDONLY|O_BINARY);

Original issue reported on code.google.com by [email protected] on 7 Oct 2011 at 7:32

Unable to program STM32L15xx series microcontrollers...plus a patch 

After my last "patch", stm32flash was able to detect the STM32L15xx 
microcontrollers (such as the STM32L152RB, found on the Discovery L eval 
board), but I could not get it to program them.

Looking into it, the problem was the erasing that takes place first. These 
chips use a newer(?) erase protocol called Extended Erase, which thankfully, 
can be detected on an ad hoc basis. This means we can switch to programming the 
erase (mass and page-by-page) using the two-byte based method they require.

Not that my chip supports mass erase, but it's not a big issue, since it is so 
quick- takes around about 2.1 seconds to erase the whole chip and upload a 
small program.

I don't own anything that uses the extended erase *and* supports mass erase, so 
that part of the code is untested, but should work.

This patch also includes the fixes I did for detecting this class/subfamily of 
microcontrollers, making sure it dies if I can't positively identify the chip, 
along with a typo fix. You may well not need this unless you downloaded the 
software a while ago- just delete those lines as required.

Original issue reported on code.google.com by [email protected] on 10 Jul 2011 at 5:41

Attachments:

New feature: ability to skip empty pages 

It would be very useful to be able to skip programming empty flash pages 
(containing all 0xFF) that have been erased. This is useful when a "copy" of a 
chip is taken for production programming, allowing bootloaders and 
application(s) to all be programmed in one prodedure. The ST Windows 
programming tool (ST Flash Loader) supports this feature.

Original issue reported on code.google.com by [email protected] on 10 Jan 2012 at 9:30

STM32F2xx devices not supported 

The STM32F2xx devices are not currently supported.

These devices use a different flash layout to the other stm32 devices - they 
have a set of differently sized sectors rather than being able to erase by page.

Additionally, these devices use an erase-extended command which uses half-words 
rather than byte sized parameters.

See attached patch to add support for the STM32F2xx devices. This is tested on 
an STM32F205RCT6 device.

I have also added High-density VL, Medium-density ultra low-power, and 
STM32F4xx devices to the support table. Note that these are NOT tested.

Original issue reported on code.google.com by [email protected] on 5 Jan 2012 at 7:49

Attachments:

Latest svn revision works better than current stable 

Is there any reason the svn revision has not been pushed as the new stable?

I was trying to search for a different flasher, because it looks like my flash 
wasn't supported. In the end I decided to try the svn revision and it works 
nicely for my flash. I can't spot any bugs.

Original issue reported on code.google.com by [email protected] on 14 Sep 2013 at 11:39

Release builds do not work 

Build software in release mode causes code within assert() macros to be removed 
by the pre-processor. Since we are doing actual work, not just checking 
parameters in these macros, release builds don't work

Original issue reported on code.google.com by [email protected] on 23 Nov 2012 at 12:52

Not working on Mac OS X 10.8 

What steps will reproduce the problem?
1. Connect the STM32 and put it in bootloader mode
2. in the terminal : stm32flash /dev/tty.usbserial

And the result is : 

stm32flash - http://stm32flash.googlecode.com/

Serial Config: 57600 8E1
read_byte: Undefined error: 0
Assertion failed: (0), function stm32_read_byte, file stm32.c, line 90.
Abort trap: 6

I'm using the same version of the tool and the same STM32 on my macbook (10.7) 
and everything is working fine so I presume that's a Mac 10.8 problem.

I tried different baudrate but always the same problem.
No problem on windows (using VMWare) on the same computer with the ST Tool

Original issue reported on code.google.com by [email protected] on 26 Nov 2012 at 12:24

Patch to add support for STM32F2 and F4 

Attached is a patch for adding F2 and F4 to stm32flash.

Only the F4 part has been tested on a STM32F4 discovery board.

The serial timeout needed to be increased to accommodate the significant 
increase in the mass erase time.

Original issue reported on code.google.com by [email protected] on 6 Nov 2011 at 7:44

Attachments:

stm32 firmware: linker script and Makefile 

Hello,

  Your linker script does not work for me on a STM32F103 eval board from Olimex (STM32-103STK). I think flash address is wrong by default.

  Your Makefile also calls './bin_to_c.sh stmreset' which is missing.

  I have added to the Makefile hex format:
  arm-eabi-objcopy -O ihex stmreset.elf stmreset.hex

  I am looking forward to have your excellent project running here, but at the moment it is resisting me.

Best regards

Original issue reported on code.google.com by [email protected] on 9 Dec 2010 at 4:22

Mac OS X failure during flash 

What steps will reproduce the problem?
1. OS - Mac OS X Snow Leopard or Lion
2. latest svn - stm32flash
3. try flash

Does not matter what baud date I set. With python script for stm32 update, it 
works without any problem, so I guess there is some bug in stm32flash...

What is the expected output? What do you see instead?
100% success flash
-----------
./stm32flash -b 9600 -w firmware.bin /dev/tty.SLAB_USBtoUART
stm32flash - http://stm32flash.googlecode.com/

Using Parser : Raw BINARY
Serial Config: 9600 8E1
Version      : 0x22
Option 1     : 0x00
Option 2     : 0x00
Device ID    : 0x0410 (Medium-density)
RAM          : 20KiB  (512b reserved by bootloader)
Flash        : 128KiB (sector size: 4x1024)
Option RAM   : 15b
System RAM   : 2KiB

Wrote address 0x08000100 (0.43%) Wrote address 0x08000200 (0.86%) read_byte: 
Undefined error: 0
Assertion failed: (0), function stm32_read_byte, file stm32.c, line 94.

Original issue reported on code.google.com by [email protected] on 17 Mar 2012 at 7:23

tried the example ./stm32flash /dev/ttyS0 and no dice, then/dev/stlinkv2_1 gives this error 

/dev/stlinkv2_1: Inappropriate ioctl for device

What steps will reproduce the problem?
1. sudo ./stm32flash /dev/stlinkv2_1

What is the expected output? What do you see instead?
I expected the device version information.

What version of the product are you using? On what operating system?
STM32f0 Discovery board

Please provide any additional information below.
Ubuntu 64bit

Original issue reported on code.google.com by [email protected] on 9 Jun 2012 at 9:25

error: parser.h: No such file or directory 

Win7, MingGW 4.4, 4.6, mingw32-make output:

--- begin ---------------------------------------------------------
mingw32-make -C parsers
mingw32-make[1]: Entering directory `d:/build/stm/parsers'
gcc -g -Wall -c -I../ binary.c hex.c
ar r parsers.a        binary.o hex.o
ar: creating parsers.a
mingw32-make[1]: Leaving directory `d:/build/stm/parsers'
gcc -g -o stm32flash -I./ \
                main.c \
                utils.c \
                stm32.c \
                serial_common.c \
                serial_platform.c \
                parsers/parsers.a \
                stm32/stmreset_binary.c \
                -Wall
In file included from main.c:35:
parsers/binary.h:24:20: error: parser.h: No such file or directory
mingw32-make: *** [all] Error 1
--- end -----------------------------------------------------------

small fix in attachment.

Original issue reported on code.google.com by [email protected] on 9 Apr 2012 at 1:02

Attachments:

'merging' branch doesn't build on OS X. 

The attached patch fixes some build issues on OS X.

Note that when selecting baud rates, many posix systems (Linux, BSD, OS X) will 
happily accept any numeric value, not just the B* defines.

Original issue reported on code.google.com by [email protected] on 6 Dec 2012 at 7:42

Attachments:

Patch for additional serial speeds 

I can consistently get my boards to download at 921,600.

This patch adds in all the standard to 2,000,000.

The symptoms of going too fast are that it never initially connects. I have 
never had a corrupted download.

Original issue reported on code.google.com by [email protected] on 6 Nov 2011 at 3:31

Attachments:

Mac OS X Invalid argument 

What steps will reproduce the problem?
1. use ftdi chip as usbserial
2. command :  ./stm32flash /dev/tty.usbserial-A9WJB515
3. output:
Using Parser : Raw BINARY
/dev/tty.usbserial-A9WJB515: Invalid argument

my os is Mac os 10.8.

Original issue reported on code.google.com by [email protected] on 6 Dec 2013 at 9:14

use RTS and DTR connected to RESET and BOOT0 to enter bootloader mode 

this is not really an issue but since i didnt find any place else to go with 
this i post it here...

if anyone interested i can provide a patch for stm32flash which uses the RTS 
and DTS lines (connected to RESET and BOOT0) to put the STM32 into bootloader 
mode before programming. it can be enabled by a new command line option.

Original issue reported on code.google.com by [email protected] on 27 Nov 2012 at 8:30

Corrected (?) help information 

I believe the -w filename option writes filename to flash -- not the other way 
around.

Original issue reported on code.google.com by jakob.malm on 5 Sep 2012 at 7:50

Attachments:

Need pre-built Windows binaries 

#1 Please provide pre-built binary for Windows in the download section.

#2 Please list Windows requirements (which range of version of Windows that it 
should support), and which versions it has been tested.

#3 I added a link to this project in my new STM32 wikipedia article.
http://en.wikipedia.org/wiki/STM32#Development_tools

Thanks in advance!

Original issue reported on code.google.com by sbmeirow on 4 Dec 2011 at 1:59

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.