Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[STLinkV2]: unknown chip id! 0x466 #1283

Closed
5 of 6 tasks
Cypresslin opened this issue Dec 2, 2022 · 3 comments
Closed
5 of 6 tasks

[STLinkV2]: unknown chip id! 0x466 #1283

Cypresslin opened this issue Dec 2, 2022 · 3 comments

Comments

@Cypresslin
Copy link

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.

  • Programmer/board type: [STLINK V2] (e.g STLINK /V1, /V2, /V2-onboard, /V2-clone, /V3)
  • Operating system an version: [Ubuntu 22.04 ARM64] (e.g Linux, Windows)
  • stlink tools version and/or git commit hash: [git-f93adb92f] (e.g v1.6.1/git-d0416149)
  • stlink commandline tool name: [sf-flash] (e.g st-info, st-flash, st-trace, st-util)
  • Target chip (and board, if applicable): [enter here] (e.g STM32F103C8T6 (NUCLEO-F103RB))

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
@Nightwalker-87
Copy link
Member

Nightwalker-87 commented Dec 28, 2022

@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.

@Nightwalker-87
Copy link
Member

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.

@Cypresslin
Copy link
Author

Hello @Nightwalker-87

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 and happy new year!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
No open projects
Status: Done
Development

No branches or pull requests

2 participants