Hello!
st-link driver 1.1.0.0 install from STM32 ST-LINK Utility v4.5.0.exe
using firmware iss.bin size 131384 bytes
try WinUSB (v6.1.7600.16385) driver, same result
Commandline-Output:
C:\VSARM/stlink/bin/st-flash write ./build/iss.bin 0x08000000 <
st-flash 1.6.1
2020-06-18T14:25:57 INFO common.c: F1xx High-density: 64 KiB SRAM, 256 KiB flash in at least 2 KiB pages.
mmap() size_t overflow for file ./build/iss.bin
2020-06-18T14:25:57 ERROR common.c: map_file() == -1
stlink_fwrite_flash() == -1
The terminal process terminated with exit code: 1
Expected/description:
the flashing was success , when i use stlink-1.5.1 from https://github.com/texane/stlink
C:\VSARM/stlink/bin/st-flash write ./build/iss.bin 0x08000000 <
st-flash 1.5.1
2020-06-18T14:34:50 INFO common.c: Loading device parameters....
2020-06-18T14:34:50 INFO common.c: Device connected is: F1 High-density device, id 0x10036414
2020-06-18T14:34:50 INFO common.c: SRAM size: 0x10000 bytes (64 KiB), Flash: 0x40000 bytes (256 KiB) in pages of 2048 bytes
2020-06-18T14:34:50 INFO common.c: Attempting to write 131384 (0x20138) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08020000 erased
2020-06-18T14:34:52 INFO common.c: Finished erasing 65 pages of 2048 (0x800) bytes
2020-06-18T14:34:52 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2020-06-18T14:34:52 INFO flash_loader.c: Successfully loaded flash loader in sram
65/65 pages written
2020-06-18T14:34:57 INFO common.c: Starting verification of write complete
2020-06-18T14:34:58 INFO common.c: Flash written and verified! jolly good
@imyaFamiliev, Can you provide some information about the issue you complain?
@imyaFamiliev, please provide the size of ./build/iss.bin
@imyaFamiliev: Please use the Template form you just deleted and fill it out. Otherwise I may simply discard this ticket - I'm fed up with this - really. We have so clear instructions on how to open issues properly and most people seem able to understand these.
iss.bin 131384 bytes
ok, message will be fixed.
Please follow #906.
Does this already occur with Release v1.6.0?
try WinUSB (v6.1.7600.16385) driver, same result
Don't use external drivers along with this stlink-toolset; this is not expected to work anyway.
@Nightwalker-87 don't see windows release build of v1.6.0
I will try to compile and check.
oh, yeah - that's right. Please follow /doc/compiling.md for windows and make sure to cleanly remove the newer version beforehand. Release v1.6.1 was the first release after a long period to distribute windows builds.
1.6.0 flashes ok
C:\VSARM\/stlink/bin/st-flash write ./build/iss.bin 0x08000000 <
st-flash 1.6.0
2020-06-18T15:26:57 INFO common.c: Loading device parameters....
2020-06-18T15:26:57 INFO common.c: Device connected is: F1 High-density device, id 0x10036414
2020-06-18T15:26:57 INFO common.c: SRAM size: 0x10000 bytes (64 KiB), Flash: 0x40000 bytes (256 KiB) in pages of 2048 bytes
2020-06-18T15:26:57 INFO common.c: Attempting to write 131384 (0x20138) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08020000 erased
2020-06-18T15:26:58 INFO common.c: Finished erasing 65 pages of 2048 (0x800) bytes
2020-06-18T15:26:58 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2020-06-18T15:26:58 INFO flash_loader.c: Successfully loaded flash loader in sram
65/65 pages written
2020-06-18T15:27:04 INFO common.c: Starting verification of write complete
2020-06-18T15:27:05 INFO common.c: Flash written and verified! jolly good!
st-flash from stlink-1.6.1-i686-w64-mingw32.zip work well.
the problem occurs on st-flash from stlink-1.6.1-x86_64-w64-mingw32.zip
@imyaFamiliev which toolchain you use to build st-link? It is 64 or 32 bit one?
for 1.6.0 i use x86_64-5.3.0-win32-sjlj-rt_v4-rev0 as used in mingw64-build.bat
1.6.1 version I downloaded as is stlink-1.6.1-x86_64-w64-mingw32.zip
check stlink-1.6.1-i686-w64-mingw32.zip - work fine
i have Intel(R)_Core(TM)_i5-8400_CPU
st-flash from stlink-1.6.1-i686-w64-mingw32.zip work well.
the problem occurs on st-flash from stlink-1.6.1-x86_64-w64-mingw32.zip
This could be somehow similar to the casting issues we faced with clang on macOS earlier, just in another context ...
This could be somehow similar to the casting issues we faced with clang on macOS earlier, just in another context ...
It seems to be caused by a size check combined with a cast somewhere