This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS570LS2134: CRC Module Computation using data supplied by DMA

Other Parts Discussed in Thread: TMS570LS2134

Hello there,

I write application for the TMS570LS2134 MCU and would like to runtime checking the application binary code residing in the 2 MB Flash ROM. For this I set the main application area ROM from 0x00000000 to 0x001FDFFF, which is 2MB-8KB in size, and use 0x001FE000 to 0x001FFFFF (8KB) to store the precomputed CRC code of 64 bits or 8 bytes.

So I configure the DMA channel to transfer 8160 frames of 32 elements each. The transfer element size is 64 bits.

To match the DMA transfers, I configure accordingly the CRC module to generate End Of Compression (EOC) interrupt once the 64-bit counts reaches 261120.

I then use another simple project to flash only 8 bytes from memory address 0x001FE000 to 0x001FE007 for the precomputed CRC code. All surrounding addresses contain 0xFF, blank.

With this configuration, the CRC module EOC interrupts are generated cyclically, occurrences are with accordance to the programmed frequency. Every time when I change a single bit in the code, the computed CRC is changed. No problem until now.

However, to be sure that the DMA/CRC Module is reaching the end of address 0x001FDFFF, I purposely write a dummy 8-byte data to memory address range from 0x001FDFF8 to 0x001FDFFF. To my surprise, the newly computed CRC is the same as the previous one, which means that at least the last 8 bytes of data are not taken into the CRC computation!

Do you see what is my problem and any suggestion to troubleshoot?


Thanks!

  • Hello Chuck,

      For the CRC to generate an EOC interrupt, it means that it must have received a total of 261120 64-bit writes from the DMA. However, the CRC does not know from which address the data is coming from. So in the extreme case where the source address in the DMA is setup for fixed address mode then it is possible that the DMA transfers 261120 64-bit data to the CRC but it is all coming from the same address. Of course I wouldn't think this is your problem. But it is something to check on the trigger type and the addressing mode.  I also wouldn't think that you may have any un-intentional writes to the PSA register from the CPU in the code. This can also lead the CRC to generate the interrupt before the DMA has completed the transfer.

      What if you store dummy data to the last 16 bytes or even the last 32 bytes? Do you still get the same CRC signature?

      Since 2MB is kind of large, I will also suggest that you start with a smaller size to see if it works and then scale up the transfer size grandually.

     

  • Hi Charles,

    I understand what you're saying and will investigate. Still wondering if you can see any pop-to-eyes problem from the numbers and memory addresses that I've provided.

    From the time when I receive the CRC EOC interrupt, I can set a breakpoint. What are the DMA registers that I can check to see at this moment by assuming that the DMA activities are suspended upon breakpoint:

    1. Number of transfers been performed.
    2. Last memory address of the transfer.

    Thanks!

  • Hi Chuck,

      Please make sure you also set the Debug Mode to 0x3 for the DMA in the GCTRL at offset 0x0 so that it will immediately stop the transfer when debug mode is entered.

      Once the CPU and the DMA are stopped you can then read the PBACSADDR and PBACTC registers at offset 0x198 and 0x1A0. These two registers show the current active channel source address and transfer count. However, be careful the time from which the interrupt is generated until it is serviced may take some cycles and by which time the DMA may have tranferred a few more data before breakpoint is taken. For example, if you set up the CRC to generate EOC after 10 transfers and you also setup the DMA to do 10 transfers but  by mistake accidently the CPU has two un-intentional writes to the CRC. The CRC will think that 10 writes has happened and generates the interrupt before the DMA completes the 10 transfers. But by the time you are in the CRC interrupt ISR and breakpoint, the DMA may have transferred all 10. 

      One more debug feature you can use is the watch point register at offset 0x184. You can setup to watch for address 0x001FDFF8 which is the one that you reported not being transfered. If DMA ever reads from this address then a debug request will be generated to the CPU and halt the CPU. This means that DMA has reached this address. Or you can setup for a range of address. For example setup the watch mask register at offset 0x188 such that if the DMA reads the second 1MB byte of the flash then it will halt the CPU. Just play with it to narrow down which addresses the DMA fails to read.

     

  • Hi Charles,

    The DMA is configured to run only once every 60 seconds, so no possibility to go any further after the breakpoint is entered. Beside that, I've no concern on the concurrent write access in another place in code, because the computed CRC result remains the same every single time.

    Following your instructions, below is the reading after entering the breakpoint:

    • DMAPBACSADDR = 0x001FE000 (the byte after the last byte used in the CRC computation)
    • DMAPBACDADDR = 0xFE000060 (destination address: good)
    • DMAPBACTC = 0x00000000 (why???)

    With these results, can I assume that the DMA transfer to CRC Module has reached the end (from 0x00000000 to 0x001FDFFF)?

    How to explain DMAPBACTC=0?

    Thanks for your help!

  • Hi Chuck,

      The DMAPBACTC is showing the active transfer count left for the transfer. Since the transfer is complete it is showing 0 meaning nothing left to transfer.

      Can you try to put some dummy data in the last 16 bytes or even the last 32 bytes? Will you see different signature?

      From my side, I will also run some experiment.

  • Hi Charles,

    To simplify thing, I now only has one DMA active, every 10 seconds (accelerated for debug only). When I put DMAWPR=0x001FDFF8 (or even 0xFF8 - beginning of Flash ROM), DMAWMR=0x0, and DEBUG_MODE=0x3, even though I continue to have CRC Compression Completion interrupt every 10 seconds, but the CPU is never halted.

    Anything wrong in my setting?

    I'll continue with your suggestion ...

    Thanks!

  • Hi Chuck,

      You need to setup the DCTRL register at offset 0x180. You will need to write to bit 0 (DBGEN bit field) using the debugger to enable the debug request.

     

  • Hi Chuck,

      I created an example project. The project will operate the CRC in Semi-CPU mode in conjunction with DMA. I use the same frame count and element count as in your application. Also I have a dummy data at location 0x1FDFF8. Use the memory browser to location 0x1FDFF8 you will find the dummy data. In the CRC completion complete interrupt notification you can put a breakpoint. You can read out the CRC value from the PSASECSIGL1 and PSASECSIGH1 registers. You can try to alter the dummy data to a different values and then recompile and rerun and you will see that the CRC value in the PSASECSIGL1 and PSASECSIGH1 registers change. This should prove that the DMA has read from 0x1FDFF8 and written to the CRC module. 

    8802.LS31x_CRC_Semi_CPU.zip

  • Good morning Charles,

    Thank you very much for such a personalized help. I'm using IAR EWARM and couldn't easily integrate your project now, but can only inspect the numbers that you have implemented, which are the same as the one that I use in my project.

    To advance in my coding, instead of using the last 8KB of the 2MB Flash ROM for constants storage (CRC code for instance), I split the Flash into two regions, 1MB+1MB, since my code is currently under 100KB for the time being and is stored in the first 1MB, and all other constants stored in the second 1MB. Everything works fine, so that when I've modified the last couple of bytes of the first 1MB, the CRC module provides a different code accordingly.

    I'll sort out the problem that I've observed later, probably with IAR's technical support.

    Best regards!