在哪里可以找到ST-LINK/V2主机接口详细信息

听起来你正在寻找这个：
https://stm8-binutils-gdb.sourceforge.io/



以下为原文




It sounds like you are looking for this:

https://stm8-binutils-gdb.sourceforge.io/

那是另一个我以前没见过的实现。谢谢。在GitHub上有几个ST-LINK项目（例如
https://github.com/texane/stlink
 ，https：//github.com/fpoussin/QStlink2
 ，https：//github.com/afaerber/stlink
 ，https：//github.com/pavelrevak/pystlink
 ）。所有这些资源都是实现，因此受开发人员选择的任何范围限制。有些人在SWIM上有很好的细节，有些在DEBUG上有很好的细节。似乎根本没有ST参考。我觉得产品具有定义的输出接口但没有定义的输入接口，这似乎很奇怪，但对于ST-LINK / V2来说似乎就是这种情况。基本上，所有的实现都充满了“魔术数字”和一些用法的例子。只有几个未知数的例子是
 什么是0xF4 0x02命令实际返回以及它用于什么？命令0xF4 0x03通过 - 0xF4 0x08实际上实现了什么？为什么需要两个命令来执行一个SWIM命令的复位？什么是神奇的用于初始化'session'的一系列命令？哪些'session'启动命令可以导致STM8 cpu的重启？什么参数禁用重启？等等...等...



以下为原文




Well that is another implementation that I haven't seen before. Thank you. There's several ST-LINK projects on GitHub (such as
https://github.com/texane/stlink
, https://github.com/fpoussin/QStlink2
, https://github.com/afaerber/stlink
,  https://github.com/pavelrevak/pystlink
). All these resources are implementations, so are subject to whatever scope the developer chooses. Some have good detail on SWIM, and others on DEBUG. It seems there is no ST reference at all. It just seems odd to me that a product can be produced that has a defined output interface but no defined input interface, but that seems to be the case for ST-LINK/V2. Basically, all the implementations are full of 'magic numbers' and a few examples of usages.Just a couple of examples of unknowns are

• what does 0xF4 0x02 command actually return and what is it used for?
  
• What do the commands 0xF4 0x03 thru - 0xF4 0x08 actually achieve?
  
• Why does it take two commands to do a reset which is a single SWIM command?
  
• What is the magic in the long series of commands to initialise a 'session'?
  
• Which of the 'session' startup commands can cause a restart of the STM8 cpu? What parameter disables the restart?
  
• etc...etc...etc...
  

你的最终目标是什么？调试还是编程？
我确信OpenOCD开发人员在ST过去的某个时刻得到了一个头文件：
https://sourceforge.net/p/openocd/mailman/message/35761273/
 我认为完整的协议描述不会公开。



以下为原文




What is your end goal? Debugging or programming?
What I know for sure that the OpenOCD developers got a header file at some point in the past from the ST:

https://sourceforge.net/p/openocd/mailman/message/35761273/
I do not think that full protocol description would be publicly available.

我收到了OpenOCD源代码的最新副本。 OpenOCD根本不支持STM8，但它确实有一个结构良好的ST-LINK接口。
有一个针对STM8支持的待处理补丁（感谢Ake Rehnman）：
http://openocd.zylin.com/♯/c/3953/
 
http://openocd.zylin.com/♯/c/3952/
 
https://sourceforge.net/projects/stm8-binutils-gdb/files/stm8-binutils-gdb-sources-2017-05-25.tar.gz/download
 我有这个OpenOCD与STM8S003一起工作，所以它确实能够通过SWIM写入内存。
我认为完整的协议描述不会公开
让我重申一下：我认为STLink USB协议文件不会公开。



以下为原文




I got the latest copy of source code for OpenOCD. OpenOCD does not support STM8 at all, but it does have a well-structured ST-LINK interface.
There is a pending patch for the STM8 support (thanks to Ake Rehnman):

http://openocd.zylin.com/♯/c/3953/

http://openocd.zylin.com/♯/c/3952/

https://sourceforge.net/projects/stm8-binutils-gdb/files/stm8-binutils-gdb-sources-2017-05-25.tar.gz/download
I have got this OpenOCD working with STM8S003, so it is indeed capable of writing memory through SWIM.
I do not think that full protocol description would be publicly available
Let me rephrase that: I do not think that the STLink USB protocol document would be publicly available.

嗯，Ake Rehnman在为STM8实现SWIM接口方面做得很好是正确的。他已经纠正并更新了两个早期代码中的代码（通过修补OpenOCD代码，该代码基于GitHub上的texane代码 - 这是我之前看到的代码 - 并且发现我的目的不足）。我只是想知道每个连续的作者如何获得做这种工作的必要信息。我不太擅长猜测或探究这些家伙。
我没有仔细阅读Ake的代码，但我认为我需要的所有信息都在那里。所以，我感谢你的领导。我现在回去尝试将我的小项目放在一起。如果它有效，它将在GitHub上。



以下为原文




Well, you are correct that Ake Rehnman has done a great job of implementing the SWIM interface for STM8. He has corrected and updated code from two earlier sources (by patching the OpenOCD code, which is based on code by texane on GitHub - which is the one I had seen earlier - and found to be deficient for my purposes). I just wonder how each successive author gets the necessary information to do such work. I am not so good at guessing or probing as these guys.
I haven't been through Ake's code in fine detail, but I think all the information I need is there. So, I thank you for the lead. I'll go back and try to put my little project together now. If it works, it'll be on GitHub.

让我重申一下：我认为STLink USB协议文件不会公开。
如果有人
https://community.st.com/people/59416
最终读了这个帖子。我有像Marton提到的那样在gdb的stm8后端工作，这也需要在OpenOCD上做一些繁重的工作。我不知道为什么ST保持st-link u***协议的秘密。 ST不仅指他们的OpenOCD
http://www.st.com/content/st_com/en/about/media-center/press-item.html/p3781.html
 所以基本上你（ST）支持该项目，但也受益于使用我们（开源社区）努力工作的人。为什么不发布USB协议的文档？这将使我们能够编写更好的软件而不是花时间逆向工程你的工作。所以我请求ST发布st-link / v1和st-link / v2 u***协议的相关文档。做正确的事。
谢谢/阿克



以下为原文




Let me rephrase that: I do not think that the STLink USB protocol document would be publicly available.
If someone
https://community.st.com/people/59416
eventually read this thread. I have as Marton mentions been working on the stm8 back end for gdb which also required some heavy work on OpenOCD as well.I do not know why ST keeps the st-link u*** protocol secret. Not only are ST referring to OpenOCD on their
http://www.st.com/content/st_com/en/about/media-center/press-item.html/p3781.html
so basically you (ST) kind of supports the project but also benefit from people using our (open source community) hard work. Why not just release the documents for the USB protocol? That would enable us to write better software instead of spending time reverse engineering your work.So here by I request ST to release the relevant documents for the st-link/v1 and st-link/v2 u*** protocol. Do the right thing.
Thanks /Ake

有点偏离主题，因为它与STM8和STM32的ST许可证情况一般，仅与ST-LINK / V2：
ST软件许可证的情况在STM32和STM8之间完全不同。
对于STM32，在BSD许可下可以获得很多。对于STM8，在对早期许可证更糟糕的投诉之后，他们想出了
http://www.st.com/en/embedded-software/stsw-stm8069.html
 版本3.0，第4条不是免费的，并且具有明确的反自由软件条款5.为方便软件开发，我们需要具有寄存器位置的空闲头文件。 ST在SPL中提供标头，但是在非免费许可下。在里面
http://www.colecovision.eu/stm8/
，我没有使用这些标题，而是手动从数据表中获取位置。一个可以从darasheets中提取寄存器位置和名称以生成标题。但ST会声称这个过程会导致ST对标题持有版权吗？
Microchip Technology Inc.就是这样做的。如果此类索赔持有可能取决于管辖权 - 在许多地方，事实不具有版权。但很多是注册名称是？或者有数据库权限需要考虑？
虽然ST不太可能在这样的问题上起诉他们的一个客户，但可能还不够。此外，版权似乎永远¹，没有人知道他们将来可能会在哪里结束。
菲利普
¹从形式上讲，它们在大多数司法管辖区都是有限的，但从历史上看，只要有些法案即将到期，法律就会改变以延长版权期限。



以下为原文




A bit off-topic, since it is about the ST license situation with STM8 and STM32 in general, to just the ST-LINK/V2:
The situation in ST software licenses is radically different between STM32 and STM8.
For the STM32, a lot is available under a BSD license. For STM8, after complaints about a worse earlier license, they came up with
http://www.st.com/en/embedded-software/stsw-stm8069.html
  Version 3.0, which is non-free by clause 4, and has an explicit anti-free-software-clause 5.For convenient software development, we need free headers with the register locations. ST provides headers in the SPL, but under a non-free license. In the
http://www.colecovision.eu/stm8/
, I did not use those headers, and instead just got the locations from the datasheets manually.One could extract the register locations and names from the darasheets to generate headers. But would ST claim that this process results in ST holding copyright over the headers?
Microchip Technology Inc. did so in such a case. If such claims hold might depend on the jurisdiction - in many places facts are not copyrightable. But many be the register names are? Or there are database rights to be considered?

While ST is very unlikely to sue one of their customers over such an issue, likelyhood is not enough. Also, copyrights seem to last forever¹, and no one knows where they might end up in the future.
Philipp
¹ Formally, they are finite in most jurisdictions, but historically, whenever some are about to expire, laws get changed to extend the duration of copyright.