Uart Hardfault entering extended sleep

9 posts / 0 new
Last post
jtl
Offline
Last seen: 2 weeks 5 days ago
Joined: 2018-06-15 13:14
Uart Hardfault entering extended sleep

Hi Dialog,

I am currently using both UARTs for a project.
I created two tasks which are continuously calling ad_uart_read with a timeout of 1000ms to fill a buffer.
All was working fine until I enabled extended_sleep.

Since then I am running into the hard-fault handler getting called by the function ad_uart_signal_event_read.
So far I tried
- using pm_stay_alive while communicating with the UART devices and pm_resume_sleep when I finished this. I also implemented a method which waits for the two tasks to stop calling ad_uart_read to be save there is no read operation ongoing when entering sleep. Same result.
- opening and closing the uart before every read and write operation. Same result.
- disabling one task for testing purpose and if i disable the uart1-using task the problem disappears.

I've read that the DA14580 has two differently implemented drivers for uart1 and uart2, does this matter for my DA14680?

Do you have any advice helping me to get this fixed?

Device: 
PM_Dialog
Offline
Last seen: 4 days 13 hours ago
Staff
Joined: 2018-02-08 11:03
Hi jtl,

Hi jtl,

Is there any specific reason using the pm_stay_alive? Since there is UART activity the device will not go into sleep mode. Could you please clarify where you get the hardfault? In which position is the PC and LR? . Also,  I would strongly suggest you have a look at chapter 12.3.1 The UART adapter example of the UM-B-044 User Manual: DA1468x Software Platform Reference (HTML) from our support portal.

Thanks, PM_Dialog

jtl
Offline
Last seen: 2 weeks 5 days ago
Joined: 2018-06-15 13:14
Hi PM_Dialog,

Hi PM_Dialog,

I used the pm_stay_alive, because I thought that the problem would be going to sleep while UART Rx is ongoing. Without pm_stay_alive and pm_resume_sleep the problem persists.
Please look at my attached image and you see that the PC points at ad_uart_signal_event_read() at the line OS_EVENT_SIGNAL_FROM_ISR(cd->device->bus_data->event_read); .
For PC it's the adress 0x800cf1c and for LR it's 0x8009841 ( function: static void hw_uart_fire_callback(UART_Data *ud)).
Here is my simplified Task which causes the Hardfault:

UART_BUS(UART1, uartex, HW_UART_BAUDRATE_9600, HW_UART_DATABITS_8, HW_UART_PARITY_NONE,
HW_UART_STOPBITS_1, 0, 0, HW_DMA_CHANNEL_1, HW_DMA_CHANNEL_0, 0, 0)

void rx_task(void *params)
{
uart_dev = ad_uart_open(uartex);
uint8_t buf[1];
while (1) {
int r = ad_uart_read(uart_dev, buf, 1, OS_MS_2_TICKS(1000));
if (r != 1) {
// didn't receive anything
continue;
}
//if received anything, put it in the buffer
}
}

I've read the UART example and I wrote that the problem is present when I read from UART1 and UART2, but not present when I read only from UART2 with nearly the same reading-task for UART1 and UART2

Edit: Using ad_uart_bus_acquire and ad_uart_bus_release before and after every ad_uart_write_async and ad_uart_read doesn't change anything.

Attachment: 
PM_Dialog
Offline
Last seen: 4 days 13 hours ago
Staff
Joined: 2018-02-08 11:03
Hi jtl,

Hi jtl,

According to the datasheets, the UART2 implements hardware flow control with a FIFO of 16 bytes depth, so you are not able to configure it as software UART. The UART1 supports software implementation.  This means that you are not able to wake up over UART1, because it does not support RTS/CTS. In general you are not able to use the UART1 since your device enters the sleep. If you disable the sleep mode, could you please let me know if you get the same error when you are trying to read over UART1? If you are able to provide any kind of configurations or any code snippet that you are using, it would be very helpful.

Thanks, PM_Dialog

jtl
Offline
Last seen: 2 weeks 5 days ago
Joined: 2018-06-15 13:14
Hi PM_Dialog,

Hi PM_Dialog,

if I disable the sleep mode, everything runs fine.
I don't need the UART in sleep mode. This means I don't care about loosing data in sleep mode, but unfortunately the device crashes.
As I said, you can duplicate the code in my post above for UART1 and 2 except of the variable names. This is literally the only piece of code which produces the error.
If I uncomment starting the rx_task, it won't crash. My platform-devices looks like the following:

UART_BUS(UART1, uartex, HW_UART_BAUDRATE_9600, HW_UART_DATABITS_8, HW_UART_PARITY_NONE,
HW_UART_STOPBITS_1, 0, 0, HW_DMA_CHANNEL_1, HW_DMA_CHANNEL_0, 0, 0)

UART_BUS(UART2, uartey, HW_UART_BAUDRATE_9600, HW_UART_DATABITS_8, HW_UART_PARITY_NONE,
HW_UART_STOPBITS_1, 0, 1, HW_DMA_CHANNEL_3, HW_DMA_CHANNEL_2, 0, 0)

Do you have any Idea?

jtl
Offline
Last seen: 2 weeks 5 days ago
Joined: 2018-06-15 13:14
Hello again,

Hello again,

may there be a problem if my UART devices are still sending data to me while the DA is in sleep mode?
I can't force them to stop sending data and it's also not bad that I miss them.

see the attached minimized firmware which I used to test this.
The firmware is working on the devkit because there are no UART devices sending data to the DA while in sleepmode.

Attachment: 
PM_Dialog
Offline
Last seen: 4 days 13 hours ago
Staff
Joined: 2018-02-08 11:03
Hi jtl,

Hi jtl,

As it is mentioned in the previous post, you are not able to wake up over UART1, because it does not support RTS/CTS. That’s why if you disable the sleep mode, everything runs fine. If the device enters the sleep mode, all the peripherals, including UART blocks, are powered of and you will not have UART activity since the device wakes up. In case you are using adapters, if you have pending UART transactions, the DA1460 will be in active mode, and when the UART transactions end, the device will go to sleep mode. So, if the chip is in sleep mode, it is not possible to have UART transactions.

Thanks, PM_Dialog

jtl
Offline
Last seen: 2 weeks 5 days ago
Joined: 2018-06-15 13:14
Hi PM_Dialog,

Hi PM_Dialog,

I understand this. I don't need to wake up and get those messages. The problem is still, that the device hardfaults for some reasons because the UART want's to fire an "empty" read event as I've written before.

Regards

PM_Dialog
Offline
Last seen: 4 days 13 hours ago
Staff
Joined: 2018-02-08 11:03
Hi jtl,

Hi jtl,

Could you please clarify what you mean with the “because the UART want's to fire an "empty" read event as I've written before”? If you are using sleep mode, you should configure the RTC/CTS pin as well in order to wake up. Also, please have a look at the UART_BUS() comments. The _auto_flow_control should be defined to 1. It would be very help if you were able to probe the UART signals and provide some screenshots.

Thanks, PM_Dialog