mleaf / stm32flash Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/stm32flash
Automatically exported from code.google.com/p/stm32flash
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:
Progress indicator did not work correctly on Windows. This simply uses CR to
set cursur to beginning of the line.
Original issue reported on code.google.com by [email protected]
on 9 Nov 2011 at 8:05
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:
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:
{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
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
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
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
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:
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
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
Empty space in HEX file is filled by 0x00 but should be 0xFF.
Original issue reported on code.google.com by [email protected]
on 15 Feb 2011 at 8:17
In serial_w32.c should be something like:
if(strlen(device)>4&&device[0]!='\\') sprintf(devName,"\\\\.\\%s",device);
else strcpy(devName,device);
h->fd = CreateFile(devName, ...
Original issue reported on code.google.com by [email protected]
on 15 Feb 2011 at 8:24
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
Attachments:
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:
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:
The attached patch adds support for the STM32 High Density Value Line devices.
(id 0x0428)
Original issue reported on code.google.com by [email protected]
on 8 Aug 2011 at 1:42
Attachments:
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
This is my script that seems to do the job.
Original issue reported on code.google.com by [email protected]
on 19 Nov 2013 at 9:44
Attachments:
Here is a list of patches with my improvements of stm32flash
1) fix memory write procedure in case when we write file to default location.
2) Fix memory erase proc (Extended Erase)
Original issue reported on code.google.com by [email protected]
on 18 Dec 2012 at 3:54
Attachments:
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:
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:
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
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
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
See attached patch which adds ability to (optionally) specify start address and
length of a read.
Original issue reported on code.google.com by [email protected]
on 5 Jan 2012 at 8:50
Attachments:
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:
If address in HEX file OR size of HEX file overruns magical limit of 64 KB then
application fails.
Original issue reported on code.google.com by [email protected]
on 15 Feb 2011 at 8:20
Hi,
I've fixed & added this to stm32flash:
* new reset code common for Cortex-M0, Cortex-M3, Cortex-M4(untested)
* support for STM32F3(untested) and STM32F0 family
* new option -o for erase only operation
* -e 0 option now work correctly
Greetings,
Daniel Strnad
Original issue reported on code.google.com by [email protected]
on 31 Oct 2012 at 8:05
Attachments:
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
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:
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
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
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
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:
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
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
In "stm32.c" line 53, the ram_start address for "Connectivity Line" devices is
listed as 0x20000200, but should be 0x20001000.
Original issue reported on code.google.com by [email protected]
on 2 Feb 2011 at 5:25
/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
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:
Is it possible to support dev.boards with auto-reset using TX-break and RTS/DTR
pulse signals ?
Original issue reported on code.google.com by [email protected]
on 26 Sep 2011 at 8:40
Here is a one-line patch to add support for stm32f030 microcontrollers. Tested
on stm32f030f4p6
Original issue reported on code.google.com by [email protected]
on 17 Dec 2013 at 9:50
Attachments:
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:
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:
can you put the circuit diagram to connect stm32 to pc for programming through
stm32 flash.
Original issue reported on code.google.com by [email protected]
on 20 Jul 2011 at 6:54
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
I tried source code with MinGW but produced code does not report any error
messages - simply dies without any message.
Original issue reported on code.google.com by [email protected]
on 15 Feb 2011 at 8:28
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
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:
#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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.