search

stlink-org / stlink

Open source STM32 MCU programming toolset
BSD 3-Clause "New" or "Revised" License
4.45k stars 1.24k forks source link

[feature] STLINK-V3 programmer support #820

Closed WRansohoff closed 3 years ago

WRansohoff commented 5 years ago

Output:

[Time] WARN usb.c: Couldn't find any ST-Link/V2 devices

Expected/description:

The utility should connect to the device. I'm not sure how different these new ST-Link bridges are from the old ones, but hopefully things won't look too different. ST has a marketing blog post describing the new debuggers, but the technical information might be more spread out:

https://blog.st.com/stlink-v3set-in-circuit-debugger-programmer/

Sorry if this has already been added - I tried st-util -s 3, but I got: stlink version 3 unknown!

unclebanjoman commented 5 years ago

I also have a serious problem. I just bought a brand new STLINK-V3SET programmer / debugger original from StMicro.

The st-info utility discovers and manage my new STM32F746G-Discovery board without problems. When I plug my new STLINK-V3SET programmer, executing the command:

./st-info --probe

I only obtain:

"Found 0 stlink programmers."

I've already put the appropriate file in /etc/udev/rules.d (filename: 49-stlinkv3.rules). Issuing the lsusb -v command I get the following:

mmazza@linux9:~/ARMtoolchains/stlink-master/build/Release$ lsusb -v

Bus 005 Device 003: ID 0483:374f STMicroelectronics Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize0 64 idVendor 0x0483 STMicroelectronics idProduct 0x374f bcdDevice 1.00 iManufacturer 1 STMicroelectronics iProduct 2 ST-LINK/V3 iSerial 3 005200363137510239383538

Any ideas? I'm really stuck. Thanks in advance, Max
xkwy commented 5 years ago

I have the same request.

Is there any one shall do something for support STLINK-V3SET? Please.

mhnsn commented 5 years ago

Same as @unclebanjoman, on Ubuntu 18.04 LTS, my system detects the V3 probe, but st-info --probe returns 0 devices. I'll look into this some, but I can't promise anything.

nife87 commented 5 years ago

I have the same request. I love using "make flash" in Makefiles, but I kinda also love the new v3. My concrete error (Windows 10, Cygwin) with the STLINK-V3SET connected (and usable using STM32CubeProgrammer as well as using STLINK Utility): st-flash --reset write bin/X.bin 0x8000000 st-flash 1.3.0 2019-10-09T22:56:02 WARN C:\Users\Jerry\Desktop\stlink-master\src\usb.c: Couldn't find any ST-Link/V2 devices

martonmiklos commented 4 years ago

Hey folks!

I have managed to patch the sources to get my STLink V3 mini recognised and initialised.

To be honest I remembered that it is just the matter of adding PIDs and configuring the proper endpoints. Well it was not that simple, but thanks to Antonio Borneo's great work on openOCD I managed to go through the differences easier.

My code lives here: https://github.com/martonmiklos/stlink/pull/new/add_stlink_v3_support

I have not managed to test it (I have a mini at home but no device with 1.27 pitch JTAG conn). Feel free to test it (it should work, since the most difference was in the initialisation) and report.

Nightwalker-87 commented 4 years ago

@WRansohoff: Are you interested in testing it by checking out the current develop branch?

WRansohoff commented 4 years ago

I can take a look when I have access to one of the newer boards again. But that might be a couple of weeks from now, so maybe someone else can beat me to it :)

Thanks for patching this in!

kioan commented 4 years ago

I have an stlink-v3 and I could help you with testing. I compiled your code and connected my stlink-v3 programmer to a bluepill (stm32f103c8) board.

$ ./st-info --version
v1.6.0

$ ./st-info --probe
Found 1 stlink programmers

$ ./st-info --flash
0x10000

$ ./st-info --sram
0x5000

$ ./st-info --descr
F1 Medium-density device

$ ./st-info --pagesize
0x400

$ ./st-info --chipid
0x0410

$ ./st-info --serial
303034323030314633313337353130413339333833353338

$ ./st-info --hla-serial
"\x30\x30\x34\x32\x30\x30\x31\x46\x33\x31\x33\x37\x35\x31\x30\x41\x33\x39\x33\x38\x33\x35\x33\x38"

Runnning st-flash throws some errors as you can see bellow.

Erase seemed to succeed and it erased already running chip:

$ ./st-flash erase
st-flash 1.6.0
2020-02-26T11:27:37 INFO usb.c: Unable to match requested speed 1800 kHz, using 1000 kHz
2020-02-26T11:27:37 INFO common.c: Loading device parameters....
2020-02-26T11:27:37 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2020-02-26T11:27:37 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
  core status: unknown
Mass erasing

I then reprogrammed the chip usint the STM32CubeProgrammer and tried reading and writing back using your stlink version.

Reading the chip throws errors:

$ ./st-flash read /tmp/saved.img 0x8000000 0x1000
st-flash 1.6.0
2020-02-26T11:24:35 INFO usb.c: Unable to match requested speed 1800 kHz, using 1000 kHz
2020-02-26T11:24:35 INFO common.c: Loading device parameters....
2020-02-26T11:24:35 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2020-02-26T11:24:35 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
  core status: unknown

And also errors when trying to write back to the chip:

$ ./st-flash write /tmp/saved.bin 0x8000000
st-flash 1.6.0
2020-02-26T12:30:40 INFO usb.c: Unable to match requested speed 1800 kHz, using 1000 kHz
2020-02-26T12:30:40 INFO common.c: Loading device parameters....
2020-02-26T12:30:40 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2020-02-26T12:30:40 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
  core status: unknown
2020-02-26T12:30:40 INFO common.c: Ignoring 3396 bytes of 0xff at end of file
2020-02-26T12:30:40 INFO common.c: Attempting to write 700 (0x2bc) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000000 erased
2020-02-26T12:30:40 INFO common.c: Finished erasing 1 pages of 1024 (0x400) bytes
2020-02-26T12:30:40 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2020-02-26T12:30:40 INFO flash_loader.c: Successfully loaded flash loader in sram
  core status: unknown
  core status: unknown
  core status: unknown
  core status: unknown
  core status: unknown
  core status: unknown
  core status: unknown

---- multiple lines trimmed ----

  core status: unknown
  core status: unknown
2020-02-26T12:30:41 ERROR flash_loader.c: flash loader run error
2020-02-26T12:30:41 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1
stlink_fwrite_flash() == -1

If you want me to run specific tests, please guide me and I will do so.

Nightwalker-87 commented 4 years ago

I would suggest to test common use cases and tasks which can be achieved with the stlink toolset, just as we expect these to work with the stlink-v2 programmer already supported. It seems not a problem if any additional feature may not yet be fully functional, but the main functions should turn out to be in a working state. @kioan @WRansohoff @martonmiklos: Maybe you can discuss some more specific tests with each other and also consult our documentation and "How-To" for some ideas. I'll jump into this in a few days as well.

martonmiklos commented 4 years ago

I will swipe together the necessary stuff to be able to debug during execution. It is going to be the most easier and efficient I think. Many thanks to @WRansohoff and @kioan for performing the tests.

kioan commented 4 years ago

I am a little newbie to github etc, so if someone could give me some guidelines it would be really helpful.

My system is running Debian. Is there any way to create the debian package in order to install it? This would allow me to test it using the environment I was already using (I have just started learning STM32 development using the Warren Gay book so I use his makefiles as a basic structure)

Nightwalker-87 commented 4 years ago

@kioan: You may find it helpful to have a look in /doc/compiling as a first step and see how far you get. Unfortunately it's not completely up to date, but as I'm trying to do my very best - here is a "quick-and-dirty" update to it, to help you along:

1) Fork the repo on the main project page: https://github.com/texane/stlink 2) Clone/Download shows a git-link which you should copy to the clipboard. 3) Create a new local folder for your git-Projects and make sure you have the package git installed, which I assume is already the case 4) cd into the new folder via the terminal and then type git clone $pasted_link 5) Make sure to have the following packages installed:

... and then proceed with the instructions. Please let us know if you run into trouble. ;-)

kioan commented 4 years ago

Thank you! In case someone else like me wants to follow this procedure, right after cloning (step 4) they should checkout the development branch and compile that instead of the main. That can be done by running git branch -a to show all branches followed by git checkout remotes/origin/develop which is the branch with stlinkv3 support

I have created successfully the debian packages and installed them. I tried the makefiles that used to work with the stlinkv2 programmer but I get the same errors I mentioned before. At least now I know that I can test your future patches.

Nightwalker-87 commented 4 years ago

Yes, you are right - I forgot to mention that everybody is strongly encouraged to work with the develop branch.

Nightwalker-87 commented 4 years ago

See also #863.

WRansohoff commented 4 years ago

Okay, I scrounged up an STM32G431 "Nucleo" board which has an "STLINK-V3E" debugger and tried it out with the 'develop' branch. They use an STM32F723 in the debugger! Too bad they don't make more of that chip's pins available on the board, huh?

Anyways, I can flash the chip with a simple 'blinking LED' program using st-flash, and that program runs without error after it is flashed.

The problems start when I upload a program that uses interrupts; things work fine when the 'blinking LED' program uses a 'while' loop to delay between LED toggles, but when it uses the SysTick interrupt, ST-Link does not seem to be able to connect to the debugger afterward the initial program upload. I get all kinds of unusual errors, from "unknown chip ID" to "failed to unlock flash" to "verification of flash failed".

Maybe the debugger is failing to hold the chip in a reset state for long enough, or failing to disable interrupts once it is pulled into a debugging state? Sorry that I don't know enough about the inner workings to make a more educated guess. To get the board back to a working state, I needed to perform a mass erase using one of the utilities distributed by ST.

I get similar errors to what @kioan reported when I try to open a debugging connection with st-util. The connection appears to open successfully, but when I connect to the target in GDB, it does not provide reliable data and the st-util application prints a bunch of "core status: unknown" messages.

So that's what happens when I test the current "develop" branch with an STLink-V3, but it definitely looks like a promising start! And sorry for the delayed response; I've been moving lately, so most of my microcontroller stuff is packed away.

Nightwalker-87 commented 4 years ago

Hey! How are you getting along?

medicalwei commented 4 years ago

Would giving the capture using Wireshark and usbmon using STM32CubeProg help in anyway?

I am getting the same result as https://github.com/texane/stlink/issues/820#issuecomment-591358679 using STLINK-V3SET, but can be programmed through CLI of STM32CubeProg. I can't use their GUI due to missing library.

Ant-ON commented 4 years ago

OpenOCD in latest source read DCB DHCSR register to retrieve status https://github.com/ntfreak/openocd/blob/bff1b6f05a56eed8e150c25d925bd51ca2840daf/src/jtag/drivers/stlink_usb.c#L1743

May be it fix problem "core status: unknown"

martonmiklos commented 4 years ago

Hi guys,

I apologise for the late reply. I still not managed to debug the whole thing physically.

@medicalwei I think it is not necessary at the moment, I have the equipment at my workplace and home so if I find time to work on this I can debug this.

@Ant-ON OpenOCD Stlink support was written using NDA protected documentation from ST, so that's my plan: if I isolate the problematic points I will take a look on the OpenOCD code. (The changes what I added was based on that too.)

Nightwalker-87 commented 4 years ago

@martonmiklos: No problem, take the time it needs. We are not in a hurry. I just asked to stay on track.

lvdlvd commented 4 years ago

I have an STM32H745 Nucleo-144 board which comes with a STLINK-V3E. is there information i can dig out or things to test to help you all get that to work?

Nightwalker-87 commented 4 years ago

@lvdlvd: Thx, for raising interest - though you throw in a slightly inconvenient combination. We currently neither support the STM32H7 nor the STLINK-V3... :-D ,

BUT both are in fact planned features with available open issues. I currently can hardly tell what of both is more challenging to implement. If someone familiar with the H7 steps up and is willing to contribute and thus get it supported, I can change the current release planning for that. You guys tell me what you prefer and I can correspond to the demand. And as always - any help is welcome. :+1:

lvdlvd commented 4 years ago

i think getting the stlink v3 on that thing to work with a bluepill would be a valid first step, then once that works i could look into the H7.

i'll need some weekends to get up to speed in your codebase.

Op ma 30 mrt. 2020 om 01:01 schreef nightwalker-87 <notifications@github.com

:

@lvdlvd https://github.com/lvdlvd: Thx, for raising interest - though you throw in an slightly inconvenient combination. We currently neither support the STM32H7 nor the STLINK-V3... :-D ,

BUT both are in fact planned features with available open issues. I currently can hardly tell what of both is more challenging to implement. If someone familiar with the H7 steps up and is willing to contribute and thus get it supported, I can change the current release planning for that. You guys tell me what you prefer and I can correspond to the demand. And as always - any help is welcome. 👍

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/texane/stlink/issues/820#issuecomment-605715609, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACIGIC7VBB7BSZU6F7RZC5TRJ7HN7ANCNFSM4IG5F6WA .

Nightwalker-87 commented 4 years ago

@lvdlvd: ok, take your time. Indeed the recent weeks have been quite busy on this project with lots of things to work up from the past. I hope to get rid of the remaining leftovers soon so we can look forward...

martonmiklos commented 4 years ago

Okay: starting from the very first issue reported by @kioan core status: unknown

By peeking into the openOCD code it turns out that different status query method is used in the case if the supported JTAG API is over 1: https://github.com/ntfreak/openocd/blob/master/src/jtag/drivers/stlink_usb.c#L1789

If you peek into the JTAG API determination in openOCD it turns out that it is not that simple that StLinkV2 uses V2 API, but a V1 it as well after a certain JTAG version: https://github.com/ntfreak/openocd/blob/master/src/jtag/drivers/stlink_usb.c#L989

I always get an impression that we could be on the easier side if we would wrap the openOCD code directly. :smile:

chenguokai commented 4 years ago

@martonmiklos

I always get an impression that we could be on the easier side if we would wrap the openOCD code directly. 😄

I am afraid that we cannot. stlink is licensed under BSD while openocd is under GPLv2 and later. This means, if we wrap any code from openocd, the project will have to be GPLed, or at least be under mixed licenses which I am doing a clean room to remove.

martonmiklos commented 4 years ago

Yeah I understand that. But by looking the amount of hacks implemented in OpenOCD (and knowing the fact that they have access to ST materials) always makes me hard time to justify spending my free time on the project.

Nightwalker-87 commented 4 years ago

Also keep in mind that development on OpenOCD appears to have stalled somewhen in 2017. If we want this feature with a BSD-3 compatible approach, we would need somebody to spend some efforts on this (which may be more time consuming).

martonmiklos commented 4 years ago

Well I would argue that the development of OpenOCD had been stalled: the STLinkV3 support was added last year, and if you do a blame on the https://github.com/ntfreak/openocd/blame/master/src/jtag/drivers/stlink_usb.c you will see that there is active work on that.

But anyway, I will hack the V3 to work if I started once! I have managed to get around the core status query, the read, erase of my bluepill works now.

Nightwalker-87 commented 4 years ago

Well I would argue that the development of OpenOCD had been stalled: the STLinkV3 support was added last year, and if you do a blame on the https://github.com/ntfreak/openocd/blame/master/src/jtag/drivers/stlink_usb.c you will see that there is active work on that.

Interesting to see that. My statement pointed to the official project page.

martonmiklos commented 4 years ago

Anyone has any idea about why a flash loader would not hit a breakpoint?

martonmiklos commented 4 years ago

Ah we are arriving...:

        h->cmdbuf[h->cmdidx++] = STLINK_DEBUG_COMMAND;
    if (h->version.jtag_api == STLINK_JTAG_API_V1)
        h->cmdbuf[h->cmdidx++] = STLINK_DEBUG_APIV1_WRITEREG;
    else
        h->cmdbuf[h->cmdidx++] = STLINK_DEBUG_APIV2_WRITEREG;
Igorbunow commented 4 years ago

After update stlink v2.1 in version "V2J36M26 STM32 Debug+VCP" it have been recognized with stvink v3 pid id:

Bus 003 Device 010: ID 0483:3752 STMicroelectronics ST-LINK/V2.1

and don't recognized by st-util:

$ st-util -s 3
stlink version 3 unknown!
martonmiklos commented 4 years ago

@Igorbunow FYI: that 's not a V3 PID but a V2.1 no MSD: https://github.com/ntfreak/openocd/blob/master/src/jtag/drivers/stlink_usb.c#L73

martonmiklos commented 4 years ago

In the case if anyone interested t he write mem 32 functionality is broken (this is why the loaded did not get loaded), and I could not figure out the difference between the OpenOCD and this tool yet (and I need to get some sleep now).

If anyone wants to look into it here are the codes: https://github.com/ntfreak/openocd/blob/master/src/jtag/drivers/stlink_usb.c#L2266 https://github.com/martonmiklos/stlink/blob/add_stlink_v3_support/src/usb.c#L291

Since I added send_recv into the _stlink_usb_write_mem32 I always got libusb timeout issues. So I overlooked something.

Nightwalker-87 commented 4 years ago

Could somebody please assist @martonmiklos with this topic in general? I think this topic should deserve at least two contributors actively working on it if we want it to be fully addressed within the next few weeks and see a proper implementation in the next release.

Ant-ON commented 4 years ago

@martonmiklos You add send_recv and so you send command and try read 32bit data from stlink instead write it. Stlink device wait data, but we try read it. I think need back to:

int _stlink_usb_write_mem32(stlink_t *sl, uint32_t addr, uint16_t len) {
    /* data must be a multiple of 4 and word aligned */
    if (len % 4 || addr % 4) {
        printf("[!]Invalid data alignment");
        return -1;
    }

    struct stlink_libusb * const slu = sl->backend_data;
    unsigned char* const data = sl->q_buf;
    unsigned char* const cmd  = sl->c_buf;
    int i, ret;

    i = fill_command(sl, SG_DXFER_TO_DEV, len);
    cmd[i++] = STLINK_DEBUG_COMMAND;
    cmd[i++] = STLINK_DEBUG_WRITEMEM_32BIT;
    write_uint32(&cmd[i], addr);
    write_uint16(&cmd[i + 4], len);
    ret = send_only(slu, 0, cmd, slu->cmd_len);
    if (ret == -1)
        return ret;
    ret = send_only(slu, 1, data, len);
    if (ret == -1)
        return ret;

    return _stlink_usb_get_rw_status(sl);
}
martonmiklos commented 4 years ago

@Ant-ON you are correct with it, I have overlooked the OpenOCD behaviour.

I have found difference in OpenOCD in the run command as well what I implemented, but the core still not halted.

Strangely the Debug Halting Control and Status Register is always remain 0x90001 with V3 while with V2 it starts with 0x41001 ands sets to 0x43003 when the core is halted.

Ant-ON commented 4 years ago

@martonmiklos perhaps you are debugging differents core. This value has a clear meaning for Cortex-M3 DHCSR (and some other core same).

I looked at the code a few more times, but could not find critical differences.

May be try check read loader configuration register after write? (it is check correct register read/write operation) Also may try read PC register after each try of read core state. May be core is halted but we don't get real core status.

Minor comments. It's break V1 support, I think need return 0.

int _stlink_usb_get_rw_status(stlink_t *sl)
{
    if (sl->version.jtag_api == STLINK_JTAG_API_V1)
        return -1;
...
}

In original stlink code second call send_only has a second argument value of 1. It may break V1 support (if it work still...).


int _stlink_usb_write_mem32(stlink_t *sl, uint32_t addr, uint16_t len) {
...
    ret = send_only(slu, 0, cmd, slu->cmd_len);
    if (ret == -1)
        return ret;
    ret = send_only(slu, 0, data, len);
    if (ret == -1)
        return ret;
...
}
Nightwalker-87 commented 4 years ago

Let me please ask again to merge in the current changes from develop into the related PR. We tend to look at issues that also have been somehow addressed or edited by @grevaillot or may be related to recent changes from him that are already merged. I would not like to see the related PR along with it's branch drifting away from develop any further I am not willing to resolve the existing conflicts as I am already loosing track of what change-diff to take from which branch.

martonmiklos commented 4 years ago

@Nightwalker-87 FYI: the merge did not solved the problem.

Nightwalker-87 commented 4 years ago

Well it did solve the merge conflict at least and ensures this branch is with the latest codebase. There could have been a relation though. I was not able to rule that out at the time of writing.

martonmiklos commented 3 years ago

Hi folks!

I started to work on this again, but I got surprised: I managed to program a bluepill with my V3 from the develop branch.

I have checked the usb.c file (where most of the V3 implementation was done), but I do not even see my merged commit in the blame, and as I see many things changed there. Other than the st-link code changes I also need to note that my V3 firmware had been updated several times since I last worked on this. For reference I am using V3J6M2B4S1 version.

So folks, please test your V3 gear with various MCUs and if all jolly good close this issue :smiley:

martonmiklos commented 3 years ago

FYI: I have checked out my original commit in which the flash programming failed, and now it works OOTB, so it should be an improvement in the V3 firmware. We could either do a downgrade one-by-one in the V3 firmwares and chech which point will it fail, or to put simply we could implement a version check to enforce that the users should run at least V3J6M2B4S1 version.

~And BTW. we should also pimp the output of the st-info a bit to print out the STLink hardware and firmware version as well before we say that this feature is complete.~

Nightwalker-87 commented 3 years ago

Hi @martonmiklos. Yes there have been a few contributions since then. @ all: Please check the current develop branch with your V3 ST-LINK programmer hardware and suggest further improvements that appear to be necessary. Also check your programmer firmware and report if this feature is working with the respective version. I'd like to close this feature-topic as well, but would prefer to do this with a final PR to be able to attach all related issues to it.

lvdlvd commented 3 years ago

thanks for all your work. i realize i'm on this thread because i thought i'd have time to contribute but poof... a year flew by.

least i can do is help you test: just programming a bluepill with something I had lying around.

on master i get

$ ../stlink/build/Release/bin/st-flash --format ihex write main.hex st-flash 1.6.1-1-gbaab8ca 2020-12-20T20:51:36 INFO common.c: F1xx Medium-density: 20 KiB SRAM, 64 KiB flash in at least 1 KiB pages. 2020-12-20T20:51:36 INFO common.c: Attempting to write 21860 (0x5564) bytes to stm32 address: 134217728 (0x8000000) 2020-12-20T20:51:36 INFO common.c: Flash page at addr: 0x08000000 erased [.... bunch of similar lines deleted ....] 2020-12-20T20:51:37 INFO common.c: Flash page at addr: 0x08005400 erased 2020-12-20T20:51:37 INFO common.c: Finished erasing 22 pages of 1024 (0x400) bytes 2020-12-20T20:51:37 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id 2020-12-20T20:51:37 INFO flash_loader.c: Successfully loaded flash loader in sram 22/22 pages written 2020-12-20T20:51:38 INFO common.c: Starting verification of write complete 2020-12-20T20:51:38 INFO common.c: Flash written and verified! jolly good!

$ ../stlink/build/Release/bin/st-info --probe Found 1 stlink programmers serial: 303636464646353335353530373535313837323434313430 hla-serial: "\x30\x36\x36\x46\x46\x46\x35\x33\x35\x35\x35\x30\x37\x35\x35\x31\x38\x37\x32\x34\x34\x31\x34\x30" flash: 0 (pagesize: 0) sram: 0 chipid: 0x0004

yet on develop:

$ ../stlink/build/Release/bin/st-flash --format ihex write main.hex st-flash 1.6.1-197-g4918223 2020-12-20T20:55:35 WARN common.c: Invalid flash type, please check device declaration

Luuks-new-mbp:stm32f103_adc2serial lvd$ ../stlink/build/Release/bin/st-info --probe Found 1 stlink programmers version: V2J25S13 serial: 303636464646353335353530373535313837323434313430 hla-serial: "\x30\x36\x36\x46\x46\x46\x35\x33\x35\x35\x35\x30\x37\x35\x35\x31\x38\x37\x32\x34\x34\x31\x34\x30" flash: 0 (pagesize: 0) sram: 0 chipid: 0x0000 descr: unknown device

The stock one i use day-to day:

$ st-info --version v1.5.1 $ st-info --probe Found 1 stlink programmers serial: 303636464646353335353530373535 openocd: "\x30\x36\x36\x46\x46\x46\x35\x33\x35\x35\x35\x30\x37\x35\x35" flash: 65536 (pagesize: 1024) sram: 20480 chipid: 0x0410 descr: F1 Medium-density device

On a Nucleo-H7745ZI-Q,

$ ../stlink/build/Release/bin/st-info --probe Found 1 stlink programmers version: V3J2 serial: 303034453030333933313337353130443339333833353338 hla-serial: "\x30\x30\x34\x45\x30\x30\x33\x39\x33\x31\x33\x37\x35\x31\x30\x44\x33\x39\x33\x38\x33\x35\x33\x38" flash: 2097152 (pagesize: 131072) sram: 131072 chipid: 0x0450 descr: H74x/H75x

so thats nice! i'll start writing some code for it soon.

there is one thing i noticed earlier, but i'm not sure if you have an 'if it ain't broke, dont fix it' policy, so i just include the patch here as an attachment, and you can see if you want it (i don't need credit) or ignore it. basically it is https://commandcenter.blogspot.com/2012/04/byte-order-fallacy.html instead of http://www.ibm.com/developerworks/aix/library/au-endianc/index.html

Kind regards/Luuk

Op zo 20 dec. 2020 om 13:13 schreef nightwalker-87 <notifications@github.com

:

Hi @martonmiklos https://github.com/martonmiklos. Yes there have been a few contributions since then. @ all: Please check the current develop branch with your V3 ST-LINK programmer hardware and suggest further improvements that appear to be necessary. Also check your programmer firmware and report if this feature is working with the respective version. I'd like to close this feature-topic as well, but would prefer to do this with a final PR to be able to attach all related issues to it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/stlink-org/stlink/issues/820#issuecomment-748599836, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACIGICZN7TVSLVUTXHUJK5TSVXS5XANCNFSM4IG5F6WA .

Nightwalker-87 commented 3 years ago

Can we see some more testing here by other STLINK/V3 users?

As far as I am aware of, the following devices should be working by now:

lvdlvd commented 3 years ago

on the nucleo-h745i-q board: $ uname -a Darwin Luuks-new-mbp.local 19.6.0 Darwin Kernel Version 19.6.0: Tue Jan 12 22:13:05 PST 2021; root:xnu-6153.141.16~1/RELEASE_X86_64 x86_64 $ git checkout develop $ make .... $ ./build/Release/bin/st-info --probe Found 1 stlink programmers version: V3J2 serial: 303034453030333933313337353130443339333833353338 hla-serial: "\x30\x30\x34\x45\x30\x30\x33\x39\x33\x31\x33\x37\x35\x31\x30\x44\x33\x39\x33\x38\x33\x35\x33\x38" flash: 2097152 (pagesize: 131072) sram: 131072 chipid: 0x0450 descr: H74x/H75x

$ ./build/Release/bin/st-util st-util 2021-03-11T11:17:12 INFO usb.c: Unable to match requested speed 1800 kHz, using 1000 kHz 2021-03-11T11:17:12 INFO common.c: H74x/H75x: 128 KiB SRAM, 2048 KiB flash in at least 128 KiB pages. 2021-03-11T11:17:12 WARN usb.c: NRST is not connected 2021-03-11T11:17:12 INFO gdb-server.c: Chip clidr: 09000003, I-Cache: on, D-Cache: on 2021-03-11T11:17:12 INFO gdb-server.c: cache: LoUU: 1, LoC: 1, LoUIS: 0 2021-03-11T11:17:12 INFO gdb-server.c: cache: ctr: 8303c003, DminLine: 32 bytes, IminLine: 32 bytes 2021-03-11T11:17:12 INFO gdb-server.c: D-Cache L0: 2021-03-11T11:17:12 INFO gdb-server.c: f00fe019 LineSize: 8, ways: 4, sets: 128 (width: 12) 2021-03-11T11:17:12 INFO gdb-server.c: I-Cache L0: 2021-03-11T11:17:12 INFO gdb-server.c: f01fe009 LineSize: 8, ways: 2, sets: 256 (width: 13) 2021-03-11T11:17:12 INFO gdb-server.c: Listening at *:4242...

I dont have anything to program it with, so can test that yet, but looks like its time to pick up this project again. thanks!

Op do 11 mrt. 2021 om 00:31 schreef nightwalker-87 @.***

:

Can we see some more testing here by other STLINK/V3 users?

As far as I am aware of, the following devices should be working by now:

  • STLINK-V3SET
  • STLINK-V3MINI
  • STLINK-V3MODS

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/stlink-org/stlink/issues/820#issuecomment-796287009, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACIGIC4PW2LWBQ3KTKIPMGTTC76NFANCNFSM4IG5F6WA .

Nightwalker-87 commented 3 years ago

Any tests with stand-alone V3 programmers? Please give us some feedback! :bell: It would be nice if we could close this topic with the upcoming release.