You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thank you for giving feedback to the stlink project.
NOTE: In order to offer sufficient and the best possible support, please read /CONTRIBUTING.md and follow the given instructions before submitting a ticket.
Bug reports and/or feature requests will be deleted, if they violate our contribution guidelines and if no issue-template is used! Thank you for your support.
I made serious effort to avoid creating duplicate or nearly similar issue
In order to allow developers to isolate and target your respective issue, please take some time to select the check boxes below and fill out each of the following items appropriate to your specific problem.
Further we kindly ask you to describe the detected problem as detailed as possible and to add debug output if available, by using the following template:
Commandline output:
ubuntu@ubuntu:~/stlink/build/Release/bin$ sudo ./st-flash write ~/addon_bootloader_v0010.bin 0x8000000
st-flash 1.7.0-217-gf93adb9
/usr/share//stlink/chips: No such file or directory
2022-12-02T15:18:11 WARN common.c: unknown chip id! 0x466
Failed to connect to target
Expected/description:
Flash process can ends successfully with: Flash written and verified! jolly good!
This issue is similar to issue #850, and does not exist with v1.7.0. Bisect shows this is the possible cause:
commit 14498bb3c011c70d5ba66f26de2a8c11eed68b8d
Author: nightwalker-87 <15526941+Nightwalker-87@users.noreply.github.com>
Date: Sun Jan 9 16:39:54 2022 +0100
Restructuring of STM32 definitions
- Moved enum stlink_stm32_chipids to stm32.h
- Moved additional MCU defines to stlink.h
- Minor formatting improvements
- Commented comparison for old/new chipid db
inc/stlink.h | 4 ++
inc/stm32.h | 118 +++++++++++++++++++++++++++++++++++++++---------
src/stlink-lib/chipid.c | 69 ++++++++++++++--------------
src/stlink-lib/chipid.h | 77 ++-----------------------------
Here is the bisect log:
$ git bisect log
git bisect start
# bad: [f93adb92f2e4ecf05a9361cb723c98693586929d] Fixes for project compilation
git bisect bad f93adb92f2e4ecf05a9361cb723c98693586929d
# good: [179650df40295b0af3a148ddfb2c467a0334f54a] Release v1.7.0
git bisect good 179650df40295b0af3a148ddfb2c467a0334f54a
# good: [7c4ad1c14df80a872d2c50a8caead65bce435e16] Merge pull request #1181 from gszy/chip-files
git bisect good 7c4ad1c14df80a872d2c50a8caead65bce435e16
# bad: [e5cc884c7fe1e0e742b32dac58faa76a8c5855a9] Merge pull request #1216 from stlink-org/chipid_cleanup
git bisect bad e5cc884c7fe1e0e742b32dac58faa76a8c5855a9
# bad: [115f7c846adf612c1ee818713530dbf17287ed9b] Transition to new enum stm32_chipids
git bisect bad 115f7c846adf612c1ee818713530dbf17287ed9b
# good: [e97f438075ff5128630dfa3668f6ac7bd1181c51] Merge pull request #1197 from c-grant/develop
git bisect good e97f438075ff5128630dfa3668f6ac7bd1181c51
# good: [7cc1fdae6b0c48f96f4f3155786305ac0cde0d87] Merge pull request #1207 from Crest/freebsd
git bisect good 7cc1fdae6b0c48f96f4f3155786305ac0cde0d87
# good: [f55dd8d08f5cd414b9569b8d16a0f7841cec6db9] [refactoring] Clean-up for chipid files (L1, L4)
git bisect good f55dd8d08f5cd414b9569b8d16a0f7841cec6db9
# bad: [5cde863c0382d92ca0d6ea027a7a3b24926a44e0] Switch-over to new chip-files
git bisect bad 5cde863c0382d92ca0d6ea027a7a3b24926a44e0
# bad: [14498bb3c011c70d5ba66f26de2a8c11eed68b8d] Restructuring of STM32 definitions
git bisect bad 14498bb3c011c70d5ba66f26de2a8c11eed68b8d
# first bad commit: [14498bb3c011c70d5ba66f26de2a8c11eed68b8d] Restructuring of STM32 definitions
This is my lsusb -v output of the stilink-v2 device:
Bus 001 Device 006: ID 0483:3748 STMicroelectronics ST-LINK/V2
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0483 STMicroelectronics
idProduct 0x3748 ST-LINK/V2
bcdDevice 1.00
iManufacturer 1 STMicroelectronics
iProduct 2 STM32 STLink
iSerial 3 9ÿfBC88%2!W
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0027
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 4
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
The text was updated successfully, but these errors were encountered:
@Cypresslin Thanks for reporting. I've had a look at the respective commit, but couldn't detect the bug.
The mentioned chip-id has not vanished and should be detected correctly...
/usr/share//stlink/chips: No such file or directory
This looks as if the chip configuration files were not correctly installed.
Please clean-up your installation (make uninstall & make clean) and retry with make install, preferably with commit 14498bb. Then check if the directory /usr/share/stlink/chips is present and contains .chip files.
Please report back in order to resolve this issue.
This is not a chip-specific issue.
The output message /usr/share//stlink/chips: No such file or directory indicates a compilation bug regarding the installation path of the .chip configuration files used to detect MCU devices.
This bug has been fixed in commit f93adb9.
The correct installation path is /usr/share/stlink/chips.
In order to resolve this, please clean-up your installation with make uninstall, then make clean, preferably check out the latest commit on the develop branch and proceed with make install.
I have this tested with the latest tip 45b846bac on the develop branch,
and it looks like it's working well with this version.
$ st-flash write ~/addon_bootloader_v0010.bin 0x8000000
st-flash 1.7.0-231-g45b846b
Failed to parse flash type or unrecognized flash type
2022-12-29T15:47:29 INFO common.c: STM32G03x_G04x: 8 KiB SRAM, 32 KiB flash in at least 2 KiB pages.
2022-12-29T15:47:29 WARN common_flash.c: Flash base use default L0 address
file /home/ubuntu/addon_bootloader_v0010.bin md5 checksum: 5dd3d0b322903fc8d93c21756ca16035, stlink checksum: 0x000e823b
2022-12-29T15:47:29 INFO common_flash.c: Attempting to write 10564 (0x2944) bytes to stm32 address: 134217728 (0x8000000)
-> Flash page at 0x8000000 erased (size: 0x800)
-> Flash page at 0x8000800 erased (size: 0x800)
-> Flash page at 0x8001000 erased (size: 0x800)
-> Flash page at 0x8001800 erased (size: 0x800)
-> Flash page at 0x8002000 erased (size: 0x800)
-> Flash page at 0x8002800 erased (size: 0x800)
2022-12-29T15:47:29 INFO flashloader.c: Starting Flash write for WB/G0/G4
4/ 5 pages written
2022-12-29T15:47:30 INFO common_flash.c: Starting verification of write complete
2022-12-29T15:47:30 INFO common_flash.c: Flash written and verified! jolly good!
Thank you for giving feedback to the stlink project.
NOTE: In order to offer sufficient and the best possible support, please read /CONTRIBUTING.md and follow the given instructions before submitting a ticket.
Bug reports and/or feature requests will be deleted, if they violate our contribution guidelines and if no issue-template is used! Thank you for your support.
In order to allow developers to isolate and target your respective issue, please take some time to select the check boxes below and fill out each of the following items appropriate to your specific problem.
st-info
,st-flash
,st-trace
,st-util
)Further we kindly ask you to describe the detected problem as detailed as possible and to add debug output if available, by using the following template:
Commandline output:
Expected/description:
Flash process can ends successfully with: Flash written and verified! jolly good!
This issue is similar to issue #850, and does not exist with v1.7.0.
Bisect shows this is the possible cause:
Here is the bisect log:
This is my lsusb -v output of the stilink-v2 device:
The text was updated successfully, but these errors were encountered: