TMS570LS3137: UniFlash v8.8.0 behavior with MCU programming & CRC

Additional test results have proved that using the UniFlash utility, Flash ROM read and export functions in HEX format (for 1 MB) from any steps above (including step 9)  gives identical binary .HEX output files, except step 8 (filled with 0x00), yet the CRC at step 9 is not the same.

I start doubting the TMS570 CRC engine configuration (memory alignment etc.). Below are my configuration for the DMA and the CRC engine.

DMA CH15 configuration:

    // ------------------------------------------------------------------------
    // configure DMA CH15 for CRC compression of the Flash ROM (1 MB)
    // ------------------------------------------------------------------------

    DMACP15ISADDR   = (u32)((u32 *) 0x00000000);    // set to start of Flash ROM (initial source)
    DMACP15IDADDR   = (u32) &PSA_SIGREGL1;          // set to channel 1 PSA signature low (fix destination)

    DMACP15ITCOUNT_bit.IETCOUNT = 32;       // element transfer=32
    DMACP15ITCOUNT_bit.IFTCOUNT = 4096;     // frame transfer=4096

    DMACP15CHCTRL   = 0x0000F108;           // RD/WR size: 64 bits, transfer type is one block
                                            // RD mode: post-increment, WR mode: constant
                                            // auto-initiation disabled

    DMACP15EIOFF    = 0x00000000;           // element index address offset: source=destination=0
    DMACP15FIOFF    = 0x00000000;           // frame index address offset: source=destination=0

CRC engine configuration:

    CRC_CTRL0_bit.CH1_PSA_SWREST = 1;       // reset channel 1 PSA signature register
    CRC_INTS_bit.CH1_CCITENS     = 1;       // semi-CPU mode: enable CH1 CC interrupt

    // CRC Pattern Count × CRC Sector Count = DMA Element Count × DMA Frame Count
    // must match DMA CH15 configuration for other details

    CRC_PCOUNT_REG1_bit.CRC_PAT_COUNT = 131072; // pattern count: 4096*32=131072, 64-bit words
    CRC_SCOUNT_REG1_bit.CRC_SEC_COUNT = 1;      // sector count: 1 (4096*32*8=1 MB)

    CRC_CTRL2_bit.CH1_MODE = 0x0;           // set channel 1 to data capture mode (required step after ISR)
    CRC_CTRL2_bit.CH1_MODE = 0x2;           // set channel 1 to semi-CPU mode

    CRC_STATUS = 0x0000FFFF;                // clear all interrupts

    CRC_CTRL0_bit.CH1_PSA_SWREST = 0;       // release PSA signature register to operational state

Could any expert on the CRC engine help?

We continue our investigation and this is what we've found.

If we compile with IAR EWARM, release mode, 1MB Flash ROM been allocated from 0x0 to 0xFFFFF, with unused bytes filled with 0x00. This action outputted both .OUT and .HEX files.

Now with those files, flashing the MCU ROM with either IAR EWARM or UniFlash gave always the same CRC code 0xF611XXXXXXXXXXXX, consistent with step 9 above, no more discrepancies!

This is what I've found in the TRM SPNU499C para. 14.2.3: "CRC Controller supports doubleword, word, half word and byte access to the PSA Signature Register. During a non-doubleword write access, all unwritten byte lanes are padded with zero’s before compression.".

If somehow the padding with '0' feature was used by the CRC engine as stated above, which caused the discrepancies, why this feature is been used even with DMA instructions to always transfer 8-byte doubleword from 0x0 to 0xFFFFF (1MB including unused memory bytes)?

Thanks.

Hi Chuck Wong,

My sincere apologies for the delayed response, i was stuck with other issues in this mean time.

Are you still stuck with this issue? I never used IAR for my testing's below i usually use CCS.

Let me know if you have any other findings as well. I am working on your issue and will try to provide my updates soon.

--
Thanks & regards,
Jagadish.

Good morning Jagadish,

Thank you for your reply. We don't have new updates to the case since then. Just as described above, 1MB is a multiple of the 8-byte transfers, so the CRC Engine should NOT pad with 0x00, however it looks that way considering my experiments when filling the unused 1MB memory with 0x00 (working) instead of 0xFF (NOT working).

Thank you for the follow-up.

Hi Chuck Wong,

Can you please setup one live debugging session as i don't have IAR workbench now.

I will be available from 10AM to 8PM IST (Indian Standard Time), so based on your availability please setup one live debugging session. 

--
Thanks & regards,
Jagadish.

Thank you for the live debugging session proposal. 

Unfortunately, our setup is not ready to continue troubleshooting this issue. For the time being, we opted to use 0x00 filled instead of 0xFF to workaround the problem.

However, I summarize our experiments and additional evidences below for your investigation. If you could hint anything, we would appreciate.

• Using DMA CH15 double-word (64-bit) transfers to compress Flash ROM locations to the CRC engine PSA register, semi-automatic mode.
• The software binary code is exactly 263310 bytes (257.138671875 kB). To make it divisible by 8 for DMA/CRC, we have to round it up to 263424 bytes (257.25 kB).
• Use 0xFF to fill unused memory space to 1MB.
• According to the results below, we concluded that the mismatched CRC happened when the calculation range is between 270kB and 275kB.
• Please note that: Even when both CRC mismatched, the device memory export using TI UniFlash for the 1MB space are ALWAYS the same (identical exported Intel HEX file).

Good day Jagadish,

I've updated the screen capture of my last reply for more clarity on the SEQUENCE of Flash programming alternating between IAR EWARM IDE and TI UniFlash v8.8.0, with either 0x00 filling or 0xFF filling of unused memory space in the first MB of the Flash ROM.

Thanks.

Sorry I've updated the capture again, flash sequence 4 and 5 were reversed earlier. Now it is OK, as below: 

Hi Chuck,

My sincere apologies for the late response, i was stuck with other issues in this mean time.

Can you please confirm whether you still stuck with this issue or not.

If yes, then i will immediately try to reproduce and debug this issue from my side.

--
Thanks & regards,
Jagadish.

Hello Jagadish,

We are still at the same point and would appreciate your assistance. Please keep me posted.

Best regards!

Hi Chunk,

Now i spend some time on this issue and i don't find any root cause for the issue.

Chuck Wong said:

Please note that: Even when both CRC mismatched, the device memory export using TI UniFlash for the 1MB space are ALWAYS the same

And this is strange to me, even when there is CRC mismatch, but the Uniflash export data is same.

Until we debug this issue, it may not be possible to find the root cause.

I have one more suggestion is that, i never used IAR workbench before but in CCS we can do one thing.

I mean after flashing the code from Uniflash, we can still connect to the controller without flashing the code again.

For example, see the below steps:

1. First i flashed the code from UniFlash:

2. Now launching the configurations from CCS:

3. Now i connected to the target core:

4. Once i did this then i can be able to see the memory data of the controller, without any new code programming:

5. I can also be able to see the disassembly code:

6. We can also do the step by step debugging of assembly also.

7. Why i am suggesting this procedure is that, we can watch how the data from uniflash programmed into the controller. This might be helpful in this scenario.

Again, i am not sure how to do this in IAR.

--
Thanks & regards,
Jagadish.

Yeah very strange. The UniFlash exports are binary-identical and was checked using Beyond Compare. You understand now why there is this capture (from Excel) trying to locate the area where the mismatch fault occurred, which is between 270kb and 275kb.

It is because I cannot check on the exact location by comparing the dumps (they are the same), the only thing that I could do is to modify the SW to compute the CRC for a given range within the 0xFF-filled 1MB space until the CRC fault is found. 

Bottom line as today:

• With 0x00-filling unused memory to 1MB, same CRC, using UniFlash or IAR EWARM, programmed in any order.
• With 0xFF-filling unused memory to 1MB, different CRC (UniFlash and IAR EWARM) - mismatch location is between 270kB and 275kB (SW modification on DMA transfers size and CRC compression engine receiving size).
• By looking at the Excel capture (previous posts), we get a feeling that when program the 0xFF-filled 1MB file by UniFlash, it looks like that it "doesn't write correctly Flash location with 0xFF". Does it assume that 0xFF doesn't need to be written because it is the default memory state??? ... but again, why exports gave the same output???
• Again, what I suspect is how the TMS570 64-bit CRC engine handles things when accessing memory (double-word or 8 bytes aligned).

How long can you leave this post opened? We might get back to you with a setup that you can experiment yourself using Remote Desktop, if you wish so.

Thank you for your support.

Hi Chunk,

My apologies i am on Christmas holidays, and didn't get enough time on this issue.

Usually most of the issues i will solve within a week only, this issue is taking more time because i can't be able to reproduce the issue at my end and i need your codes for this.

Maybe it would be helpful if you gave remote setup and guide me once exactly how you are doing, so that i can further debug and rectify the issue from my end.

--
Thanks & regards,
Jagadish.

Hi Jagadish,

Happy New Year!

And yes, please send me an invite for meeting so I may share my desktop for troubleshooting. I'm located at the Eastern Time Zone (New York) and we will be available starting at 10:00AM.

Thanks.

My Sincere apologies for the delay in late response.

I was off for few days due to important festival in my region.

I will be available for anytime between 10AM to 8PM IST (Indian standard Time) through Webex or Teams. You can create the meeting request based on your availability.