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)
Further guidance would be much appreciated. Thank you.
Hi There, for the custom 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
For some reason, I cannot get 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环buffer functionality, it appears that our UART is configured similarly to the DSPS example. The main difference is the initialization of the application-level UART module calling uart_read with a callback function. According to UM-B-004, I should be able to call a uart_read without a callback. I attempted the same thing with a receive callback and calling uart_read upon init but I still have no luck. There is something I'm missing here regarding the UART Handler - shouldn't I be receiving an interrupt handed by UART Handler upon the first byte stored into the recv FIFO (UART_IIR_FCR_REG initialized to 7)? Obviously without the UART Handler triggering, I won't see the callback either.
Is there another example besides peripheral examples and production tools that I can examine? Or any other additional insight. I appreciate the help.
Hi, in chapter "14.3 Two PAN1740 USB sticks" the change is described you need to do in the config.h file.
I actually did try this after my last reply but unfortunately again without any luck - I get a hard fault and halts at the hard fault debugger software breakpoint. The call stack indicates the fault occurs during the uart_sps_timeout_data_avail ISR (interrupt occurring during rf init). Further debugging pinpoints the fault occurs when the receive buffer value is set to the read data.
I have not tested the uart_ family but uart2_ works well here. To get uart2 working on the devkit, I did the following:
Change #undef CFG_PRINTF to #define CFG_PRINTF in da14580_config.h.
In periph_setup.c, change the gpio port and pins to use for uart (GPIO_PORT_0, GPIO_PIN_4 for TX and GPIO_PIN_5 for RX) in GPIO_reservations and set_pad_functions.
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.
I changed my application to use the UART2 peripheral and am still not receiving an interrupt (UART2_Handler).
As a sanity check, I created a new folder with a fresh copy of the SDK v3.0.8.0 and I opened up the template project. I then performed the same modifications to da14580_config.h and periph_setup.c, added uart2_read calls with a UART receive callback, am still not seeing a UART2_Handler interrupt when transmitting to the DA14580. Something that may be of note is that I do see an UART2 RX interrupt occurring on startup with an idd of RECEIVED_AVAILABLE. The uart2_rec_data_avail_isr call to uart2_data_rdy_getf returns TRUE once and therefore the first uart2_read call will perform a callback if a read size of 1 byte is specified.
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.