亲爱的支持团队,
在基于PAN1740的定制硬件上运行Dialog提供的生产测试固件时,我们目前面临一个问题。
原始DA14580源代码仅针对UART RX/TX引脚分配进行了调整。
当我们连接连接管理器并启动任何TX测试时(例如,未调制的TX),我们可以在频谱中观察到一个载波,但频率不正确。通道37的信号看起来或多或少正常。载波位于2402 MHz。通道38位于2404 MHz而不是2426 MHz。通道39也位于2404 MHz,但形状更宽。
prod_测试fw基于SDK5.0.4;连接管理器为v3.0.10.
您能给出一个提示吗?
顺便说一句。实际应用程序fw运行良好。例如,广告频道完全满足。
谢谢,
霍尔格
Hi,
如何使用不同的芯片选择将多个SPI从设备连接到PAN1740?
如何配置它们并读取代码中的数据
谢谢您
Bharath
Could you please point me to the function that handles incoming GTL SPI messages?
Thanks,
mabraun
EDIT: I am talking about the DA1458x (slave) side here.
spi_hci_write_func()
function. It drives the DREADY signal high and waits for an SPI transfer (spi_wait_for_transfer()
):
...
spi_dready_high(); // Assert dready to request transmit
do {
spi_wait_for_transfer(); // Wait for SPI transaction from SPI master device
...
spi_send_hci_msg()
function, waiting for the DREADY signal to go low:
...
// disable dready interrupt
dready_irq_disable();
// Polling DREADY to detect if data is being received
while(dready_get_status());
...
The following happens:
- The uC disables the dready interrupt, just before the DA asserts the dready signal.
- The dready signal goes high, but no interrupt is triggered on the uC side.
- Instead, the uC waits for the dready signal to go low.
- The dready signal won't go low, since the DA is waiting for an SPI transmission.
--> Deadlock
I'm wondering how the protocol intends to avoid running into the deadlock described above. From what it looks like there is no mechanism that prevents that situation.
Thanks!
mabraun
edit: tried to make problem description more comprehensive
我目前能够使用CLI编程OTP。然而,我希望避免使用RESET引脚或有任何类型的用户干预我的脚本。我使用的FTDI芯片的一个特点是它有gpio,可以编程进行比特敲打。其中一个gpio可以切换为RESET。有没有任何方法,我可以创建我自己的裸编程脚本,消除了按下Reset按钮的需要,只是调用FTDI芯片来做它?我知道FTDI芯片的指令。我只是不知道如何在Dialog端调用它。
Thank you and regards,
Michael