• AVR Freaks

Hot!USART serius problem in Harmony 2.02b

Page: 12 > Showing page 1 of 2
Author
Johnny0099
Super Member
  • Total Posts : 157
  • Reward points : 0
  • Joined: 2015/06/20 00:33:20
  • Location: 0
  • Status: offline
2017/01/29 07:40:50 (permalink)
0

USART serius problem in Harmony 2.02b

MCU: PIC32MZ2048EFM100-I/PT
MPLAB X IDE: v3.51
Harmony Version: 2.02b
 
I'm using Harmony USART Buffer Queue model to manage comunication with a GSM/GPRS module through AT commands. I need to read and parse AT replies char by char until I identify a certain sequence and I find the size of data packet, in this case I can read up to 2018 bytes at once.
 
What i'm doing now is the following:
 
1) Use DRV_USART_BufferAddRead with size of 1 byte
 
/* Start buffering on usart rx data */
DRV_USART_BufferAddRead(hDriver->usartDriverOpenHandle, &hDriver->usartRxBuffer.handle,
&hDriver->usartRxBuffer.tmpData[hDriver->usartRxBuffer.tmpCount], 1);

 
2) Wait and parse the received byte in the dedicated Event Handler Callback
 
void DRV_GSM_USARTBufferEventHandler(DRV_USART_BUFFER_EVENT event,
DRV_USART_BUFFER_HANDLE bufferHandle, uintptr_t contextHandle)
{
      /* Receive and parse data here byte by byte */
 
     [...]
 
 
 
      /* Get size of next buffer */
 
      if(socketData) {buffSize = socketSize;}
 
      else {buffSize = 1;}
 

      /* Start buffering on usart rx data */
 
      DRV_USART_BufferAddRead(hDriver->usartDriverOpenHandle, &hDriver->usartRxBuffer.handle, 
      &hDriver->usartRxBuffer.tmpData[hDriver->usartRxBuffer.tmpCount], buffSize);
 
 
 
}

 
In the USART event handler callback, I decide if to get at next step one byte or multiple bytes based on last byte received.
 
Everything works fine, but periodically (after a few minutes or sometimes after several hours) USART hangs up and there is no way to recover it.
 
I found that a receiver overrun happen periodically, and UART3 fault interrupt is fired (I have a LED to trigger this event)
 
void __ISR(_UART3_FAULT_VECTOR, ipl1AUTO) _IntHandlerDrvUsartErrorInstance1(void)
{
   LED4On();
   DRV_USART_TasksError(sysObj.drvUsart1);
}

 
Not ony USART3 but also other pheripherals seems to hang up (at least other USARTs I'm using in this project) and there is no way to recover it. Usart error event handler interrupt should recover USART from overrun but this does't happen. I found an errata that is probably linked to this problem:
 
8. Module: UART
During a RX FIFO overflow condition, the shift register stops receiving data. This causes the UART to lose synchronization with the serial data stream. The only way to recover from this is to turn the UART OFF and ON until it synchronizes. This could require several OFF/ON sequences.
 
Work arounds
 
Work around 1:
Avoid the RX overrun condition by ensuring that the UARTx module has a high enough interrupt priority such that other peripheral interrupt processing latencies do not exceed the time to overrun the UART RX buffer based on the application baud rate. Alternately or in addition to, set the URXISEL bits in the UxSTA register to generate an earlier RX interrupt based on RX FIFO fill status to buy more time for interrupt latency processing requirements.
 
Work around 2:
If avoiding RX FIFO overruns is not possible, implement an ACK/NAK software handshake protocol to repeat lost packet transfers after restoring the UART synchronization.
 
I tried to turn ON and OFF usart in error event handler, but nothing happens. I've tryed in several ways, multiple turn ON and OFF with different delays. It worked only a couple of times with the above code (overrun was restored and comunication started again), but I was never able to let it work again.
 
    /* If it's a overrun error then clear it to flush FIFO */
    if(USART_ERROR_RECEIVER_OVERRUN & PLIB_USART_ErrorsGet(hDriver->moduleId))
    {
        PLIB_USART_ReceiverOverrunErrorClear(hDriver->moduleId);
        
        /* Workaround for PIC32MZ EF Errata n.8 UART Syncronization */
        while(PLIB_USART_ReceiverDataIsAvailable(hDriver->moduleId))
        {
            uint8_t dummyData = PLIB_USART_ReceiverByteReceive(hDriver->moduleId);
        }
        PLIB_USART_Disable(hDriver->moduleId);
        PLIB_USART_Enable(hDriver->moduleId);
    }

 
Any suggestion? I'm going in production with this configuration and I'm really in trouble since this problems happens also with another USART module dedicated to RS-485 comunication.
 
Thanks,
CF
post edited by Johnny0099 - 2017/02/15 15:16:47
#1

29 Replies Related Threads

    timijk
    Super Member
    • Total Posts : 1216
    • Reward points : 0
    • Joined: 2007/11/26 00:30:07
    • Location: Taiwan
    • Status: offline
    Re: USART serius problem in Harmony 2.02b 2017/01/29 08:08:49 (permalink)
    3 (1)
    Have you tried to set URXISEL to 00 or 01 to avoid the overrun?
     
    According to the errata,
    The only way to recover from this is to turn the UART OFF and ON until it synchronizes.

    It sounds like there is something going on...  If your source keeps on sending the data and the USART cannot sync with it, then you will have to turn it off/on again to try to re-sync with the data source.
     
    Maybe using the workaround 2 with ACK/NAK is much better.
     
    If you can use DMA to receive the data into another FIFO buffer, it's another approach to avoid the overrun issue.
    #2
    Johnny0099
    Super Member
    • Total Posts : 157
    • Reward points : 0
    • Joined: 2015/06/20 00:33:20
    • Location: 0
    • Status: offline
    Re: USART serius problem in Harmony 2.02b 2017/01/29 09:11:17 (permalink)
    0
    I've attempted to turn ON/OFF several times in usart error ISR without success:
     
    uint8_t repeat;

    for (repeat = 0; repeat < 100; repeat++)
    {
        PLIB_USART_Disable(hDriver->moduleId);
        Nop(); Nop(); Nop(); Nop(); Nop(); Nop(); Nop(); Nop(); Nop(); 
        PLIB_USART_Enable(hDriver->moduleId);
        Nop(); Nop(); Nop(); Nop(); Nop(); Nop(); Nop(); Nop(); Nop(); 
    }

    #3
    timijk
    Super Member
    • Total Posts : 1216
    • Reward points : 0
    • Joined: 2007/11/26 00:30:07
    • Location: Taiwan
    • Status: offline
    Re: USART serius problem in Harmony 2.02b 2017/01/29 11:05:36 (permalink)
    3 (1)
    I don't know if it's good to use repeat to turn the USART off/on... because it seems you only have to do it until it's synchronized.
     
    According to the workaround 1, it seems not easy to re-synchronize it.  You may have to handle frame error FERR and parrity error PERR in the error handler after the Overrun happens.  For example, we can create an overrun flag, isOverrun, initialized to false.  And also after reading the data from the buffer, we set it to false.
     
    In the error handler,
    if( PLIB_USART_ReceiverOverrunHasOccurred())
    { isOverrun= true;
       //read data from the buffer first, according to the UART reference manual.
       //clean the overrun flag
       //turn USART off/on
    }
    else if( PLIB_USART_ReceiverParityErrorHasOccurred() || PLIB_USART_ReceiverFramingErrorHasOccurred())
    {
       //clean the perr,ferr flags
       //read the data from the buffer 
       if( isOverrun)  
       { // turn USART off/on }
    }

     
    No quite sure, if this can work...  the better approach is trying to avoid the overrun situation.
     
    #4
    rjc101
    Super Member
    • Total Posts : 107
    • Reward points : 0
    • Joined: 2016/07/08 14:56:34
    • Location: 0
    • Status: offline
    Re: USART serius problem in Harmony 2.02b 2017/01/29 12:23:14 (permalink)
    3.67 (3)
    Looking at the docs (page 3274) if you use the buffer model with interrupts, the event handler is within an interrupt.
     
     
    When the driver is configured for Interrupt mode operation (that is defined and registered by the driver client), the buffer event handler executes in
    an interrupt context. Calling computationally intensive or hardware polling routines within the event handlers is not recommended. Calling interrupt
    unsafe functions in the event handler when the driver is configured for Interrupt mode could result in unpredictable system behavior.

     
    So it looks like you do a fair bit within the event handler interrupt, could this potentially cause overrun issues?
     
    It might be better to simply raise a flag within the event handler and have the main processing routine handle the reading and scheduling of buffer reads.  On a recent project where I have 4 x USART running at 115200 I haven't had issues at all with over runs.  The only thing I have had to manually handle as Harmony didn't was framing errors etc. as the user can change the port speeds and line controls if there is a mismatch that will cause problems.  I am using the 144pin version of the same chip.
    For other reasons I now handle the USARTs directly without Harmony, but use it for USB, ethernet and SPI.  I handle the USART IO on a byte by byte basis for reads and DMA for writes.
    #5
    Totem
    Super Member
    • Total Posts : 266
    • Reward points : 0
    • Joined: 2014/12/04 02:18:11
    • Location: Mars
    • Status: offline
    Re: USART serius problem in Harmony 2.02b 2017/01/29 21:40:46 (permalink)
    4 (2)
    Most of these are already discussed,
    This might be the discussion you need to read, http://www.microchip.com/forums/m840153.aspx
     
    And more useful points,
    1. As rjc101 mentioned, you should not handle much logic inside event handler, remember that it is in ISR. So raise a     flag and perform action in app_tasks(). 
    2. And even USART driver calls DRV_USART_TasksError from the fault ISR, this should be handling overrun error.
        Point to be noted here is, if you are not submitting sufficient read requests you will always be in the fault loop,           doesn't matter driver clear it every time because you are receiving data continuously.
     
    I hope this is useful.

    Everything is Relative!
    #6
    Johnny0099
    Super Member
    • Total Posts : 157
    • Reward points : 0
    • Joined: 2015/06/20 00:33:20
    • Location: 0
    • Status: offline
    Re: USART serius problem in Harmony 2.02b 2017/02/04 16:50:44 (permalink)
    0
    I think that Harmony USART library is totally unuseful if it doesn't allow byte by byte reading/parsing in an efficient way. I'm using USART to interface GPS, GSM, a uart WiFi module, and in all these cases, comunication is based on AT commands that are always with variable lenght and terminated with carriage return <CR>.
     
    What's the most efficient and elegant solution to handle this type of USART comunication using harmony USART library? Furthermore, PIC32MZ-EF has a silicon bug on USART and does't allow to recover from FIFO overrun, that makes this device very unreliable for production, unless a real workaround for overrun recovery is used or a new silicon that solves this issue is released by Microchip.
     
    I can even write my own code with a circular buffer to solve this issue but this mean that I have to waive harmony USART library that makes my project quite dirty. I really don't like this solution. I've incurred in USART overrun problems since harmony 1.05, and there is no solution until now.
     
    The problem is always the same: DRV_USART_TasksError() task is not doing its job!
     
    http://www.microchip.com/forums/m840153.aspx
     
    Hope that Microchip will take seriously into account to solve USART issues, both with harmony bug fixing and PIC32MZEF silicon review. In the meantime Microchip users will still waste time writing their own code or looking for a workaround.
     
    #7
    NKurzman
    A Guy on the Net
    • Total Posts : 17709
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: USART serius problem in Harmony 2.02b 2017/02/04 18:07:59 (permalink)
    4.67 (3)
    The answer would be to ignore the Harmony driver.
    Code a interupt driven ring buffer. It moves from the uart to the ring buffer in the interrupt. There is no hard ware overflow. And you can pull from the ring buffer one byte at a time. The buffer can be as big as you need, and have RAM for.
    The Harmony team only coded to the Hardware modes the UART has. They tend to only be needed in certain specialty cases. Since the ring buffer can be coded with no hardware support, they did not do it.
    Some of the harmony send uart modes may be more efficient than a ring buffer.
    #8
    timijk
    Super Member
    • Total Posts : 1216
    • Reward points : 0
    • Joined: 2007/11/26 00:30:07
    • Location: Taiwan
    • Status: offline
    Re: USART serius problem in Harmony 2.02b 2017/02/04 23:18:47 (permalink)
    0
    Hi Johnny0099,
     
    The USART Buffer Queue has Receive DMA Support.  This should be able to overcome the overrun issue.  Have you tried it?
    #9
    NKurzman
    A Guy on the Net
    • Total Posts : 17709
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: USART serius problem in Harmony 2.02b 2017/02/04 23:42:08 (permalink)
    3 (1)
    The DMA approach usually requires ping-pong buffers. This also does not lend itself to byte by byte reads.
    Do you have a butter approach using DMA?
    #10
    Johnny0099
    Super Member
    • Total Posts : 157
    • Reward points : 0
    • Joined: 2015/06/20 00:33:20
    • Location: 0
    • Status: offline
    Re: USART serius problem in Harmony 2.02b 2017/02/05 04:38:36 (permalink)
    4 (1)
    I've always used interrupt driven ring buffer to manage USART AT comunication with PIC24, dsPIC and some PIC32 projects without harmony with good results. This is probably what I will do again. I'm just a little frustrated since my code is almost complete using harmony USART driver and does't work. This means that I've wasted 15 days of my time and I have to start again now. We have customers that are still waiting for this product and I have not so much time now.
     
    Before moving to interupt driven ring buffer I will try with DMA. I'm not so familiar with DMA on USART, since I've tryed to use it with harmony 1.05 but at that time it was not working. Hope Microchip fixed it recently.
     
    Another idea is to modify Microchip USART driver adding a software ring buffer in order to mantain the same interface functions. This will allow me to keep the same application code. I have to look at USART library code to understand how hard is to do. This is the way I'm aspecting that Microchip harmony team would manage USART library. It doesn't make sense to have a USART driver library based only on a 8-dept rx hardware fifo buffer that doesn't works due to rx overrun.
     
    I'm also aspecting that Microchip would add to harmony USART library a new interface function that allows to get data from USART until a certain byte is received, something like this:
     
    void DRV_USART_BufferAddReadUntilByteRcv
    (
    DRV_HANDLE hClient,
    DRV_USART_BUFFER_HANDLE * bufferHandle,
    void * destination,
    byte stopByte,
    size_t * rcvBytes
    size_t maxBytes
    )
     
    Is there someone that successfully used harmony USART driver with AT commands?
    #11
    timijk
    Super Member
    • Total Posts : 1216
    • Reward points : 0
    • Joined: 2007/11/26 00:30:07
    • Location: Taiwan
    • Status: offline
    Re: USART serius problem in Harmony 2.02b 2017/02/05 05:49:50 (permalink)
    0
    I checked the USART hardware setup in the drv_usart.c (Buffer Queue Support), it's using USART_RECEIVE_FIFO_ONE_CHAR, which means the interrupt is triggered when a character is received.  It's the same if the Receive DMA support is turned on.
     
     Use DRV_USART_BufferAddRead with size of 1 byte

     
    I am not sure why you only setup the queue with the size of only 1 byte.  My understanding is, you want to process the information byte by byte unless under certain conditions, you will change the size of the buffer to a larger number.
     
    But can you change it earlier?  Can you change the size of the buffer before you send the AT command?
     
    * * *
    another thing about the DMA approach, if you handle the event with the DMA interrupt, you might not get the overrun error, but you could miss some data if the size of the queue is only 1 byte.
     
    DMA do have some pattern match feature to terminate the transfer.
     
     
    #12
    Johnny0099
    Super Member
    • Total Posts : 157
    • Reward points : 0
    • Joined: 2015/06/20 00:33:20
    • Location: 0
    • Status: offline
    Re: USART serius problem in Harmony 2.02b 2017/02/05 06:56:05 (permalink)
    0
    Thank you timijk,
     
    yes, I'm setting the queue with the size of 1 byte only because I need to check byte by byte the rx data until a certain sequence is matched or <CR> is received.
     
    If a certain sequence is matched it means that I know how many data is going to arrive and I'm setting a queue of n bytes. To be more clear, in this particular case I can have the following scenarios:
     
    1) I can receive AT replies like the ones above after an AT command is sent:
     
    OK<CR><LF>
    ERROR<CR><LF>
    +CWJAP: <ssid>,<channel><rssi><CR><LF>
    etc..
     
    2) An unsolicited message with socket incoming data that can happen at any time: 
     
    +IPD,<socket>,<nBytes>:<incoming data, nBytes arriving here, it can be any byte><CR>
     
    in this case, after receiving the sequence +IPD and ":" byte, I will set a queue of nBytes with a timeout, and will switch again to byte by byte parsing when the operation is completed.
    post edited by Johnny0099 - 2017/02/05 07:10:37
    #13
    Totem
    Super Member
    • Total Posts : 266
    • Reward points : 0
    • Joined: 2014/12/04 02:18:11
    • Location: Mars
    • Status: offline
    Re: USART serius problem in Harmony 2.02b 2017/02/05 21:12:09 (permalink)
    0
    Did you read the thread I have shared?  The same situation/use case was discussed and he was able to make it by better usage of USART driver.
    I have also mentioned the points to take care to avoid overflow of RX.
     
    Let me put it this way, 
    1. Your code flow:
     
    1. Submit a read buffer with length 1
    2. Wait for the callback
    3. Submit one more buffer of length 1 if not the expected character, else submit buffer with higher length.

     
    2. What you can try:
     
    1. Submit 2 or 3 read buffer requests with length 1.
    2. Wait for the callback
    3. Raise a flag in callback and submit one more buffer of length 1 if not the expected character, else submit buffer with higher length in app_tasks().

     
    How is it different and helps?
    >>You are submitting buffers in advance, so while first read buffer is finished you have spare buffers those will read when more packets arrive and won't create overflow situation.
    >>As mentioned in my previous reply, not adding much logic within callback avoids stalling of read interrupts which will again improve the read efficiency.
     
    USART driver has flexibility, that application can use it in multiple ways, I suggest you to read that post( http://www.microchip.com/forums/m840153.aspx) to understand it better.
     
    And I agree PIC32MZ EF has silicon issue and that's one thing which needs some better workaround, at the same time being aware of that we can avoid overflow by using software efficiently.
     

    Everything is Relative!
    #14
    Johnny0099
    Super Member
    • Total Posts : 157
    • Reward points : 0
    • Joined: 2015/06/20 00:33:20
    • Location: 0
    • Status: offline
    Re: USART serius problem in Harmony 2.02b 2017/02/07 06:20:36 (permalink)
    0
    I wil try with your suggestion to add multiple read buffer request, at leat to see if the problem of overrun will not happen again. After this I have to handle the need to switch from byte by byte read/parsing to multiple byte reading.
     
    I will let you know what happens.
     
     
    #15
    muellernick
    Super Member
    • Total Posts : 473
    • Reward points : 0
    • Joined: 2015/01/06 23:58:23
    • Location: Germany
    • Status: offline
    Re: USART serius problem in Harmony 2.02b 2017/02/13 05:36:54 (permalink)
    3 (1)
    I too implemented my own ring buffer. Interrupts do come when there is onc char in the receive buffer. So I do have a lot of time until the USART's receive buffer overruns. For sending, I have set the interrupt to "send buffer empty".
     
    Re the AT commands:
    I too have to read them. With my ring buffer, I can do a peek in the buffer and thus wait until a complete response was actually received. There is no need to hurry, as the ring buffer does all the time critical stuff.
    You might also think about using RTS/CTS.
     
    Nick
    #16
    Johnny0099
    Super Member
    • Total Posts : 157
    • Reward points : 0
    • Joined: 2015/06/20 00:33:20
    • Location: 0
    • Status: offline
    Re: USART serius problem in Harmony 2.02b 2017/02/27 01:55:02 (permalink)
    0
    I'm back with some updates (I spent a lot of time trying to figure out this issue. My application uses 3 USART for different kind of tasks and I cannot go ahead if I'm not able to resolve this situation). 
     
    I'm now a few step ahead. I'm still using harmony USART drivers placing 2 buffers calls to avoid a rx buffer overrun (thanks to Totem for his suggestion):
     
    /* Add buffer read operation on buffer A */
    DRV_USART_BufferAddRead(hDriver->usartDriverOpenHandle, &hDriver->usartRxBuffer.handleA,
    &hDriver->usartRxBuffer.bufferA, 1);

    /* Add buffer read operation on buffer B */
    DRV_USART_BufferAddRead(hDriver->usartDriverOpenHandle, &hDriver->usartRxBuffer.handleB,
    &hDriver->usartRxBuffer.bufferB, 1);

     
    I renew each of them when completed in the callback:
     
    /* Continue buffering on usart rx data */
    if (bufferHandle == hDriver->usartRxBuffer.handleA)
    {
    DRV_USART_BufferAddRead(hDriver->usartDriverOpenHandle, &hDriver->usartRxBuffer.handleA,
    &hDriver->usartRxBuffer.bufferA, 1);
    }
    else if (bufferHandle == hDriver->usartRxBuffer.handleB)
    {
    DRV_USART_BufferAddRead(hDriver->usartDriverOpenHandle, &hDriver->usartRxBuffer.handleB,
    &hDriver->usartRxBuffer.bufferB, 1);
    }

     
    Now I'm not having buffer overrun, but it still remains the problem of randomly USART freeze, this is probably due to some framing errors at the beginning or in the middle of the comunication or a combination of framing errors and buffer overrun. Harmony USART error handler seems not to work properly, since every time there is a framing or overflow error the USART stop working:
     
    void __ISR(_UART3_FAULT_VECTOR, ipl1AUTO) _IntHandlerDrvUsartErrorInstance3(void)
    {
    DRV_USART_TasksError(sysObj.drvUsart3);
    }

     
    I've modified it in this way for a test:
     
    void __ISR(_UART3_FAULT_VECTOR, ipl1AUTO) _IntHandlerDrvUsartErrorInstance1(void)
    {
    while (USART_ERROR_FRAMING & PLIB_USART_ErrorsGet(USART_ID_3))
    {
    uint8_t dummy = PLIB_USART_ReceiverByteReceive(USART_ID_3);
    }
    if (USART_ERROR_RECEIVER_OVERRUN & PLIB_USART_ErrorsGet(USART_ID_3))
    {
    PLIB_USART_ReceiverOverrunErrorClear(USART_ID_3);
    }
    LED4On();

    DRV_USART_TasksError(sysObj.drvUsart1);
    }

     
    This seems to work better, 80-90 % of time the framing and overrun errors are recovered (with harmony code this never happens). I'm generating framing errors and overrun errors to test it. But still remains a problem for me, since when the USART freeze I cannot recover it anymore unless I reset the device (this happens randomly, in one hour on in one day or every 2 days, so it's very tricky to debug).
     
    In summary:
     
    1) I have nomore the problem of interrupt timing, since the overrun seems not to happen anymore in normal operations.
    2) DRV_USART_TasksError(sysObj.drvUsartID) is buggy, since it freeze the USART each time a overrun or a frame error happens.
    3) There should be some problems related to ERRATA that I'm not able to solve following the workaround suggestions by Microchip.
     
    Hope that Microchip will take seriously in charge the revision of DRV_USART_TasksError function since this problem has never been solved!
     
    post edited by Johnny0099 - 2017/02/27 01:57:11
    #17
    Totem
    Super Member
    • Total Posts : 266
    • Reward points : 0
    • Joined: 2014/12/04 02:18:11
    • Location: Mars
    • Status: offline
    Re: USART serius problem in Harmony 2.02b 2017/02/27 03:15:37 (permalink)
    0
    DRV_USART_TasksError does the same logic you are performing(but tries to read maximum of 1 FIFO bytes for framing, if more framing error bytes are coming in then error task will be called again), plus it will remove the existing buffer from the queue as it has error bytes and gives a callback with DRV_USART_BUFFER_EVENT_ERROR.
    Check "_DRV_USART_BufferQueueErrorTasks" function in drv_usart.c.
     
    Are you taking action in event handler for DRV_USART_BUFFER_EVENT_ERROR event?
    If not, read the error type by calling DRV_USART_ErrorGet in DRV_USART_BUFFER_EVENT_ERROR state and take respective action.
     
    As USART driver is doing it's job to clear one FIFO in the case of error and giving control to application to chose what it wishes to do.
    Try it if you are not handling this at application.
     
     
     

    Everything is Relative!
    #18
    Johnny0099
    Super Member
    • Total Posts : 157
    • Reward points : 0
    • Joined: 2015/06/20 00:33:20
    • Location: 0
    • Status: offline
    Re: USART serius problem in Harmony 2.02b 2017/02/27 03:52:26 (permalink)
    0
    What sounds strange here is that, as you say, I'm doing the same logic as DRV_USART_TasksError does except removing the buffers from the queue. 
     
    I'm not doing any action in the application in the event handler for DRV_USART_BUFFER_EVENT_ERROR. I don't think this is blocking the application since I'm actually bypassing Harmony DRV_USART_TasksError function. I want to try to go back using DRV_USART_TasksError trying to figure out what action I can do in the application within the DRV_USART_BUFFER_EVENT_ERROR event in the event handler.
     
    Let me try and will let you know.
     
     
    #19
    Johnny0099
    Super Member
    • Total Posts : 157
    • Reward points : 0
    • Joined: 2015/06/20 00:33:20
    • Location: 0
    • Status: offline
    Re: USART serius problem in Harmony 2.02b 2017/02/27 05:06:00 (permalink)
    0
    I just re-enabled DRV_USART_TasksError to check what happens. All USARTS freeze (DEBUG Usart is nomore working) when an error take place on one USART. I verified that DRV_USART_BUFFER_EVENT_ERROR is not fired in the event handler (I have a LED that is turned on).
     
    There is something that does't work in DRV_USART_TasksError, unless I'm missing something. My code replacement in the USART interrupt error handler allows me to recover from error in some way, but I cannot understand why it's not working with Harmony.
     
    #20
    Page: 12 > Showing page 1 of 2
    Jump to:
    © 2019 APG vNext Commercial Version 4.5