Hi Dialog,
Now I'm struggling to add UART2 communication into ble_app_all_in_one project in DA1458x_SDK sample project.
UART2 communication with uart2_async project in same DA1458x_SDK sample project works fine.
But by adding the uart2_async function into the ble_app_all_in_one project, UART2 communication doesn't work normally.
As UART2 functions, I just only same uart2_async functions.
Following abnormal phenomena occur.
Just run by debugger, character beta in Greek appears in console.
After execution uart2_print_string(), Line feed is never done.
Receive interrupt doesn't occur, though I checked in UART2_Handler() by debugger.
I guess BLE kernel disturbs my UART2 communication or other UART tasks are running.
But I feel strange since I inserted before BLE settings in system_init().
And for sure I froze watchdog and commented out GPIO_init() but I wrote only necessary IO configurations.
Since I encountered these strange phenomena, I commented out all UART related defines and functions, but result was same.
Anyone could solved such problems?
Or any suggestions?
Thanks,
Hi Diogenes,
In fact that you are using BLE, the device will go into sleep, so the 16MHz crystal oscillator will power down and you will not be able to use UART2. The UART2 is working only when the XTAL16M is on. If you would like to print data while using BLE functionality, you should use the arch_printf() API that is defined in the arch_console.h header file. This API [lace the formatted output data into the UART queue. Before using the serial output the user should enable the API by defining the CFG_PRINTF flag in the da1458x_config_basic.h. In case you are using the Pro DK, you should change the uart ports of the fw and assign the UART_TX port/pin to P04 and UART_RX port/pin to P05. Please make sure that the configuration that you have changed is under the HW_CONFIG_PRO_DK and that this the board declared in the HW_CONFIG definition. Also, you must include the arch_console.h file in the file that you are working.
Thanks, PM_Dialog
Hi PM_Dialog,
Thank you for your suggestions,
I may need more explanation in detail.
首先开始16 m晶体和进入leep, UART is started just after their initialization as follows and sleep is not started at the point.
// Power up peripherals' power domain
SetBits16(PMU_CTRL_REG, PERIPH_SLEEP, 0);
while (!(GetWord16(SYS_STAT_REG) & PER_IS_UP));
SetBits16(CLK_16M_REG, XTAL16_BIAS_SH_ENABLE, 1);
And for sure, I inserted arch_disable_sleep() and wdg_freeze() just before starting UART.
When I tested yesterday at least UART was running, but the problem was that printed strings are displayed partially and receive interrupt flag was not set.
As result I solved the problem and I understood the cause was derived from Kernel behaviors.
I inserted uart2_finish_transfers() after uart2_read() and uart2_write() instead of while (uart2_read_in_progress){} then UART2 receive and UART2 send worked normally.
In short by RW kernel's frequent systick interrupt other interrupts may not work normally and more DA1485x has very poor performance.
Regarding the uart2_async without RW kernel works normally but the same function doesn't work with RW kernel, I concluded it.
I have a question about RW Kernel, how is the ticks interval of the RTOS?
If you know it tell me about it, because I care about the frequency since I also using systick.
Thanks,
嗨,迪ogenes,
Sorry but little bit confused with your description. It is not enough to start the XTAL16 for getting the correct data over UART because the XTAL16M must be settled first. The safest place that assures that the XTAL16 has settled correctly is in the app_on_ble_powered callback (since the core also requires the XTAL16 to operate), after going through that function and if you don’t go to sleep the device will have the XTAL16 settled and ready and you will be able to receive/transmit data via UART. When the device is in sleep mode, it shuts down the XTAL16 which is crucial for the clock generation off the UART, so after waking up you will have to wait for the XTAL16 to settle again. In my previous post I suggest you the safest way to use UART when using BLE functionality. One other information that I would like to let you know is that when the device is in sleep mode it shuts down the XTAL16 which is crucial for the clock generation off the UART, so after waking up you will have to wait to the XTAL16 to settle. Also, be aware that the DA1458x family chips have a very simple event driven scheduler and they are not based on the RTOS. The DA1468x family devices are based on the RTOS.
Thanks, PM_Dialog