TMS570LS2134: CRC Module Computation using data supplied by DMA

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.

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!