你好
我刚刚花了几个小时试图找出我的硬件和软件出了什么问题!
以下是我的经验，这可能对任何人都有帮助，谁将设计一个系统，通过SPI从主MCU引导DA1458x:
我们的设备包含一个STM32Fxxx MCU、一个ALPS UGMZ2AA模块（内部为AFAIK DA14580）和SPI闪存，两者共享主MCU的相同SPI外围设备。在正常运行期间，闪存以及UGMZ应可作为SPI从设备访问，因此不可能将UGMZ作为主设备连接到闪存存储器。
我已经编写了一些代码，用于将图像数据从闪存加载到MCU，然后根据文档“AN-B-001-从串行接口引导v2.0”中的引导协议将其传输到蓝牙模块。在调试程序时，我很高兴看到UGMZ用ACK（0x02）响应前导码和图像长度数据。
但SPI数据如下所示：
字节莫西人味噌
#（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.size MSB）
5 0xD1 0xC6（MOSI:CRC）
6 0x00 0x02（MOSI:Mode字节=8位模式，MISO:ACK表示长度，如预期）
7 0x00 0xC0（MOSI:空）
8 0x00 0xFF（MOSI:第一个数据字节，MISO:问题->预期确认！）
问题是字节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和从机之间的SPI跟踪长度只有几毫米，因此我无法真正想象那里的反射问题，也无法在示波器上看到任何可疑的东西。
在绝望中，我试图通过忽略字节#8处缺失的ACK来传输一个4字节的小“测试图像”：
字节莫西人味噌
0 0x70 0x00（序言）
1 0x50 0xDC
2 0x00 0xD4
3 0x01 0x02（MOSI:Prg.size LSB，一个32位字=4字节，MISO:ACK，如预期）
4 0x00 0xC0（MOSI:Prg.size MSB）
5 0xFF 0xFF（MOSI:CRC）
6 0x00 0x02（MOSI:Mode字节=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高，这似乎是工作的。但我还没有最终通过....用真实的图像数据测试它
嗨，塞尔格，
关于580的SPI模块的灵敏度，由于尖峰和反射，是一个有效的问题，在大多数情况下，这是580一侧没有与主机进行任何通信的原因。
关于您的问题，实际上文档在这一点上有不准确之处，第8步的ACK字节并不完全在第8步，而是在下载序列的末尾，因此如果主机开始下载，他将获得0xAA（取决于模式）如果设备的CRC与主机在图像头发送的CRC不匹配，则为0x02或0x20。我向小组通报了关于该特定章节的误导性说明。
谢谢你的提示。
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
嗨，塞尔格，
感谢分享你的发现，我相信这将是一个巨大的帮助，任何人有类似的问题从SPI主引导。关于0x55和0x10，你看到它实际上是一个0xAA和一个0x20 (NACK)移位了一位，它应该是由于出现在逻辑分析仪捕获上的尖峰(SPI模块操作在从模式，敏感的尖峰和反射)。由于几毫秒的中断保证了图像的可靠传输，因此降低SPI主时钟频率可能是值得一试的。
谢谢你的对话
嗨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