STM32在Reset后，其IO处于Floating状态，此事MAX3232的Input处于Floating状态，意味着Out可能是逻辑0或者逻辑1。
当PC发送0x7F做波特率校准时候，STM32的Loader开始初始化串口，居然会突然来个下降沿，并且会保持一会（具体时间未测,并且不是每次都有），于是PC会接受到一个0x00。
这个0x00的来到，在PC Open串口并发送0x7F之后。
本来ＰＣ期望的ACK（0x78），变成了（0x00 0x79）两个字节,这时候ST的ISP Demo会报告失败，但是力源的ISP Utility会聪明的只抓取后面这个0x79。
这也是我为什么第一次给客户安排量产烧录用的力源的工具。
我也开始怀疑力源ISP Utility的作者发现了STM32的这个陷阱，所以才会避开。
后来，我发现ST的Demo只要连接OK，烧录从来没出问题，就用串口监控看数据流，然后就发现了这个0x00。
而且我这里发现，美信的MAX3232出这个0x00机会远远低于国产MAX3232芯片。
所以，上拉个电阻就好了，原因就是解决了MAX3232的TxdIn的floating问题。
ST其实可以在一开始就初始化串口所用的IO，迅速脱离TXD的Floating状态。
PC在Open串口时候，此前的Receive Buffer收到的0x00会自动丢弃。
----------------------------------------------------
另：力源ISP Utility速度慢的原因之一是，每次只传0x18个字节。
ST的Demo是每次0xFC个字节，其实完全可以做到0x100个数据。
Hot徒弟那个Utility速度慢的原因没找到蛛丝马迹，估计是控件上捆绑功能太多，累了吧。 |
楼主
