你好,
我刚刚花了几个小时,试图找出有什么问题我的硬盘和软件!
这是我的经验,这可能有利于任何人,谁来设计一个系统,靴子从主单片机通过SPI DA1458x:
我们的设备包含一个STM32Fxxx单片机,阿尔卑斯山UGMZ2AA模块(AFAIK DA14580内部)和SPI闪存,都共享相同的SPI主单片机的外围。快闪记忆体,以及UGMZ应当两accessable SPI奴隶在正常操作期间,因此它不可能连接UGMZ flash深深的为主。
我已经写了一些代码加载图像数据从闪存进入单片机,然后输送到蓝牙模块,根据文档启动协议”- b - 001 -从串行接口v2.0引导”。在调试程序的时候,我很高兴看到ACK的UGMZ回应(0 x02)序言和图像数据长度。
但SPI数据看起来像这样:
字节莫西人味噌
# (P0_5) (P0_6)
0 0 x70 0 x00(序言)
1 0×50 0 xdc
2 0 x00 0 xd4
3 0 x00 0 x02(莫西人:Prg。大小LSB,味噌:ACK,一如预期)
4 0 0 x1a xc0(莫西人:Prg。大小MSB)
5 0 xd1 0 . xc6(莫西人:CRC)
6 0 x00 0 x02(莫西人:模式字节= 8位模式,味噌:ACK的长度,像预期的那样)
7 0 x00 0 xc0(莫西人:空的)
8 0 x00 0 xff(莫西人:第一个数据字节,味噌:问题- > ACK预期!)
问题是字节# 8,这应该是ACK,据- b - 001
所以我试图找出可能是错的,也在这个论坛,发现一些其他的关于这个问题的帖子,如https://support.dialog-semiconductor.com/forums/post/dialog-smartbond-bl..。
对话框,因为答案的话题都是关于可能的SPI转移问题,DA1458x SPI的奴隶模式可能有些关键(“SPI取样器在奴隶模式对峰值非常敏感和反思”),因为一个- b - 001与此同时很旧,没有进一步的更新发布,我不认为文档可能是错的。所以我认为问题是有关我的努力——或软件。但即使有第二个测试hardwarre,完全不同于我们的设备生产样品(另一个单片机板、连接到阿尔卑斯山发展局、尝试SPI连接两个变异根据步骤1和步骤2,结果总是相同的,我不知道什么是错的。
在我们的设备上,SPI跟踪单片机和奴隶之间的长度是几毫米,所以我真的不能想象反映的问题,我也无法看到任何可疑的示波器。
在绝望中,我试图发送4个字节的“测试图”,通过简单地忽略了失踪ACK字节# 8:
字节莫西人味噌
0 0 x70 0 x00(序言)
1 0×50 0 xdc
2 0 x00 0 xd4
3 0 x01 0 x02(莫西人:Prg。LSB大小,一个32位的字= 4字节,味噌:ACK,一如预期)
4 0 0 x00 xc0(莫西人:Prg。大小MSB)
5 0 xff 0 xff(莫西人:CRC)
6 0 x00 0 x02(莫西人:模式字节= 8位模式,味噌:ACK的长度,像预期的那样)
7 0 x00 0 xc0(莫西人:空的)
8 0 x00 0 xff(莫西人:第一个数据字节,味噌:ACK预期,FF =垃圾,忽略)
9 0 x00 0 xff(莫西人:数据字节)
10 0 x00 0 xff(莫西人:数据字节)
11 0 x00 0 xff(莫西人:最后一个数据字节)
12 0 0 x00 xaa(莫西人:空、味噌::))
13 0 x00 0 x02(莫西人:空、味噌:)哇!惊喜——显然这工作!)
我的结论是:DA14580的引导装载程序并不完全遵循文档- b - 001。
问:有人看到一个ACK引导装载程序的字节# 8 ?
@Dialog:如果我是对的,医生(一个- b - 001)是错误的,请发布一个修正版本!而是沮丧花几个小时来寻找bug,并不存在,由于误导文档!
我发现:
我从未见过任何“纳”(0 x20)——如果你发送垃圾,例如如果给定图像的长度超出了DA1458x的内存大小,你会得到垃圾回来(=任何东西,但“ACK),所以并不期待“纳”(0 x20)错误。
好:
似乎被允许取消SPI奴隶高(CS)之间的任何两个数据字节和简历SPI传输后通过设置CS又低。这是为我们的应用程序非常有用,因为flash和蓝牙模块共享相同的单片机SPI别针。所以我想我可以从flash和获取图像在小数据包发送到模块,而不必加载和传输整个图像作为一个大的块。我没有找到任何关于这些文件,所以我尝试了通过设置CS高每个字节后,似乎工作。但我还没有最后测试与实际图像数据虽然....
嗨thelger,
关于580的SPI模块的灵敏度,由于高峰和反思,是一个有效的问题,在大多数情况下,这是没有任何沟通的原因,从580年的主人。
文档关于你的问题,确实有一个inaccurancy此时,ACK在步骤8字节并不是在步骤8但末尾的下载序列,如果主人开始下载,他将得到一个0 xaa(取决于模式)和0 x02或0 x20如果设备与CRC的CRC不匹配,主标题图片发送。我通知团队这方面误导注意特定的部分。
谢谢你的指示。
MT_dialog问好
你好,
这里是一个小更新:同时我设法完成图像数据发送到蓝牙模块,但是这个过程似乎不是很可靠。通常,数据被损坏和ACK,而是我有一些垃圾(不是纳!)的传播。当没有,引导装载程序发送0 xff在整个数据部分的trtansfer xaa为0,0 x02 (ACK)。如果数据损坏,回复0 xff图像数据,太,但后来x55 0 x10。这似乎是0 xaa 0 x40(否定),右移一点,看起来DA14580 SPI奴隶缺少一个SPI时钟脉冲!
显然,错误出现在传输的开始(见附件图片)。我发现,数据损坏时,小穗可见味噌字节之间的界线# 7 # 8,紧随其后的是字节(0 x7f)味噌字节# 8。对于“好”的传播,没有飙升和味噌字节0 xff # 8。
我发现传播似乎可靠的工作如果有稍微休息一下字节之间的几微秒# 7 # 8,像底部的图片所示。
最好的问候,
托马斯Elger
嗨thelger,
谢谢你分享你的创建,我相信这将是一个伟大的帮助与引导类似问题的人都从一个SPI的主人。关于0 x55和x10实际上,你看到一个0 xaa和0 x20(纳)移一点,应该是由于高峰出现在逻辑分析仪采集(SPI模块操作在奴隶模式中,敏感的峰值和反射)。自几毫秒打破担保则多在你的情况下,可靠的形象,那么也许降低SPI主时钟frequncy就值得一试。
由于MT_dialog
嗨MT_dialog,
>关于0 x55和x10实际上,你看到一个0 xaa和0 x20(纳)改变了一点
uuups——对不起,这是我的意思!我的“0 x40”只是一个错误。
>,这应该是由于高峰出现在逻辑分析仪采集(SPI模块操作在奴隶模式中,敏感的峰值和反射)。
味噌的飙升是线,DA1458x本身造成的,我不认为这是问题的原因——它看起来更像一个问题的症状。除此之外,我不能看到任何数量的区别好和坏数据传输,是否只有几毫米PCB痕迹。或额外20厘米线连接的逻辑分析仪连接到信号。即使在一个范围(500 MHz Tektronics),莫西人和SCK信号都很干净。如果真正的线质量(反射等)是关键,额外的电线也改变了SPI端口输出转换速率的各种速度设置的数量应该有一个明确的影响的缺点,但我不能看到。
>也许降低SPI主时钟frequncy就值得一试。
是的,我想试试这个,如果它很容易,但我们主要的单片机运行在72 MHz和最低SPI的时钟频率时钟/ 256 = 0,28 MHz。目前我不想重新配置系统时钟树只是为了测试,虽然这短暂的休息更容易实现,解决了这个问题。,)但我猜,一个较低的SPI时钟频率可能会解决它,太。
谢谢你的关注!
最好的泳衣
托马斯Elger