你好，
我刚刚花了几个小时试图找出答案，我的辛勤软件有什么问题！
这是我的经验，这可能对任何人都有帮助，他们将设计一个系统通过SPI从Master MCU启动DA1458X的系统：
我们的设备包含STM32FXXX MCU，以及ALPS UGMZ2AA模块（内部AFAIK DA14580）和SPI闪存，都共享主MCU的相同SPI外设。闪存以及UGMZ的闪存应在正常操作期间作为SPI从站访问，因此不可能将UGMZ作为闪存常规连接到闪存。
我已经写了一些代码，用于将图像数据从闪存加载到MCU中，然后根据从文档“AN-B-001 - 从串行接口v2.0启动”的引导协议将它们传送到蓝牙模块。在调试程序的同时，我很高兴看到UGMZ对序言和图像长度数据的ACK（0x02）响应。
但SPI数据如下所示：
Byte Mosi Miso.
＃（p0_5）（p0_6）
0 0x70 0x00（序言）
1 0x50 0xdc.
2 0x00 0xd4.
3 0x00 0x02（MOSI：PRG.SIZE LSB，MISO：ACK，如预期）
4 0x1a 0xc0（MOSI：PRG.SIZE 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！）
根据AN-B-001，问题是Byte＃8，应该是ACK
所以我试图在这里找出可能出现的错误，也搜索了这个论坛，发现了几个关于该问题的帖子，例如，https：//support.dialog-semicondiondiondum/forums/post/dialog-smartbond-bl ...
嗯，由于对话框的答案始终可能是SPI传输问题，并且从机器模式中的DA1458x的SPI可能有些重要（“SPI采样器在从站模式下对尖峰和反射非常敏感”），而且B-001同时很老，没有发布的进一步更新，我不认为文档可能是错误的。所以我认为这个问题与我的硬件有关。但即使用第二个测试HardWarre，与我们的设备生产样本完全不同（另一个MCU板，连接到ALPS开发板，根据步骤1和步骤2，尝试用于两种变体的SPI连接，结果总是相同的，我没有想法是错的。
在我们的设备上，MCU和奴隶之间的SPI跟踪长度只有几毫米，所以我真的无法想象在那里的反思问题，也不能在示波器上看到任何可疑的东西。
在绝望时，我试图只要在Byte＃8忽略丢失的ACK的缺失的ACK，我试图只有4个字节的一个小“测试图像”
Byte Mosi Miso.
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 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：空，味噌：:)）
13 0x00 0x02（MOSI：空，味噌：:)哇！惊喜 - 显然工作了！）
我的结论：似乎DA14580的引导加载程序没有完全符合文档AN-B-001。
问题：有没有人在Byte＃8中看到了来自Bootloader的ACK？
@dialog：如果我是对的，并且doc（an-b-001）是错误的，请发布更正的版本！花费数小时和时间来搜索不存在的错误是相当令人沮丧的，这是由于误导性文档！
我进一步发现：
如果你送垃圾，我从未见过任何“nack”（0x20） -如果图像的给定长度超出DA1458X的内存大小，则会让垃圾回来（=任何东西，但“ACK），因此不要真正期望”NACK“（0x20）进行错误。
好的：
似乎允许在任何两个数据字节之间取消选择SPI从站（CS高）并通过再次设置CS低来恢复SPI传输。这对我们的应用非常有帮助，因为Flash和Bluetooth模块在MCU上共享相同的SPI引脚。所以我想我可以从Flash中获取一个小数据包中的图像，并将它们发送到模块，而不是必须加载和将整个图像作为单个大块。在文件中没有找到关于该文件的任何内容，所以我通过在每个字节之后设置CS高电平，似乎工作。但我尚未终于用真实的图像数据测试....
嗨thelger，
关于580的SPI模块的敏感性，由于尖峰和反射，是一个有效的问题，在大多数情况下，这是没有从580的朝向大师的任何通信的原因。
关于您的问题，实际上，该文件在该点处具有不准确的，步骤8的ACK字节并不完全在步骤8，但在下载序列的末尾，因此如果主站开始下载，则会获得0xAA（取决于如果设备的CRC与MASER发送在图像标头处的CRC不匹配，则模式）和0x02或0x20。我向团队通知了关于该具体部分的这种误导注意事项。
谢谢你的迹象。
Best Regards MT_dialog
你好，
这里有点更新：同时我设法将完整的图像数据发送到蓝牙模块，但该过程似乎不是很可靠。经常，数据被损坏，而不是Ack，我在传输结束时得到了一些垃圾回来（不是nack！）。当没有校验时，引导加载程序在整个数据部分的Transfer中发送0xFF，然后在0xAA，0x02（ACK）中发送0xFF。如果数据已损坏，则回复为图像数据为0xFF，而是0x55 0x10。这似乎是0xAA 0x40（NAK），右移一位，所以看起来DA14580 SPI奴隶缺少一个SPI时钟脉冲！
显然，错误在传输开始时出现错误（见附图）。我找到了，当数据在字节＃7和＃8之间的味噌线上可见时，数据会损坏，后跟MISO字节＃8的字节（0x7f）。在“良好”传输的情况下，尖峰不是那里，味噌字节＃8是0xFF。
我发现传输似乎可靠，如果在字节＃7和＃8之间存在几微秒，那么像在图片的底部所示。
此致，
托马斯·斯特尔
嗨thelger，
感谢您分享您的创始，我相信这对任何有类似问题的人都有很大的帮助。关于0x55和0x10，您认为其实际上是0xAA和0x20（NACK）移位一位，它应该是由于逻辑分析仪捕获上出现的峰值（以从模式运行的SPI模块，在尖峰和反射中敏感）。由于在您的情况下休息了几毫秒的休息保证图像的可靠传输，那么可能降低SPI主时钟频率将值得尝试。
谢谢mt_dialog.
嗨mt_dialog，
>关于0x55和0x10，您看到它实际上是0xAA和0x20（NACK）移位一位
uuups - 对不起，这就是我的意思！我的“0x40”只是一个错字。
>并且它应该是由于逻辑分析仪捕获上出现的尖峰（以从模式运行的SPI模块，在尖峰和反射中敏感）。
好吧，钉子在味噌线上，所以它是由DA1458x本身引起的，我不认为这是问题的原因 - 它看起来更像是问题的症状。除此之外，我看不到良好的与数据传输的数量有任何区别，是否只有几mm pcb轨迹。或20 cm附加电线，用于连接连接到信号的逻辑分析仪。即使在范围内（500 MHz Tektronics），SCK和MOSI信号也非常干净。如果真的，那么线路质量（反射等）将是关键的，额外的电线和也改变SPI端口的输出转换速率各种速度设置应该对故障的数量有明显的影响，但我看不到。
>然后可能降低SPI主时钟频率将值得尝试。
是的,我想试试这个,如果它很容易,但我们的梅n MCU runs at 72 MHz and the minimum SPI clock frequency is Clk/256 = 0,28 MHz. Currently I don't want to reconfigure the system Clock tree just for test, while that short break was easier to implement and solved the problem. ;) But I guess, a lower SPI clock frequency would likely solve it, too.
感谢您的关注！
最好的后续
托马斯·斯特尔