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

Basic compatibility for STLink-v3 programmer #954

Merged
merged 8 commits into from
May 17, 2020
Merged

Conversation

Nightwalker-87
Copy link
Member

@Nightwalker-87 Nightwalker-87 commented May 9, 2020

Added support for JTAG command API v2:
--> compatibility with the STLink-v3 firmware which dropped support for the previous API v1
--> as of firmware version J11 the ST-LINK-V1 supports API v2 commands as well

As described by @martonmiklos in #863: "Apart from utilising the V2 command API there are some other minor differences in the v3 handling like extended version query, which generally seems to do it's job. At the moment most of the commands are working, however the flash loaded never hits a breakpoint after loading as I mentioned in #820."

(Closes #1023)

src/usb.c Outdated Show resolved Hide resolved
- Comment for selection of API-Version (#271)
- Whitespace cleanup
- Fixed casting (-Wshorten-64-to-32)
@Nightwalker-87 Nightwalker-87 marked this pull request as ready for review May 9, 2020 19:50
@Nightwalker-87 Nightwalker-87 linked an issue May 9, 2020 that may be closed by this pull request
@Nightwalker-87
Copy link
Member Author

This PR is going to be merged next as soon as it is finally approved.

@chenguokai
Copy link
Collaborator

Mostly good, at least backward compatibility has been kept.
There is one warning at the end:
libusb: warning [libusb_exit] application left some devices open

Not sure if this warning is caused by this PR

@Nightwalker-87
Copy link
Member Author

I don't know really - if so usb.c would be of interest, but I haven't found anything there yet.
@chenguokai does it happen on develop as well in your test case?

@chenguokai
Copy link
Collaborator

does it happen on develop as well in your test case?

No, at least with commit ID 4c1f5b9575a90178a9f8fd29b64ccbbb00953ec9

@Nightwalker-87
Copy link
Member Author

Nightwalker-87 commented May 16, 2020

I'll have a look. What did you do exactly? How can I try to reproduce?
The flash and erase procedures (for example) conclude successfully here without any additional notifications.

@chenguokai
Copy link
Collaborator

chenguokai commented May 16, 2020

How can I try to reproduce?

Edit: Warning shows even without --debug, my test command is

./st-flash write ~/Documents/stm32/dev/stm32_clang/build/stm32.bin 0x8000000 
st-flash 1.6.0-302-g4c1f5b9
2020-05-16T20:30:17 INFO common.c: F1xx Medium-density: 20 KiB SRAM, 64 KiB flash in at least 1 KiB pages.
file /Users/cgk/Documents/stm32/dev/stm32_clang/build/stm32.bin md5 checksum: 8f79575b232c1ffe40a2f9afff75a7a6, stlink checksum: 0x000a8934
2020-05-16T20:30:17 INFO common.c: Attempting to write 9272 (0x2438) bytes to stm32 address: 134217728 (0x8000000)
2020-05-16T20:30:17 INFO common.c: Flash page at addr: 0x08000000 erased
2020-05-16T20:30:17 INFO common.c: Flash page at addr: 0x08000400 erased
2020-05-16T20:30:17 INFO common.c: Flash page at addr: 0x08000800 erased
2020-05-16T20:30:17 INFO common.c: Flash page at addr: 0x08000c00 erased
2020-05-16T20:30:17 INFO common.c: Flash page at addr: 0x08001000 erased
2020-05-16T20:30:17 INFO common.c: Flash page at addr: 0x08001400 erased
2020-05-16T20:30:17 INFO common.c: Flash page at addr: 0x08001800 erased
2020-05-16T20:30:17 INFO common.c: Flash page at addr: 0x08001c00 erased
2020-05-16T20:30:17 INFO common.c: Flash page at addr: 0x08002000 erased
2020-05-16T20:30:17 INFO common.c: Flash page at addr: 0x08002400 erased
2020-05-16T20:30:17 INFO common.c: Finished erasing 10 pages of 1024 (0x400) bytes
2020-05-16T20:30:17 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2020-05-16T20:30:17 INFO flash_loader.c: Successfully loaded flash loader in sram
 10/10 pages written
2020-05-16T20:30:17 INFO common.c: Starting verification of write complete
2020-05-16T20:30:17 INFO common.c: Flash written and verified! jolly good!
libusb: warning [libusb_exit] application left some devices open

FYI, my libusb version is 1.0.23 on macOS.

@Nightwalker-87
Copy link
Member Author

Nightwalker-87 commented May 16, 2020

Uh, I can't reproduce that. This is exactly what I tried here. Could it be that this is related to clang somehow? I use gcc on Debian. That is the only difference I see currently (or it is OS-specific).

@chenguokai
Copy link
Collaborator

chenguokai commented May 16, 2020

Trying gcc on macOS only to get a compile error🤔

stlink/src/flash_loader.c:194:9: error: 'size' may be used uninitialized in this function [-Werror=maybe-uninitialized]
  194 |  size_t size;
      |         ^~~~
cc1: all warnings being treated as errors

Edit: with some quick fix, I compiled stlink with gcc, the warning persists.

I will try on my raspberry pi with raspbian.

Edit: on my raspbian, the error still exists.

st-flash 1.6.0-307-gd827ce1e-dirty
2020-05-16T21:36:02 INFO common.c: F1xx Medium-density: 20 KiB SRAM, 64 KiB flash in at least 1 KiB pages.
file /home/pi/stm32.bin md5 checksum: 8f79575b232c1ffe40a2f9afff75a7a6, stlink checksum: 0x000a8934
2020-05-16T21:36:02 INFO common.c: Attempting to write 9272 (0x2438) bytes to stm32 address: 134217728 (0x8000000)
2020-05-16T21:36:03 INFO common.c: Flash page at addr: 0x08000000 erased
2020-05-16T21:36:03 INFO common.c: Flash page at addr: 0x08000400 erased
2020-05-16T21:36:03 INFO common.c: Flash page at addr: 0x08000800 erased
2020-05-16T21:36:03 INFO common.c: Flash page at addr: 0x08000c00 erased
2020-05-16T21:36:03 INFO common.c: Flash page at addr: 0x08001000 erased
2020-05-16T21:36:03 INFO common.c: Flash page at addr: 0x08001400 erased
2020-05-16T21:36:03 INFO common.c: Flash page at addr: 0x08001800 erased
2020-05-16T21:36:03 INFO common.c: Flash page at addr: 0x08001c00 erased
2020-05-16T21:36:03 INFO common.c: Flash page at addr: 0x08002000 erased
2020-05-16T21:36:03 INFO common.c: Flash page at addr: 0x08002400 erased
2020-05-16T21:36:03 INFO common.c: Finished erasing 10 pages of 1024 (0x400) bytes
2020-05-16T21:36:03 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2020-05-16T21:36:03 INFO flash_loader.c: Successfully loaded flash loader in sram
 10/10 pages written
2020-05-16T21:36:03 INFO common.c: Starting verification of write complete
2020-05-16T21:36:04 INFO common.c: Flash written and verified! jolly good!
libusb: warning [libusb_exit] application left some devices open

@Nightwalker-87
Copy link
Member Author

Nightwalker-87 commented May 16, 2020

Ha, I got it now! There appeared to be some remnants of an old install somewhere which are now cleaned up. It happens with st-info --probe also. I found this on the web:

https://stackoverflow.com/questions/44919347/libusb-cant-claim-device

@chenguokai
Copy link
Collaborator

I am a bit confusing. So under what circumstances will the warning appear? And what does the old install mean, a registration of stlink hardware from another driver?

@Nightwalker-87
Copy link
Member Author

Nightwalker-87 commented May 16, 2020

I am a bit confusing. So under what circumstances will the warning appear? And what does the old install mean, a registration of stlink hardware from another driver?

I had an old commit installed locally with sudo make install what I lost track of. So when I did rebuild a later version, the terminal commands were still linked to that installed version of the toolset, so I did not notice at first.

The warning seems to appear whenever there is a cmd sent via usb. I haven't found the commit when it first appeared. It is somewhere in the stlink-v3_pre branch.

@Nightwalker-87
Copy link
Member Author

Nightwalker-87 commented May 16, 2020

The problem occurred in commit 0a91936.

src/usb.c Outdated Show resolved Hide resolved
- Fixed problem "libusb: warning [libusb_exit] application left some 
devices open" resulting from deprecated commands reintroduced in merge 
commit 0a91936. 
- Whitespace cleanup
@Nightwalker-87 Nightwalker-87 requested review from chenguokai and removed request for chenguokai May 17, 2020 10:52
@Nightwalker-87 Nightwalker-87 merged commit a98b094 into develop May 17, 2020
@Nightwalker-87 Nightwalker-87 deleted the stlink-v3_pre branch May 17, 2020 11:43
@stlink-org stlink-org locked as resolved and limited conversation to collaborators Jun 28, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
No open projects
Status: Done
Development

Successfully merging this pull request may close these issues.

[feature] Unable to load STM32F401CC custom board with STM32 Protocol V1 and V2 difference
3 participants