Hello,
We have created a custom project based off of the template project. A few of the things we need to implement are a custom profile (we have successfully created the start of one based off of sample128) and UART communication which will be used to interface with another microprocessor.
UART1 is initialized using default values - 115.2K, parity disabled, 1 stop bit, 8 data bits
TX assigned to P0.4
RX assigned to P0.5
I am using a systick module to increment a characteristics value, update it to test characteristic notify, and output this value via UART. UART TX worked right away without any issues - uart_write(buf, size, NULL) calls are made form main. The next step was to implement a basic polling mechanism to read commands via UART. As a function reference, we have been using UM-B-004 Peripheral Drivers v1.4. Function uart_read(buf, size, NULL) calls are made from main just like uart_write. So far, we have not been successful in receiving any characters into the supplied buffer.
The following has been performed:
——两个不同Panas进行测试onic PAN1740 evaluation kits
- Ensured FTDI chip/cable is working properly via loopback test
- Tried running peripheral examples project: able to get menu output to console but no characters are being received (sits in loop waiting for data ready in the LSR)
- Tried running production test (host application always returns RX timeout status)
将非常感谢进一步的指导。谢谢。
在那里，为自定义profile, I'm going to send you a tutorial (in draft). We will soon publish it, but i believe it will be a big help.
For the PAN1740 - i'm going to loop the Panasonic suport team into this (wireless@eu.panasonic.com) l
BR JE_Dialog
Thanks for the reply. We have already been able to get a custom profile based off of sample128 to work properly but the tutorial you supplied does appear that it will be useful for further customization.
As of now, our main issue is getting the UART reads to work.
Hi, there is a DSPS example that has the UART working and it is described a bit in the application note.https://pideu.panasonic.de/files/Documents/WM%20Documents/PAN1740/PAN174...
Best regards, Ingo
出于某种原因，我无法得到the DSPS example to execute properly. I believe it has something to do with sleep mode and debugging because it sits in a loop forever during a sleep_mode check in the arch_system module.
除了额外的UARTTOBLE，BLETOUART环形缓冲功能外，似乎我们的UART与DSP示例类似地配置。主要区别是使用回调函数调用UART_RED的应用程序级UART模块的初始化。根据UM-B-004，我应该能够在没有回调的情况下调用UART_READ。我尝试了接收回调并在init上调用Uart_read，但我仍然没有运气。有一些关于UART处理程序的东西 - 我不应该在存储到recv fifo的第一个字节上收到UART处理程序的中断（UART_IIR_FCR_REG初始化为7）吗？显然没有UART处理程序触发，我也不会看到回调。
Is there another example besides peripheral examples and production tools that I can examine? Or any other additional insight. I appreciate the help.
嗨，章节“14.3两个Pan1740 USB Sticks”描述了更改，您需要在Config.h文件中执行。
我实际上在我的最后一个回复之后尝试了这个，但不幸的是没有任何运气，我会在硬故障调试软件断点中获得一个硬故障并停止。调用堆栈指示在UART_SPS_TIMEOUT_DATA_AVAIL ISR期间发生故障（在RF INIT期间发生中断）。进一步调试针对接收缓冲区值设置为读取数据时发生故障。
我没有测试过UART_系列，但UART2_在这里工作好。为了让UART2在Devkit上工作，我做了以下事情：
Change #undef CFG_PRINTF to #define CFG_PRINTF in da14580_config.h.
在Periph_setup.c中，在gpio_reservations和set_pad_functions中更改用于UART（GPIO_PORT_0，用于RX的GPIO_PORT_0，GPIO_PIN_5的GPIO_PIN_5）的GPIO端口和引脚。
Then in the app one can now use uart2_write (or arch_printf if app_console.h is included) after including uart.h.
Call uart2_read(buf, length, read_callback) where buf is a buffer, length is the number of bytes to read before the system calls read_callback. At least for uart2_read, you cannot pass a null callback since then ASSERT_ERR(0) is called. In read_callback, you can now process your read bytes.
我改变了我的申请use the UART2 peripheral and am still not receiving an interrupt (UART2_Handler).
作为Sanity检查，我创建了一个带有SDK v3.0.8.0的新副本的新文件夹，我打开了模板项目。然后，我对DA14580_Config.h和periph_setup.c进行了相同的修改，添加了UART接收回调的UART2_READ调用，在发送到DA14580时仍然没有看到UART2_HANDLER中断。可以注意的事情是，我在启动时看到一个UART2 RX中断，在启动时使用Adition_Available的IDD发生。UART2_REC_DATA_AVAIL_ISR调用UART2_DATA_RDY_GETF返回真实一次，因此如果指定了1个字节的读取大小，则第一个UART2_READ调用将执行回调。
Update: we decided to map the RX to pin 0.2 as another debugging effort and the UART interrupt is now firing off when receiving bytes.
While this is good news, our layout design has RX mapped to pin 0.5. Main suspicion is that something is keeping 0.5 low or high, breaking any peripheral functionality that uses that pin. The same behavior is exhibiting itself on both of our PAN1740 USB devices.