[feature] STLINK-V3 programmer support
WRansohoff opened this issue · comments
- Programmer/board type: STlink/v3 (+on-board)
- Programmer firmware version: V3.J2.M1 'STM32 Debug+Mass storage+VCP'
- Operating system: Ubuntu 18.04
- Stlink tools version: v1.5
- Stlink commandline tool name:
st-util, probably others as well. - Target chip (and optional board): STM32G431KB (STM32G431 'Nucleo-32')
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!
I also have a serious problem. I just bought a brand new STLINK-V3SET programmer / debugger original from StMicro.
- Programmer type: STLINK-V3SET
- Operating system: Debian 9 (stretch)
- Stlink tools version: v1.5.1-31-g625f4cd
- Stlink commandline tool name: st-info and all others
- Target chip: STM32F746VG and/or STM32F469NI using original STLINK-V3SET programmer/debugger
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
<more...>
Any ideas?
I'm really stuck.
Thanks in advance,
Max
I have the same request.
Is there any one shall do something for support STLINK-V3SET? Please.
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.
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
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.
@WRansohoff: Are you interested in testing it by checking out the current develop branch?
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!
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.
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.
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.
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)
@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:
- Fork the repo on the main project page: https://github.com/texane/stlink
- Clone/Download shows a git-link which you should copy to the clipboard.
- 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
- cd into the new folder via the terminal and then type
git clone $pasted_link - Make sure to have the following packages installed:
- CMake (v2.8.7 or later)
- C compiler (gcc, clang or mingw)
- libusb 1.0 (v1.0.13 or later)
- libusb-dev 1.0 (v1.0.13 or later)
... and then proceed with the instructions. Please let us know if you run into trouble. ;-)
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.
Yes, you are right - I forgot to mention that everybody is strongly encouraged to work with the develop branch.
See also #863.
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.
Hey! How are you getting along?
Would giving the capture using Wireshark and usbmon using STM32CubeProg help in anyway?
I am getting the same result as #820 (comment) using STLINK-V3SET, but can be programmed through CLI of STM32CubeProg. I can't use their GUI due to missing library.
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"
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.)
@martonmiklos: No problem, take the time it needs. We are not in a hurry. I just asked to stay on track.
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?
@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. 👍
@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...
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. 😄
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.
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.
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).
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.
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.
Anyone has any idea about why a flash loader would not hit a breakpoint?
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;
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!
@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
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.
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.
@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);
}@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.
@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;
...
}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.
@Nightwalker-87 FYI: the merge did not solved the problem.
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.
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 😃
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.
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.
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
Any tests with stand-alone V3 programmers? Please give us some feedback! 🔔
It would be nice if we could close this topic with the upcoming release.
Any tests with stand-alone V3 programmers? Please give us some feedback!
It would be nice if we could close this topic with the upcoming release.
Are you just looking to test the programmer without actual hardware to program? I have a STLINK-V3MINI, but no hardware to program (yet). Happy to test with jus the programmer if that is what you mean!
@jdbruijn: Whatever may help to find bugs... Thx.
Hi. I did a test with the latest develop branch. Seems to work. STLink V3 SET
~/work/tools/stlink/build/Release/bin/st-flash --reset write bin/application.bin 0x08000000
st-flash 1.6.1-222-g1eaa638
2021-03-14T20:23:28 INFO usb.c: Unable to match requested speed 1800 kHz, using 1000 kHz
2021-03-14T20:23:28 WARN usb.c: NRST is not connected
2021-03-14T20:23:28 INFO common.c: stm32f411re: 128 KiB SRAM, 512 KiB flash in at least 16 KiB pages.
2021-03-14T20:23:28 WARN usb.c: NRST is not connected
file bin/application.bin md5 checksum: f247a2c4e817961e16c344e6e19d2c25, stlink checksum: 0x002725ff
2021-03-14T20:23:28 INFO common.c: Attempting to write 26100 (0x65f4) bytes to stm32 address: 134217728 (0x8000000)
EraseFlash - Sector:0x0 Size:0x4000 2021-03-14T20:23:28 INFO common.c: Flash page at addr: 0x08000000 erased
EraseFlash - Sector:0x1 Size:0x4000 2021-03-14T20:23:28 INFO common.c: Flash page at addr: 0x08004000 erased
2021-03-14T20:23:28 INFO common.c: Finished erasing 2 pages of 16384 (0x4000) bytes
2021-03-14T20:23:28 INFO common.c: Starting Flash write for F2/F4/F7/L4
2021-03-14T20:23:28 INFO flash_loader.c: Successfully loaded flash loader in sram
2021-03-14T20:23:28 INFO common.c: enabling 32-bit flash writes
2021-03-14T20:23:29 INFO common.c: Starting verification of write complete
2021-03-14T20:23:29 INFO common.c: Flash written and verified! jolly good!
2021-03-14T20:23:29 WARN usb.c: NRST is not connected
Any STLINK-V3MODS around as well?
BTW: Our documentation will list all reported working dev-boards with on-board STLINK/V3, so any feedback is really valuable. ❤️
I'll leave this open for a few more days to give everybody enough time for testing and feedback.
Any STLINK-V3MODS around as well?
FYI: V3MODS and V3MINI units are almost identical: the MINI has a pinheader populated, whilst the MODS does not. (You need to utilize the castellated holes at the edge of the board for connection).
@martonmiklos: I know they are very similar from the docs and even share the same FW, but it doesn't hurt to see a success with both does it? The MODS has an extended set of functionality that may bring some side effects - you never know.
but it doesn't hurt to see a success with both does it?
Of course testing never hurts :). I just mentioned it to not keep the MODS untested as blocker. (MODS should be less common in the wild due to it's intended board mount usage type)
Flashing a custom hardware with STM32F750Z8 using V3SET:
user@machine:~/nuttx$ st-info --probe
Found 1 stlink programmers
version: V3J7S1
serial: 303032433030343933303338353130333334333333393030
hla-serial: "\x30\x30\x32\x43\x30\x30\x34\x39\x33\x30\x33\x38\x35\x31\x30\x33\x33\x34\x33\x33\x33\x39\x30\x30"
flash: 65536 (pagesize: 2048)
sram: 327680
chipid: 0x0449
descr: F7xx
user@machine:~/nuttx$ st-flash --reset write nuttx.bin 0x08000000
st-flash 1.6.1-224-g9956bde
2021-03-15T16:44:27 INFO usb.c: Unable to match requested speed 1800 kHz, using 1000 kHz
2021-03-15T16:44:27 WARN usb.c: NRST is not connected
2021-03-15T16:44:27 INFO common.c: F7xx: 320 KiB SRAM, 64 KiB flash in at least 2 KiB pages.
2021-03-15T16:44:27 WARN usb.c: NRST is not connected
file nuttx.bin md5 checksum: baa24dfb857177860e5982d3e6376ff, stlink checksum: 0x00678204
2021-03-15T16:44:27 INFO common.c: Attempting to write 63792 (0xf930) bytes to stm32 address: 134217728 (0x8000000)
EraseFlash - Sector:0x0 Size:0x8000 2021-03-15T16:44:28 INFO common.c: Flash page at addr: 0x08000000 erased
EraseFlash - Sector:0x1 Size:0x8000 2021-03-15T16:44:28 INFO common.c: Flash page at addr: 0x08008000 erased
2021-03-15T16:44:28 INFO common.c: Finished erasing 2 pages of 32768 (0x8000) bytes
2021-03-15T16:44:28 INFO common.c: Starting Flash write for F2/F4/F7/L4
2021-03-15T16:44:28 INFO flash_loader.c: Successfully loaded flash loader in sram
2021-03-15T16:44:28 INFO common.c: enabling 32-bit flash writes
2021-03-15T16:44:30 INFO common.c: Starting verification of write complete
2021-03-15T16:44:30 INFO common.c: Flash written and verified! jolly good!
@jdbruijn You appear to be the only one with a V3MINI so far...
Yeah, I still want to test (have it on my todo list) but I'm I'll at the moment.
Take your time. I wish you a speedy recovery. 👍
@Nightwalker-87 This is without any board connected since I don't have any actual hardware to program, unfortunately. Programmer is the STLINK-V3MINI. Let me know if you want me to run any other commands!
$ build/Release/bin/st-info --version
v1.6.1-225-g125cb2d
$ build/Release/bin/st-info --probe
Found 1 stlink programmers
version: V0S3
serial: 303031413030343233353338353131373333333633373330
hla-serial: "\x30\x30\x31\x41\x30\x30\x34\x32\x33\x35\x33\x38\x35\x31\x31\x37\x33\x33\x33\x36\x33\x37\x33\x30"
flash: 0 (pagesize: 0)
sram: 0
chipid: 0x03e8
Without any target there would not be much else to see, I guess.
debian package is behind the times? Installed v1.7.0 stlink tools from debian package as it indicated support for V3. My STLINK V3SET version V337M2B451 is not discovered, it mounts /dev/sda to /media/${USER}/STLINK_V3S and adds a /dev/ttyACM0 node when connected to Linux.
$ st-info --version
v1.7.0
$ st-info --probe
Found 0 stlink programmers
If I build it from git sources, it does discover:
~/src/stlink$ ./build/Release/bin/st-info --version
/etc/stlink/chips: No such file or directory
v1.7.0-105-gdb8f789
~/src/stlink$ ./build/Release/bin/st-info --probe
/etc/stlink/chips: No such file or directory
Found 1 stlink programmers
version: V3J7S1
serial: 004C00413438511134313939
flash: 1048576 (pagesize: 16384)
sram: 262144
chipid: 0x0419
descr: F42x/F43x
@salyzyn it works for me (ref: #1189)
$ sudo apt remove --purge stlink
$ sudo apt remove --purge libstlink1
solution from @mariobaldini
Syncing installed lib with the st-link bin solved the issue in my case:
Purged both the lib and installed bin: sudo apt remove --purge libstlink1 stlink
Reinstalled the bin again: sudo dpkg -i stlink_1.7.0-1_amd64.deb
I just received my STLINK-V3SET today and am waiting on my STM32F411CEU6 which should be arriving end of Dec.
I'm pretty new to the Arduino/STM32 chipsets but have done a lot of programming in the past on unix, C/C++, Python, etc.
My goal is to get it set up to do some development and testing on a new automation project. I'll be in touch here as I'm quite a newbie for the STLINK-V3 and STM32 stuff.
@EngMarc you can try this https://github.com/huanglilong/stm32h7_fmu
using CMSIS-DAP for debugging
Nuttx as RTOS
you can also use openocd to update frash
example:
openocd -f interface/cmsis-dap.cfg -f target/stm32h7x_dual_bank.cfg -c "program ./build/fmu_nuttx.bin 0x8000000 verify reset exit;"
I need some pointers on the physical wiring/connections too.
I purchased the STM32F411CEU6 with 8 MB flash (https://www.aliexpress.us/item/3256801269871873.html?gatewayAdapt=glo2usa4itemAdapt&_randl_shipto=US).