• AVR Freaks

Hot!Why does the DMA handler configured as a CRC generator not respond?

Author
DominusT
Super Member
  • Total Posts : 1419
  • Reward points : 0
  • Joined: 2005/07/22 08:31:18
  • Status: offline
2019/11/29 09:01:32 (permalink)
0

Why does the DMA handler configured as a CRC generator not respond?

Hi.
 
I'm using DMA as a 16-bit CRC generator, I'm using the following document as an example:
 
http://ww1.microchip.com/...evices-DS90003196A.pdf
 
 
The difference between the document and my code is that once the DMA is configured, the task that manages the DMA goes to wait until the CRC has been successfully generated:

case APPCRC_CALCULATE_CRC:
        {
            appcrcData.errorCRC = 0x00;
            SYS_DMA_ChannelCRCSet(channelHandle, crc);
            SYS_DMA_ChannelTransferAdd(channelHandle, ramBuff,
                        (length + (crc.polyLength/8)) ,
                        ramBuff,(length + (crc.polyLength/8)),
                        (length + (crc.polyLength/8)));
               
               
            SYS_DMA_ChannelForceStart(channelHandle);
            appcrcData.state = APPCRC_CALCULATING_CRC;
            break;
        }
        case APPCRC_CALCULATING_CRC:
        case APPCRC_CRC_FINISHED: break;


The handler is the who passes the DMA's task to the 'FINISHED' state as follows:

static void App_Mem2Mem_Event_Handler(SYS_DMA_TRANSFER_EVENT event,SYS_DMA_CHANNEL_HANDLE handle, uintptr_t contextHandle)
{
    // Success event
    if(SYS_DMA_TRANSFER_EVENT_COMPLETE == event)
    {
        blockCrc = SYS_DMA_ChannelCRCGet();
        appcrcData.errorCRC = WITHOUT_ERROR_SQIDMA;
        appcrcData.state = APPCRC_CRC_FINISHED;

    }
    // Failure Event
    else if(SYS_DMA_TRANSFER_EVENT_ABORT == event)
    {
        //Nop();
        appcrcData.errorCRC = ERROR_SQIDMA_DMA_ERROR ;
    }
   
}

 
What is happening is that the task remains in the APPCRC_CALCULATING_CRC state, that is to say that the handler never executes its code.


 
I have tried to review the registers related to the DMA to determine some error flag, but everything is fine.
 
Any comments or suggestions are welcome.
 
 
 
 
post edited by DominusT - 2019/11/29 19:22:23
#1

16 Replies Related Threads

    DominusT
    Super Member
    • Total Posts : 1419
    • Reward points : 0
    • Joined: 2005/07/22 08:31:18
    • Status: offline
    Re: Why does the DMA handler configured as a CRC generator not respond? 2019/11/29 13:59:59 (permalink)
    0
    The problem described above started from this week and I thought it was to add new features to the code.
     
    But we decided to occupy an old version that worked without problems and surprise, the same problem happens.
     
    After thinking I remembered that I have problems with version 5.30 of MPLAB X and decided to go back to version 5.25 to use it and the problem has disappeared.
     
    The new code was also generated with MPLAB v5.25 and it works.
     
    Today I have been verifying that problem all day and I don't understand why MPLAB somehow does something wrong, despite maintaining the XC32 version.
     
    I also tried with older versions of XC32 and the problem is always MPLAB X.
    #2
    DominusT
    Super Member
    • Total Posts : 1419
    • Reward points : 0
    • Joined: 2005/07/22 08:31:18
    • Status: offline
    Re: Why does the DMA handler configured as a CRC generator not respond? 2019/11/30 08:06:23 (permalink)
    0
    I have managed to find a possible relationship between the USB and the DMA module.
     
    The hardware we use has a USB port configured in CDC mode (Virtual COM). It is used only to configure hardware parameters and is not constantly connected to a PC.
     
    While the USB port is not connected to a PC, the DMA works correctly, when connected after a moment the problem happens. Similarly if the hardware is turned off but connected to a PC through the USB port, when turned on, after a moment, the DMA stops working.
     
    This is much more evident when generating the project in MPLAB X v 5.30, while the one generated in version 5.25, it is very difficult to happen, but it has also happened a few times (when connecting or disconnecting the USB cable from the PC).
     
    I have placed breakpoints in the SYS_DMA_Tasks(sysObj.sysDma, DMA_CHANNEL_0) function  to determine if some type of error is generated, but nothing happens.
     
    Also the DMA module is on, I thought the USB somehow turned it off.
     
    The interruptions of the DMA and the USB are different, I also assumed that they possibly shared the same level of interruption.
     
    What I'm going to do now is to check how the DMA module registers are configured when it is working and how they are after the error happens.
     
    Any suggestions that records should review? I see that there are many
    post edited by DominusT - 2019/11/30 11:34:14
    #3
    DominusT
    Super Member
    • Total Posts : 1419
    • Reward points : 0
    • Joined: 2005/07/22 08:31:18
    • Status: offline
    Re: Why does the DMA handler configured as a CRC generator not respond? 2019/11/30 12:01:44 (permalink)
    0
    I 'm reading other threads about similar problems with the DMA that stops working.  

    It seems to be related to the cache, I have three arrays that use __attribute __ ((coherent)) with the DMA:


    uint8_t __attribute__((coherent)) ramBuff[256];
    extern uint8_t __attribute__((coherent)) writeBufferSQI[256];
    extern uint8_t __attribute__((coherent)) readBufferSQI[256];

     
    While the USB module uses its own array of the same type:
     

    #define USB_BUFFER_TYPE uint8_t __attribute__((coherent)) __attribute__((aligned(16)))
    USB_BUFFER_TYPE readBufferUSB[512];

     
    Could there be any kind of relationship?
    #4
    DominusT
    Super Member
    • Total Posts : 1419
    • Reward points : 0
    • Joined: 2005/07/22 08:31:18
    • Status: offline
    Re: Why does the DMA handler configured as a CRC generator not respond? 2019/12/02 06:30:53 (permalink)
    0
    I keep writing to myself.


    I have tried to understand similar problems regarding DMA in other threads and many mention the microcontroller cache.
     
    I still don't understand very well, but I am sure that my problem is related to it because I wrote the code related to the CheKseg0CacheOn function in the main function as follows:
     
    int main ( void )
    {
        /* Initialize all MPLAB Harmony modules, including application(s). */
        SYS_Initialize ( NULL );
        /* CheKseg0CacheOn */
        register unsigned long tmp;
        asm("mfc0 %0,$16,0" : "=r"(tmp));
        tmp = (tmp & ~7) | 3;
        asm("mtc0 %0,$16,0" :: "r" (tmp));
     
        ///////////////////////////////////////
        while ( true )
        {
            /* Maintain state machines of all polled MPLAB Harmony modules. */
            SYS_Tasks ( );
            WDTCONbits.WDTCLRKEY = 0x5743; // reinicia al WDT
        }

        /* Execution should not come here during normal operation */

        return ( EXIT_FAILURE );
    }

     
    When writing that code and connecting the USB port, the DMA works much longer before failing, approximately 2 minutes.


    I have performed many tests with and without that code, while without the code, the problem happens is almost immediately, less than 5 seconds before the DMA fails.


    I'm using an SQI memory to save and read information and it is based on the example flash_read_dma_mode of Harmony.
     
    I understand that the 'dma' is related to an internal memory functionality and would not have to do with the dma of MCU, however there are many variables of type __attribute __ ((coherent)) in that example.
     
    Would there be a possibility that my "coherent" variables plus the "coherent" variables in the above example have exceeded the maximum limit of the cache?
     
     
    post edited by DominusT - 2019/12/02 06:32:45
    #5
    moser
    Super Member
    • Total Posts : 581
    • Reward points : 0
    • Joined: 2015/06/16 02:53:47
    • Location: Germany
    • Status: offline
    Re: Why does the DMA handler configured as a CRC generator not respond? 2019/12/02 07:47:44 (permalink)
    4 (1)
    coherent variables are not placed in the cache. It is quite the opposite. They are placed in the kseg1 region, which means, they are accessed through an uncached address. Since region kseg1 (uncached) and kseg0 (cached) are physically overlapping, you can't simply run out of coherent memory in particular.
     
    I've once read in this forum about a compiler version, which had a nasty problem with coherent variables: It mixed cached and non-cached variables within a memory block of a single cache page (=16 bytes). This results in any kind oft problems, when the write-back of the cache page overwrites all changes by the uncached accesses. An easy way to fix it, was to align all coherent variables to a cache page by using __attribute__((aligned(16)). But I think the newer compiler versions have this issue fixed. Which compiler do you use?
     
    I guess the problem is more likely somewhere with the DMA configuration and handling, but I can't help you with that, as I don't have any experience.
     
    But it is strange, that the MPLAB X version makes a difference. In theory it should only depend on the compiler version and Harmony version and your configuration (MHC and project) and - of course - your code.
    #6
    DominusT
    Super Member
    • Total Posts : 1419
    • Reward points : 0
    • Joined: 2005/07/22 08:31:18
    • Status: offline
    Re: Why does the DMA handler configured as a CRC generator not respond? 2019/12/02 08:03:59 (permalink)
    0
    Thanks for writing
     
    moser
     But I think the newer compiler versions have this issue fixed. Which compiler do you use?

     
    I'm working with XC32 v2.30 and Harmony 2.06, I also tried with XC32 v2.20. MHC is v2.0.5.2
     
    moser
    But it is strange, that the MPLAB X version makes a difference. In theory it should only depend on the compiler version and Harmony version and your configuration (MHC and project) and - of course - your code.



    I'm aware that the problem should be in different versions of XC32, not with MPLAB versions.


    In MPLAB v5.25 it also happens, but it is after a long time and the reason we didn't detect before the problem is that the hardware is not constantly connected to a PC via USB and our hardware also works in two modes, STOP and RUN, in RUN mode it is when the MCU is constantly reading the code of the external flash memory and in STOP the DMA is not used and the external FLASH memory isn't read.


    When the hardware is connected to a PC, a command is sent to enter STOP mode and that is why we never realized that DMA stopped working.


    As I mentioned before with MPLAB 5.30, the problem happens almost immediately and that is where we began to realize that there was an error.
    post edited by DominusT - 2019/12/02 08:32:23
    #7
    DominusT
    Super Member
    • Total Posts : 1419
    • Reward points : 0
    • Joined: 2005/07/22 08:31:18
    • Status: offline
    Re: Why does the DMA handler configured as a CRC generator not respond? 2019/12/03 09:16:33 (permalink)
    0

    Hello with myself.
     
    Can someone tell me if the USB module has its own DMA, or the same one that has the MCU?
     
    So far I have been able to determine that the interruption related to the DMA stops working after the USB is connected to the PC.
    post edited by DominusT - 2019/12/03 09:33:22
    #8
    DominusT
    Super Member
    • Total Posts : 1419
    • Reward points : 0
    • Joined: 2005/07/22 08:31:18
    • Status: offline
    Re: Why does the DMA handler configured as a CRC generator not respond? 2019/12/03 10:19:19 (permalink)
    0
    Something I am not considering is a note of the PDF document indicated in the initial message of this thread, however I'm comparing the suggested function called APP_DMA_ChannelCRCSet with the SYS_DMA_ChannelCRCSet function but they are essentially similar.


    Look attached image.
     

    #9
    DominusT
    Super Member
    • Total Posts : 1419
    • Reward points : 0
    • Joined: 2005/07/22 08:31:18
    • Status: offline
    Re: Why does the DMA handler configured as a CRC generator not respond? 2019/12/10 09:23:27 (permalink)
    0
    Hi. I keep talking to myself.
     
    I opened a technical thread in technical support hoping they can help me.
     
    I tried to compare the DMA registers before and after the problem happens but apparently they are the same, but I get the interruption of the DMA to work again for a period of time before the problem happens.
     
    For which I pause the debugging and clean any the following flags in DCH1INT  that are in 1: CHSDIF, CHSHIF, CHSDIF, CHSDHIF CHSCCIF and force the task that administers the DMA to start the process as follows:


     

    case APPCRC_CALCULATE_CRC:
            {
                appcrcData.errorCRC = 0x00;
                SYS_DMA_ChannelCRCSet(channelHandle, crc);
                SYS_DMA_ChannelTransferAdd(channelHandle, ramBuff,
                            (length + (crc.polyLength/8)) ,
                            ramBuff,(length + (crc.polyLength/8)),
                            (length + (crc.polyLength/8))); 
                   
                   
                SYS_DMA_ChannelForceStart(channelHandle);
                appcrcData.state = APPCRC_CALCULATING_CRC;
                break;
            }
     


     
    And that's it, the interruption of the DMA will work again for a few more seconds until the problem happens again.
     
    By cleaning all the aforementioned flags the DMA works a little longer, but the problem happens again.
     
    Without cleaning the flags and forcing the task to restart the process of calculating the CRC doesn't solve the problem.
     
    The USB module also works correctly, that is, it can send and receive data. I thought that altering these flags could cause some kind of error in that module.

    Over and out
    post edited by DominusT - 2019/12/10 09:25:33
    #10
    DominusT
    Super Member
    • Total Posts : 1419
    • Reward points : 0
    • Joined: 2005/07/22 08:31:18
    • Status: offline
    Re: Why does the DMA handler configured as a CRC generator not respond? 2019/12/11 06:35:34 (permalink)
    0
    Hello again.
     
    I have cleared the flags that I mentioned earlier in the SYS_DMA_Tasks function that is executed when the DMA interrupt occurs as follows:

     DCH1INTbits.CHCCIF = 0;
     DCH1INTbits.CHDHIF = 0;
     DCH1INTbits.CHDDIF = 0;
     DCH1INTbits.CHSHIF = 0;
     DCH1INTbits.CHERIF = 0;

     
    And the problem has disappeared, the interruption of the DMA still works despite the fact that the USB port is connected to the PC.

    I'm not sure if this is a bad thing or it can affect any other part of the code since the flags I am deleting are in 1 logical when there is no problem (No connection to the USB port) and when the problem is generated (MCU connected to the PC via USB)


    I have also performed communication tests of the USB module sending and receiving data and it seems to work correctly.
    #11
    ric
    Super Member
    • Total Posts : 27979
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: offline
    Re: Why does the DMA handler configured as a CRC generator not respond? 2019/12/11 20:32:57 (permalink)
    0
    DominusT
     DCH1INTbits.CHCCIF = 0;
     DCH1INTbits.CHDHIF = 0;
     DCH1INTbits.CHDDIF = 0;
     DCH1INTbits.CHSHIF = 0;
     DCH1INTbits.CHERIF = 0;


    I suspect that could be done a lot quicker with:
    DCH1INTCLR = _DCH1INT_CHCCIF_MASK | _DCH1INT_CHDHIF_MASK | _DCH1INT_CHSHIF_MASK | _DCH1INT_CHERIF_MASK;

     
    You didn't mention which PIC32 device you are using. A number of the .h files seem to have these constants with "_DCH0INT..." instead of "_DCH1INT..."

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #12
    DominusT
    Super Member
    • Total Posts : 1419
    • Reward points : 0
    • Joined: 2005/07/22 08:31:18
    • Status: offline
    Re: Why does the DMA handler configured as a CRC generator not respond? 2019/12/12 06:29:10 (permalink)
    0
    ric
    DominusT
     DCH1INTbits.CHCCIF = 0;
     DCH1INTbits.CHDHIF = 0;
     DCH1INTbits.CHDDIF = 0;
     DCH1INTbits.CHSHIF = 0;
     DCH1INTbits.CHERIF = 0;


    I suspect that could be done a lot quicker with:
    DCH1INTCLR = _DCH1INT_CHCCIF_MASK | _DCH1INT_CHDHIF_MASK | _DCH1INT_CHSHIF_MASK | _DCH1INT_CHERIF_MASK;

     
    You didn't mention which PIC32 device you are using. A number of the .h files seem to have these constants with "_DCH0INT..." instead of "_DCH1INT..."



    Hi, thanks for write.

    Regarding cleaning those flags, all it does is postpone the problem a little more. The hardware works for about 45 minutes or an hour and the problem happens again. The point is that despite being cleaned, some return to 1 and was detected as follows:

     DCH1INTbits.CHDHIF = 0;
     DCH1INTbits.CHDDIF = 0;
     DCH1INTbits.CHSHIF = 0;
     DCH1INTbits.CHERIF = 0;
    if (DCH1INTbits.CHCCIF || DCH1INTbits.CHDHIF || DCH1INTbits.CHDDIF || DCH1INTbits.CHSHIF || DCH1INTbits.CHERIF)
    {
         Nop();
    }

     
    putting a breaking point in NOP it was discovered that the flags, despite being cleaned, are activated elsewhere.
     
    What I am going to do at this moment is to wait for a while in that where it awaits that the DMA has finished the calculation of the CRC if a certain time elapses, cleans the flags and renounces the calculation of the CRC as follows:


    case APPCRC_CALCULATE_CRC:

            {
                appcrcData.errorCRC = 0x00;
                SYS_DMA_ChannelCRCSet(channelHandle, crc);
                SYS_DMA_ChannelTransferAdd(channelHandle, ramBuff,
                            (length + (crc.polyLength/8)) ,
                            ramBuff,(length + (crc.polyLength/8)),
                            (length + (crc.polyLength/8)));
                SYS_DMA_ChannelForceStart(channelHandle);
     
                appcrcData.getInstantValueTMRCore = returnInstantValueTMRCore ( ) ;//get the instant value of the Core Timer
                appcrcData.state = APPCRC_CALCULATING_CRC;

                break;
            }
            case APPCRC_CALCULATING_CRC:
           {
                 if ((returnInstantValueTMRCore (  )  - appcrcData.getInstantValueTMRCore)> _1ms)//I wait 1 ms
                 {
                      DCH1INTbits.CHCCIF = 0;
                      DCH1INTbits.CHDHIF = 0;
                      DCH1INTbits.CHDDIF = 0;
                      DCH1INTbits.CHSHIF = 0;
                      DCH1INTbits.CHERIF = 0;
                      appcrcData.state = APPCRC_CALCULATE_CRC;// I restart the calculation of the CRC
                }
                break;
          }


     
    Regarding what MCU I'm working with is the PIC32MZ2048EFM100 with Harmony v2.06
     
    I don't understand this comment very well:
    ric
    A number of the .h files seem to have these constants with "_DCH0INT..." instead of "_DCH1INT..."

     
    But what I can tell you that I was initially working with channel 0, and I switched to 1 thinking that there would be some change, but the problem is the same.
    post edited by DominusT - 2019/12/12 06:32:29
    #13
    DominusT
    Super Member
    • Total Posts : 1419
    • Reward points : 0
    • Joined: 2005/07/22 08:31:18
    • Status: offline
    Re: Why does the DMA handler configured as a CRC generator not respond? 2019/12/12 12:12:22 (permalink)
    0
    The hardware is running about 6 hours and there have been no problems. Although it seems that the problem has been solved, I think it is a cumbersome solution.
    #14
    DominusT
    Super Member
    • Total Posts : 1419
    • Reward points : 0
    • Joined: 2005/07/22 08:31:18
    • Status: offline
    Re: Why does the DMA handler configured as a CRC generator not respond? 2019/12/19 06:16:47 (permalink)
    0
    Hi. Microchip technical support has suggested that the priority of the interruption of the DMA-USB should be equal to the priority level of the simple DMA as the image attached.
     
     The problem persists, but I think I understand the problem. Since there are two interruptions with the same peripheral, for example that of the DMA-USB could clear the flag of that interruption of the simple DMA and that is why the problem mentioned.
    Now, the simple DMA interruption, I think it never cleans a flag associated with the DMA-USB interrupt and that is why the USB doesn't stop working.

    Attached Image(s)

    #15
    DominusT
    Super Member
    • Total Posts : 1419
    • Reward points : 0
    • Joined: 2005/07/22 08:31:18
    • Status: offline
    Re: Why does the DMA handler configured as a CRC generator not respond? 2019/12/19 07:40:27 (permalink)
    0
    I have been testing the interrupts and I realized that the DMA-USB interrupt only happens when sending or receiving data between the PC and the MCU.
     
    Therefore, when the USB is connected to the PC, such interruption (DMA-USB) never happens, that is, it isn't invoked by device enumeration.
     
    In other words, the DMA-USB interrupt is not related to the problem.
     
    The interruption that happens when connecting the MCU to the PC via USB iis one that has an interruption level equal to 4 of my previous answer. (#15)
    #16
    DominusT
    Super Member
    • Total Posts : 1419
    • Reward points : 0
    • Joined: 2005/07/22 08:31:18
    • Status: offline
    Re: Why does the DMA handler configured as a CRC generator not respond? 2019/12/20 10:01:33 (permalink)
    0
    The MCHP technical service has managed to reproduce the problem. At the moment the solution is not to work with the USB interrupt and that way this module does not use the DMA.
    #17
    Jump to:
    © 2020 APG vNext Commercial Version 4.5