你好,
我刚刚花了几个小时试图找出我的硬件和软件出了什么问题!
以下是我的经验，这可能对任何人都有帮助，谁将设计一个系统，通过SPI从主MCU引导DA1458x:
我们的设备包含一个STM32Fxxx MCU，一个ALPS UGMZ2AA模块(AFAIK DA14580内部)和SPI闪存，它们共享主MCU的SPI外设。flash memory和UGMZ在正常运行时都应该可以作为SPI slave访问，因此不可能将UGMZ作为主连接到flash memory。
根据文档“AN-B-001 - boot from serial interfaces v2.0”中的引导协议，我编写了一些代码，用于将图像数据从闪存加载到MCU中，然后将其传输到蓝牙模块中。在调试程序时，我很高兴地看到UGMZ对序言和图像长度数据响应ACK (0x02)。
但是SPI数据是这样的:
字节莫西人味噌
# (P0_5) (P0_6)
0 0x70 0x00(序言)
1 0×50 0 xdc
2 0 x00 0 xd4
3 0x00 0x02 (MOSI: Prg.;尺寸LSB, MISO: ACK，如预期)
4 0x1A 0xC0 (MOSI: Prg.)大小MSB)
5 0xD1 0xC6 (MOSI: CRC)
6 0x00 0x02 (MOSI: Mode Byte = 8位模式，MISO: ACK长度，如预期)
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..。
对话框,因为答案的话题都是关于可能的SPI转移问题,DA1458x SPI的奴隶模式可能有些关键(“SPI取样器在奴隶模式对峰值非常敏感和反思”),因为一个- b - 001与此同时很旧,没有进一步的更新发布,我不认为文档可能是错误的。所以我认为问题与我的硬件或软件有关。但是，即使有第二个测试硬件，完全不同于我们的设备生产样品(另一个MCU板，连接到阿尔卑斯山开发板，根据步骤1和步骤2尝试了两个变体的SPI连接，结果总是一样的，我不知道哪里出了问题。
在我们的设备上，MCU和slave之间的SPI跟踪长度只有几毫米，所以我真的不能想象那里的反射问题，也不能在示波器上看到任何可疑的东西。
在绝望中，我尝试着仅仅传输一个4字节的“test-image”，通过简单地忽略在第8字节丢失的ACK:
字节莫西人味噌
0 0x70 0x00(序言)
1 0×50 0 xdc
2 0 x00 0 xd4
3 0x01 0x02 (MOSI: Prg.)LSB，一个32位的单词= 4字节，MISO: ACK，如预期)
4 0x00 0xC0 (MOSI: Prg.;大小MSB)
5 0xFF 0xFF (MOSI: CRC)
6 0x00 0x02 (MOSI: Mode Byte = 8位模式，MISO: ACK长度，如预期)
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吗?
如果我是对的，而doc (AN-B-001)是错的，请发布一个更正的版本!这是相当令人沮丧的花费数小时搜索不存在的错误，由于误导性的文档!
进一步，我发现:
我从来没有看到任何“NACK”(0x20) -如果你发送垃圾，例如，如果给定的图像长度超过DA1458x的内存大小，你会得到垃圾(=任何东西，但“ACK”)，所以不要真的期待“NACK”(0x20)的错误。
好:
它似乎被允许取消选择任何两个数据字节之间的SPI奴隶(CS高)，并在稍后通过再次设置CS低恢复SPI传输。这对我们的应用非常有帮助，因为flash和蓝牙模块在MCU上共享相同的SPI引脚。所以我想我可以从flash中以小数据包的形式获取图像并将它们发送到模块，而不必将整个图像作为一个单独的大块加载和传输。我在文档中没有找到任何关于这个的东西，所以我尝试在每个字节后设置CS高，这似乎是工作的。但我还没有最终通过....用真实的图像数据测试它
嗨thelger,
关于580的SPI模块的灵敏度，由于尖刺和反射，是一个有效的问题，在大多数情况下，这是没有任何通信从580的一方到主人的原因。
关于您的问题，文档确实在这一点上不准确，第8步的ACK字节不是在第8步，而是在下载序列的末尾，因此，如果主服务器开始下载，他将得到一个0xAA(取决于模式)和一个0x02或0x20，如果设备的CRC与主服务器在图像头发送的CRC不匹配。我就这一特定部分的误导通知了团队。
谢谢你的提示。
MT_dialog问好
你好,
这里有一个小更新:与此同时，我设法将完整的图像数据发送到蓝牙模块，但过程似乎不是很可靠。通常情况下，数据被损坏，而不是ACK，我在传输结束时得到一些垃圾(不是NACK!)。当没有破坏时，引导加载程序在传输整个数据段期间发送0xFF，然后发送0xAA, 0x02 (ACK)。如果数据损坏，对图像数据的应答也是0xFF，但随后是0x55 0x10。这似乎是0xAA 0x40 (NAK)，右移一个位，所以看起来DA14580 SPI从缺一个SPI时钟脉冲!
很明显，错误出现在传输的刚开始(见附图)。我发现，当MISO行上在字节#7和#8之间有一个可见的小尖峰时，数据就会被损坏，其次是MISO字节#8的字节(0x7F)。在“良好”传输的情况下，峰值不存在，MISO字节#8是0xFF。
我发现，如果在第7字节和第8字节之间有几微秒的中断，传输似乎是可靠的，如图片底部所示。
最好的问候,
托马斯Elger
嗨thelger,
感谢分享你的发现，我相信这将是一个巨大的帮助，任何人有类似的问题从SPI主引导。关于0x55和0x10，你看到它实际上是一个0xAA和一个0x20 (NACK)移位了一位，它应该是由于出现在逻辑分析仪捕获上的尖峰(SPI模块操作在从模式，敏感的尖峰和反射)。由于几毫秒的中断保证了图像的可靠传输，因此降低SPI主时钟频率可能是值得一试的。
由于MT_dialog
嗨MT_dialog,
>关于0x55和0x10，你看到它实际上是一个0xAA和一个0x20 (NACK)移位了一位
不好意思，我就是这个意思!我的"0x40"只是打错了。
>，这应该是由于出现在逻辑分析仪捕获的尖刺(SPI模块工作在从模式，在尖刺和反射灵敏)。
嗯，这个尖刺是在MISO线上，所以它是由DA1458x本身引起的，我不认为这是问题的原因，它看起来更像是问题的症状。除此之外，我看不出好的和坏的数据传输的数量有什么不同，是否只有几毫米的PCB痕迹。，或20厘米额外的电线连接逻辑分析仪连接到信号。即使在一个范围(500mhz Tektronics)， SCK和MOSI信号是相当干净的。如果真的线路质量(反射等)将是如此关键，额外的电线和也改变SPI端口的输出回转率通过各种速度设置应该有一个明确的影响故障的数量，但我看不出来。
>，那么也许降低SPI主时钟频率是值得尝试的。
是的，我会尝试这个，如果它是容易的，但我们的主要MCU运行在72 MHz和最小SPI时钟频率是Clk/256 = 0,28 MHz。目前，我不想仅仅为了测试而重新配置系统时钟树，而短暂的中断更容易实现和解决问题。,)但我想，一个较低的SPI时钟频率也可能解决它。
谢谢您的关注!
最好的泳衣
托马斯Elger