亲爱的支持团队，
we are currently facing an issue with the production test firmware provided by Dialog when running it on our custom PAN1740 based hardware.
最初的DA14580源代码仅针对UART RX/TX引脚分配进行了调整。
当我们连接到Connection Manager并开始任何TX测试（例如，未调制TX）时，我们可以观察到频谱中的载波，但频率错误。通道37的信号看起来或多或少正常。载波频率为2402兆赫。信道38位于2404 MHz而不是2426 MHz。通道39也位于2404兆赫，但其形状要宽得多。
The prod_test fw is based on SDK5.0.4; Connection Manager is v3.0.10.
Can you give a hint what could be the reason for this behaviour?
btw. The actual application fw works well. E.g. the advertisement channels are perfectly met.
谢谢，
Holger
嗨，赫林德，
我已经就此联系了松下，他们正在研究您的问题，他们会直接与您联系。
谢谢你的对话
很好的一天
I would like to know what are the causes of the pin reset not detected when I try programming with UART on my own board I am using the PAN1740
嗨，梅朗，
The reason that the device needs a reset when is programmed via UART is because the Smart Snippets needs to track the 0x02 byte (from the predefined UART pins) that signals the initiation of the UART booting procedure. So by hitting the reset the device starts executing the bootloader, eventually Smart Snippets will catch the 0x02 byte and start the UART booting protocol. So apparently if the Smart Snippets isn;t able to get the reset then it doesn't receive the 0x02 byte which means that most probably something is wrong with your UART connection.
谢谢你的对话
Hi MT\u对话框
我使用的连接
FTDL至船坞
Rx ----> Tx PIN 04
Tx--->Rx引脚05
CTS ----> CTS P03
RTS--->RTS P02
Vcc ----> 3V
GND ----> GND
他们是对的？
Attach the connection of the reset
谢谢你的时间
谢谢你的对话
already detecting rst was a hardware problem
now I try to program the latest version of the .hex file for AT commands
但在tera术语和探头中没有出现9600 Bd、57600和115200未应答的情况。
尝试编写sdk5.0.3和sdk5.0.4的其他示例，但CRC与我不匹配。
any idea how to solve this?
嗨，梅拉格，
波特率取决于您正在使用的管脚，根据您之前的语句，如果您正在使用的任何终端上没有显示任何内容（您应该看到由于引导加载程序运行而产生的垃圾打印），则P04和P05的波特率为57600，然后要么是设备没有复位（因此没有引导加载程序运行），要么是UART连接有问题。你还提到CRC不适合你，你到底是什么意思？你下载的代码和设备不响应0x06（确认）或它不匹配的STM上的计算？还要注意，应该下载.bin文件而不是.hex文件（应该使用适当的工具hex2将.hex文件转换为.bin文件）bin.exe文件).
谢谢你的对话
如何通过UART监控设备（ACK）和0x02字节？
我将尝试将.hex文件更改为.bin，看看会发生什么
非常感谢你的对话
嗨，梅拉格，
If you would like to see the serial booting procedure you do that via attaching a logic analyser on the bus. Since you are using the Smart Snippets tool it will automatically convert the .hex file that you are using into a .bin, so converting it yourself doesn't really matter (i was under the impression that you were using an external MCU in order to download code). Regarding the error that you get, i suppose that you are using a custom device, perhaps you should check the UART lines on your device apparently the data are corrupted generating an invalid CRC from what the Smart Snippets tool has calculated and what the device sends when the downloading procedure has ended.
谢谢你的对话
Hi MT\u对话框
我可以在PAN1740模块中编程DA14585的例子，就像在AN-B-001文件中一样，但是程序不编译，我检查了UART行，这很好
any idea how to solve this?
谢谢
嗨，梅拉格，
首先，据我所知，PAN1740实现了14580而不是585（这意味着您使用了错误的SDK，对于580，sdk5.0.4是最新的，对于585，sdk6.0.4是最新的），您认为程序不编译是什么意思？而且，程序不编译的事实与您不能通过UART编程的事实没有任何关系。
谢谢你的对话
Hi MT\u对话框
然后用sdk 5.0.4I have the problem that crc does not match the calculation in the STM.
在接收到ACK位之前，AN-B-001文件中描述的过程是正常的。
谢谢
嗨，梅拉格，
I am sorry i am quite confused, you are trying to program a PAN1740 via an STM processor through the UART interface and it returns a CRC mismatch or via Smart Snippets. From the images that you have attached it seems that you trying to do so via Smart Snippets and returns that kind of error. Also, what the 585 fw has to do with the above issue ? the PAN1740 has a 580 device inside and not a 585. Can please spend more time to describe what exactly you would like to do in order for me to be able to help?
谢谢你的对话
很抱歉给你一点解释。
I try to program a PAN1470 module by UART with an FTDI (USB to TTL FT232RL) through SamartSinippes.
正如你所说的，我在模块中编程585fw时出错了，因为PAN1740有一个580。
When I try to program examples of sdk 2.0.4 of 580 returns the error of CRC does not match. the procedure marked by file AN-B-0001 is correct, I receive bit 0x02 and ACK 0x06, until the moment of receiving the bit of CRC returns 00 its value by deafult.
我的问题本身，是因为CRC没有被更新或者没有执行XOR来获取它的值？。
嗨，梅拉格，
The bootloader is located in the ROM that means that the operations performed are standard, there is no way to interact or change that code somehow, if the device (580) transmits a 0x00 as a CRC value then i suppose that either there is no actual code download, so there is no actual bytes downloaded into the device (are you able to check that with an analyser), or i suppose that the PAN that you are using is somehow damaged. Can you please check with another device and check if the issue persists. Or can you try to download code via JTAG and not via UART and check if you are able to do so ?
谢谢你的对话
Hi MT\u对话框
I try to program the PAN1740 with J-Link without success, then it is likely that my device is damaged?
嗨，梅拉格，
SWD连接损坏或有问题。
谢谢你的对话
你好，MT\u对话框
问题是我已经将PA1740模块的RST连接到JTAG连接，但是通过线程
https://support.dialog semiconductor.com/forums/post/dialog-smartbond-bl。。。
I realized that the RST of JTAG and PAN1740 are opposites, so if I keep down the botton of RST that I have connected to both (RST module with RST JTAG) I managed to program the example of ble_app_profile, but the device is not announced, in the thread mentioned above it said that I could be in sleeping mode, how can I disable this sleeping mode?
嗨，梅拉格，
为了禁用睡眠模式，您可以将app\u default\u sleep\u mode设置为ARCH\u sleep\u OFF，但设备处于睡眠模式并不意味着设备不会发布广告。所有的示例都执行广告，即使它们处于睡眠模式，设备在广告间隔之间处于睡眠状态，它也不会一直处于睡眠状态。你不可能仅仅通过UART下载fw就找到设备不执行的原因（你不能通过BLE扫描仪找到设备），我建议使用JTAG连接并通过keil进行调试，以便找到发生这种情况的原因。
谢谢你的对话
Hi MT\u对话框
已经解决了，我的问题是我在CFGŧu DEVELOPMENTŧu DEBUG语句中添加了ŧundef，导致它没有被公布，
thank you very much!!!, is there anything I can do to indicate that it helped me solve my case?
嗨，梅拉格，
关于CFG\u DEVELOPMENT\u DEBUG，这不是设备不运行的原因，可能表示设备由于断言而卡住（由于该标志插入了不同类型的断言，以便向开发人员指示实现有问题）。所有的例子都应该使用CFG\u DEVELOPMENT\u DEBUG进行操作。您应该通过JTAG调试设备，以便检查设备被CFG\u DEVELOPMENT\u debug卡住的断言。
Regarding the solving indication, since you haven't created a new thread on this, you cannot indicate that you accept or that any of the above suggestions has helped you, you must be the creator of the thread in order to accept an answer.
谢谢你的对话