你好,
我刚刚花了几个小时试图找出我的硬件和软件出了什么问题!
以下是我的经验，这可能对任何人都有帮助，谁将设计一个系统，通过SPI从主MCU引导DA1458x:
我们的器件包含一个STM32Fxxx单片机，一个ALPS UGMZ2AA模块(内置AFAIK DA14580)和SPI闪存，两者共用主单片机的SPI外设。闪存和UGMZ在正常运行时都应作为SPI从站访问，因此不可能将UGMZ作为主站连接到闪存。
根据文档“AN-B-001 - Booting from serial interfaces v2.0”中的引导协议，我编写了一些代码，用于将图像数据从闪存加载到MCU中，然后传输到蓝牙模块中。在调试程序时，我很高兴地看到UGMZ对序言和图像长度数据使用ACK (0x02)响应。
但是SPI数据是这样的:
字节MOSI MISO
# (p0_5) (p0_6)
0 0x70 0x00(前言)
1 0x50 0xDC
2 0x00 0xD4 .使用实例
3 0x00 0x02 (MOSI: Prg。大小LSB, MISO: ACK，如预期)
4 0x1A 0xC0 (MOSI: Prg. 0)大小MSB)
5 0xD1 0xC6 (MOSI: CRC)
6 0x00 0x02 (MOSI: Mode Byte = 8-bit Mode, MISO: ACK for length, as expected)
7 0x00 0xC0 (MOSI:空)
8 0x00 0xFF (MOSI:第一个数据字节，MISO:问题-> ACK预期!)
问题是字节#8，根据AN-B-001，它应该是ACK
所以我试着找出哪里出了问题，也搜索了这个论坛，并找到了其他几个关于这个问题的帖子，例如。https://support.dialog-semiconductor.com/forums/post/dialog-smartbond-bl..。
好吧，因为Dialog对这个话题的回答总是关于可能的SPI传输问题，DA1458x在从模式下的SPI可能有点关键(“在从模式下的SPI采样器对峰值和反射非常敏感”)，而且由于AN-B-001同时相当老，没有进一步的更新发布，我不认为文档可能是错误的。所以我认为这个问题与我的硬件或软件有关。但是，即使使用第二个测试硬件，与我们的设备生产样品完全不同(另一个MCU板，连接到ALPS开发板，根据步骤1和步骤2尝试了两个变体的SPI连接，结果总是一样的，我不知道哪里出了问题。
在我们的设备上，MCU和从机之间的SPI跟踪长度只有几毫米，所以我真的无法想象那里的反射问题，也无法在示波器上看到任何可疑的东西。
在绝望中，我试图传输一个4字节的“test-image”，通过简单地忽略字节#8处缺失的ACK:
字节MOSI MISO
0 0x70 0x00(前言)
1 0x50 0xDC
2 0x00 0xD4 .使用实例
3 0x01 0x02 (MOSI: Prg. 2)size LSB，一个32位字= 4字节，MISO: ACK，正如预期的那样)
4 0x00 0xC0 (MOSI: Prg. 0)大小MSB)
5 0xFF 0xFF (MOSI: CRC)
6 0x00 0x02 (MOSI: Mode Byte = 8-bit Mode, MISO: ACK for length, as expected)
7 0x00 0xC0 (MOSI:空)
8 0x00 0xFF (MOSI:第一个数据字节，MISO: ACK预期，FF =垃圾，忽略)
9 0x00 0xFF (MOSI:数据字节)
10 0x00 0xFF (MOSI:数据字节)
11 0x00 0xFF (MOSI:最后一个数据字节)
12 0x00 0xAA (MOSI:空，MISO::))
13 0x00 0x02 (MOSI:空，MISO::)哇!惊喜-显然这起作用了!)
我的结论:DA14580的引导加载程序似乎不完全符合文件AN-B-001。
问:有人在字节#8处看到引导加载程序的ACK吗?
@对话:如果我是对的，而文档(AN-B-001)是错的，请发布更正版本!因为误导性的文档而花费数小时搜索不存在的bug，这是相当令人沮丧的!
我进一步发现:
我从未见过任何“NACK”(0x20) -如果你发送垃圾，例如，如果给定的图像长度超出了DA1458x的内存大小，你会得到垃圾(=任何东西，但“ACK”)，所以不要真的期望“NACK”(0x20)的错误。
好:
似乎可以在任意两个数据字节之间取消选择SPI从站(CS高)，然后通过再次设置CS低来恢复SPI传输。这对我们的应用非常有帮助，因为闪存和蓝牙模块在MCU上共享相同的SPI引脚。所以我想我可以从flash中获取小包的图像，并将它们发送到模块，而不是必须将整个图像作为单个的大块加载和传输。我在文档中没有找到任何关于这一点的东西，所以我尝试在每个字节后设置高CS，这似乎是可行的。但我还没有最终测试它与真实的图像数据，虽然....
嗨thelger,
关于580的SPI模块的灵敏度，由于尖峰和反射，这是一个有效的问题，在大多数情况下，这就是为什么580的一侧没有与主机进行任何通信的原因。
关于你的问题，确实文档在这一点上有一个不准确的地方，第8步的ACK字节并不完全在第8步，而是在下载序列的末尾，所以如果主开始下载，他将得到一个0xAA(取决于模式)和一个0x02或0x20，如果设备的CRC与主在图像头发送的CRC不匹配。我通知了团队关于这个特定部分的误导性说明。
谢谢你的提示。
MT_dialog
你好,
这里有一个小更新:与此同时，我设法将完整的图像数据发送到蓝牙模块，但这个过程似乎不太可靠。通常情况下，数据被损坏，而不是ACK，我在传输结束时得到了一些垃圾(不是NACK!)如果没有损坏，引导加载程序在整个数据部分的trtransfer期间发送0xFF，然后发送0xAA, 0x02 (ACK)。如果数据损坏，图像数据的回复也是0xFF，但随后是0x55 0x10之类的东西。这似乎是0xAA 0x40 (NAK)，右移了一位，所以看起来DA14580 SPI从站缺少一个SPI时钟脉冲!
显然，错误出现在传输的开始(见所附图片)。我发现，当字节#7和#8之间的MISO行上有小尖峰时，数据被损坏，后面跟着字节(0x7F)用于MISO字节#8。在“良好”传输的情况下，峰值不存在，MISO字节#8是0xFF。
我发现，如果在字节#7和#8之间有几个微秒的小中断，就像图片底部所示，传输似乎是可靠的。
最好的问候,
托马斯Elger
嗨thelger,
谢谢分享你的发现，我相信这将是一个很大的帮助，任何人谁有类似的问题，从SPI主引导。关于0x55和0x10，你看到它实际上是一个0xAA和一个0x20 (NACK)移位了一位，这应该是由于逻辑分析器捕获上出现的峰值(SPI模块工作在从模式，敏感的峰值和反射)。由于在您的情况下，几毫秒的中断可以保证图像的可靠传输，那么也许降低SPI主时钟频率值得尝试。
由于MT_dialog
嗨MT_dialog,
关于0x55和0x10，你看到它实际上是一个0xAA和一个0x20 (NACK)移位了一位
uuup -对不起，我就是这个意思!我的“0x40”只是一个拼写错误。
>，它应该是由于出现在逻辑分析器捕获上的峰值(SPI模块在从模式下工作，对峰值和反射敏感)。
好吧，尖峰是在MISO电线上，所以它是由DA1458x本身引起的，我不认为这是问题的原因-它看起来更像是问题的症状。除此之外，我看不出好的和坏的数据传输数量有任何区别，是否只有几毫米PCB痕迹。，或附加20厘米的电线，用于连接连接到信号的逻辑分析仪。即使是在一个瞄准镜(500 MHz泰克)上，SCK和MOSI信号也非常干净。如果线路质量(反射等)真的那么关键，那么额外的电线和通过各种速度设置改变SPI端口的输出转换率应该对故障数量有明显的影响，但我看不出来。
>，那么也许降低SPI主时钟频率值得一试。
是的，我会尝试这样做，如果它很容易，但我们的主MCU运行在72 MHz和最小SPI时钟频率是Clk/256 = 0,28 MHz。目前我不想仅仅为了测试而重新配置系统时钟树，而短暂的休息更容易实现并解决问题。,)但我想，较低的SPI时钟频率也可能解决这个问题。
谢谢您的关注!
最好的泳衣
托马斯Elger