我试图通过STM32通过UART编程DA14580。我遵循了“DA1458x从串行接口引导”文档的介绍。
我将.hex文件转换为.bin文件，再转换为.h文件(这是.bin数据的一个简单数组)。当我直接用SmartSnippets将.bin文件flash到SRAM中时，它工作得很好。
但是通过UART闪烁我有问题。我在做什么:
—从DA接收0x02
—从STM32发送0x01, LSB, MSB
—从DA接收0x06 (ACK)
-从STM32发送SW Code Bytes (array)
-接收CRC(正确/检查)
—从STM32发送0x06 (ACK)
但我看不到DA广告，它在那之后仍然发送0x02。
这是否意味着闪烁是错误的?有人知道为什么不吗?
设备:
嗨christianrudmann,
我想说的是，设备点击复位，并进行另一轮的引导加载程序，我认为这就是为什么你看到一个额外的0x02字节下载完你的图像，也许你在580中下载的fw导致设备复位。
由于MT_dialog
我在系统内存里闪了那个。bin还有一次在外部SPI-Flash里闪了。两者都适用。所以我认为这不是密码。
此外，我比较了三种类型的闪烁的SysRAM代码，它们是相同的。
我想DA14580不是重新映射和重启。这只是一个假设。
嗨christianrudmann,
ROM引导装载程序负责设备的重新映射sysram和sw重置设备尽快通过UART弗兰克-威廉姆斯下载,如果你得到一个0 x02一旦设备取得了弗兰克-威廉姆斯,然后我唯一合理的解释是,设备被重置。你能从SDK中的示例中下载fw吗?或者可能是外部MCU下载到580的二进制文件有什么问题?
由于MT_dialog
1.）是的，我试图从sdk编写一个修改过的示例(只是编辑了配置文件)。
2.）我通过UART和SPI (SPI工作)来比较DA14580的SysRAM，因此我确保每个字节都是正确的。唯一的区别是在SysRAM部分后面的4个字节，我在闪烁。Uart: 6倍0x00;SPI: 0x90 0x00 0x20 0x01 0x00。但是这些信息并没有存储在SPI flash中。
有可能知道是什么导致了最后的重置吗?也许是重置寄存器之类的?
嗨christianrudmann,
不，580上没有这样的寄存器为了让最后的重置原因暴露出来。您是否尝试过通过Smart Snippets UART引导程序下载图像，并检查是否能够通过UART成功下载?
您在实际二进制文件末尾看到的额外字节是由Smart Snippets工具附加的，以便为要配置的引脚(仅由flash_programmer使用)，那些字节不是由实际的二进制文件使用的，所以不需要在字节头长度中添加那些字节，你也不需要在你的自定义加载器中发送那些字节。bin字节就足够了。
由于MT_dialog
你好,
是的，闪烁通过SmartSnippets UART工作(在演示板上，因为我的板没有直接访问UART)。所以SW应该没问题。
我有一个状态LED在我的板上，所以我可以看到当我得到一个正确的CRC从DA14580。通过作弊，SW在我的板上工作。
-在Keil(调试模式)重置DA
-运行DA并通过UART加载SW
- LED亮时停止DA(传输完成)
-在调试模式下修改SYS_CTRL_REG (0x50000012)，并设置Remap Bit (Bit 1)和SW Reset (Bit 15)(就像它在SW传输后应该做的那样)并运行
-我能看到我的设备，所以SW在工作
你知道问题出在哪里吗?
嗨christianrudmann,
您可以尝试通过智能代码段下载代码到自定义板或比较智能代码段的程序时，通过UART下载与通过外部MCU自定义下载。由于fw的操作应该是这样的，那么在自定义板的h/w上或在智能片段和外部MCU之间的下载过程中必须有一个差异。
从你为了让设备运行而应用的技巧看来，代码确实被下载到sysram(因为重新映射到sysram和sw复位会产生这个技巧)，毫无疑问，引导加载程序重新映射并重置了设备。因此，如果通过重新映射和发布复位，你可以运行之前下载的fw，也许你应该检查580的电源，有一种情况下，当有不稳定的电压供应，设备将进入一个未定义的状态，你也可以在下载映像后检查引导加载程序是否正在执行(如果可能的话，检查引导ROM正在使用的其他引脚，以确定设备是否确实在运行引导加载程序)。
由于MT_dialog