⚠️
嗨,...感谢您来论坛。令人兴奋的消息!我们现在正在迁至我们的新论坛平台,将提供更好的功能,并包含在主对话框网站中。所有帖子和帐户都已迁移。我们现在只接受新论坛上的流量 - 请发布任何新线程https://www.dialog-seminile.com/support.。我们将在未来几天修复错误/优化搜索和标记。
5个帖子/ 0新
最后一篇
雷格尔
离线
最后一次露面:2年11个月前
加入:2016-10-11 10:58
从SPI Master启动

你好,

我刚刚花了几个小时试图找出答案,我的辛勤软件有什么问题!
这是我的经验,这可能对任何人都有帮助,他们将设计一个系统通过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高电平,似乎工作。但我尚未终于用真实的图像数据测试....

设备:
mt_dialog.
离线
最后一次露面:4个月1周前
职员
加入:2015-06-08 11:34
嗨thelger,

嗨thelger,

关于580的SPI模块的敏感性,由于尖峰和反射,是一个有效的问题,在大多数情况下,这是没有从580的朝向大师的任何通信的原因。

关于您的问题,实际上,该文件在该点处具有不准确的,步骤8的ACK字节并不完全在步骤8,但在下载序列的末尾,因此如果主站开始下载,则会获得0xAA(取决于如果设备的CRC与MASER发送在图像标头处的CRC不匹配,则模式)和0x02或0x20。我向团队通知了关于该具体部分的这种误导注意事项。

谢谢你的迹象。

MT_dialog问好

雷格尔
离线
最后一次露面:2年11个月前
加入:2016-10-11 10:58
你好,

你好,

这里有点更新:同时我设法将完整的图像数据发送到蓝牙模块,但该过程似乎不是很可靠。经常,数据被损坏,而不是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之间存在几微秒,那么像在图片的底部所示。

此致,

托马斯·斯特尔

附件:
mt_dialog.
离线
最后一次露面:4个月1周前
职员
加入:2015-06-08 11:34
嗨thelger,

嗨thelger,

感谢您分享您的创始,我相信这对任何有类似问题的人都有很大的帮助。关于0x55和0x10,您认为其实际上是0xAA和0x20(NACK)移位一位,它应该是由于逻辑分析仪捕获上出现的峰值(以从模式运行的SPI模块,在尖峰和反射中敏感)。由于在您的情况下休息了几毫秒的休息保证图像的可靠传输,那么可能降低SPI主时钟频率将值得尝试。

谢谢mt_dialog.

雷格尔
离线
最后一次露面:2年11个月前
加入:2016-10-11 10:58
嗨mt_dialog,

嗨mt_dialog,

>关于0x55和0x10,您看到它实际上是0xAA和0x20(NACK)移位一位
uuups - 对不起,这就是我的意思!我的“0x40”只是一个错字。
>并且它应该是由于逻辑分析仪捕获上出现的尖峰(以从模式运行的SPI模块,在尖峰和反射中敏感)。
好吧,钉子在味噌线上,所以它是由DA1458x本身引起的,我不认为这是问题的原因 - 它看起来更像是问题的症状。除此之外,我看不到良好的与数据传输的数量有任何区别,是否只有几mm pcb轨迹。或20 cm附加电线,用于连接连接到信号的逻辑分析仪。即使在范围内(500 MHz Tektronics),SCK和MOSI信号也非常干净。如果真的,那么线路质量(反射等)将是关键的,额外的电线和也改变SPI端口的输出转换速率各种速度设置应该对故障的数量有明显的影响,但我看不到。
>然后可能降低SPI主时钟频率将值得尝试。
是的,我将尝试这个,如果它是容易的,但我们的主MCU运行在72兆赫和最小SPI时钟频率是Clk/256 = 0,28兆赫。目前我不想重新配置系统时钟树只是为了测试,而那个短暂的休息更容易实现和解决问题。,)但我想,一个较低的SPI时钟频率也可能解决这个问题。

感谢您的关注!

最好的后续

托马斯·斯特尔