• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 520 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AM4376: CRC of .text not matching during runtime calculation

Arun Cherian
Intellectual 510 points
Part Number: AM4376

Using CCS10 and pdk_am437x_1_0_15 for AM4376 Cortex-A. I'm trying to verify CRC of .text and .data during runtime. 

I added a section to my linker script which I populate after a 2 pass link, once to build the program, then export the sections to a local .bin file, get its CRC32 and add it during the seconds link pass, similar to what's described in https://stackoverflow.com/questions/24150030/storing-crc-into-an-axf-elf-file

.crc : ALIGN(4)
{
__crc_start__ = .;
crc_table = .;
LONG(CRC_TEXTA);
LONG(CRC_DATAA);
LONG(CRC_BSSA);
__crc_end__ = .;

} > DDR0

.text : ALIGN(4)
{
__text_start__ = .;
*init.o (.text)
*(.text*)

KEEP(*(.init))
KEEP(*(.fini))

/* .ctors */
*crtbegin.o(.ctors)
*crtbegin?.o(.ctors)
*(EXCLUDE_FILE(*crtend?.o *crtend.o) .ctors)
*(SORT(.ctors.*))
*(.ctors)

/* .dtors */
*crtbegin.o(.dtors)
*crtbegin?.o(.dtors)
*(EXCLUDE_FILE(*crtend?.o *crtend.o) .dtors)
*(SORT(.dtors.*))
*(.dtors)

*(.rodata*)

KEEP(*(.eh_frame*))
__text_end__ = .;
} > DDR0

Everything compiled fine and links, during runtime, my .data CRC compares fine, but .text fails. I have paused on the debugger and exported out the dump of the memory from __text_start__ to __text_end__ and the .bin export matches the temp .bin I created during CRC calculation. However it does not compute correct while it runs. My .text section isn't that big, around 700kb, and the same CRC function matches the .data and .bss CRCs (the BSS section is way bigger at around 40MB). I was wondering how the .text CRC fails. I have run it the program via debugger and via NFS, still .text does not match. I have added 

__asm__("dmb");
__asm__("isb");

instructions in between CRC32 checks in case the pipelines get corrupted. I have copied over the .text section into a global array and run CRC32 on it, still fails. 

  • 0
    Intellectual 510 points

    My CRC32 is the standard algorithm, using the crc32_4bytes from https://create.stephan-brumme.com/crc32/ with a pre-populated lookup table. The CRC32s generated matches against CRC32 GUI tools like HxD etc.

  • 0 in reply to Arun Cherian
    TI__Mastermind 29348 points

    Hi Arun,

    I don't have any detailed recommendations or specific guidance to provide on this issue.

    Here are some high-level ideas on how to debug further:

    • Double check the .text section contents used for the offline CRC computation matches the .text section contents used on the target at run time. I understand you think you've done this, but maybe there is still some mismatch.
    • It's not clear where the offline CRC algorithm executes. Is this your own code / executable? Is the CRC computation included in the linker? Confirm the offline & run-time CRC code matches.
    • See if the issue occurs for any .text section.
    • Reduce the size of the .text section (e.g. a simple program containing a trivial main() function only). Step through offline & run-time CRC code to see where the mismatch occurs.

    Regards,
    Frank

  • 0 in reply to Frank Livingston
    Intellectual 510 points

    Thanks for the pointers Frank. I tried with a small helloworld and it works fine, with the same CRC calculation function. The .text section for the Helloworld program is only 18kb as opposed to 700Kb for my real one. 

    I'm wondering what could be causing this to fail for larger .text areas. Size per se doesnt seem to be the issue as I have done it over much larger sections. I have noticed if I pause in the debugger and later resume the CRC calculations intermittently come up correct. 

    The crc check is done first thing after reset vector, could some HW interrupt be causing some error? Or the debugger somehow?

  • 0 in reply to Arun Cherian
    TI__Mastermind 29348 points

    Hi Arun,

    >> Size per se doesnt seem to be the issue as I have done it over much larger sections

    Can you split the CRC calculation into pieces, and latching the output for the different pieces? Then compare this with a similar offline CRC computation.This might help you narrow down where the failure occurs. What type of memory is used for the .text section?

    >> I have noticed if I pause in the debugger and later resume the CRC calculations intermittently come up correct.
    >> Or the debugger somehow? 

    Emulation halt will change system timing vs. a normal execution.

    >> The crc check is done first thing after reset vector 

    I expect the reset vector to branch to a startup routine, and the startup routine to branch to main() upon completion. Is the CRC calculation the first task performed in main()?

    >> could some HW interrupt be causing some error?

    I expect HW interrupts to be disabled on entering main(). Even when a HW interrupt is enabled, a HW ISR written in C will save/restore processor context to preserve the interrupted context.

  • 0 in reply to Frank Livingston
    Intellectual 510 points

    Can you split the CRC calculation into pieces, and latching the output for the different pieces? Then compare this with a similar offline CRC computation.This might help you narrow down where the failure occurs. What type of memory is used for the .text section?  DDR is used for all the sections. I have done this chunking, and I copy the runnning CRC into an array. I see the running CRC get corrupted at random points.

    Emulation halt will change system timing vs. a normal execution. - even with HW breakpoints? 

    I expect the reset vector to branch to a startup routine, and the startup routine to branch to main() upon completion. Is the CRC calculation the first task performed in main()? The PDK uses reset vector -> start_boot in startup.c -> main(). The CRC check is the first item in start_boot.

    I expect HW interrupts to be disabled on entering main(). Even when a HW interrupt is enabled, a HW ISR written in C will save/restore processor context to preserve the interrupted context. - How about SVC_handler? Is it possible the startup routines change modes from Service to Supervisor and that intermittently messes with the registers somehow?

  • 0 in reply to Frank Livingston
    Intellectual 510 points

    Hello Frank,

    I run the CRC32 1 byte at a time, and I write the crc and data to a global array and print it out. I see the CRC computes wrong when I'm at the 72th byte. It somehow reads in the wrong data. The data at position 72 is not 5, its 6E. This mismatch goes on for a few bytes and then the data matches. But by that time the CRC is mangled. 

    Output from on target program

    crc[0] E8B7BE43 Data: 61
    crc[1] E98478FB Data: 63
    crc[2] C55CD5B6 Data: 65
    crc[3] 36C97C53 Data: 3A
    crc[4] 1B380677 Data: 20
    crc[5] 1ACE860B Data: 45
    crc[6] EFC0B4DC Data: 6E
    crc[7] 0AE004E3 Data: 74
    crc[8] D6D3299C Data: 65
    crc[9] 9566F3DB Data: 72
    crc[10] F7F85BDE Data: 69
    crc[11] 1994A45A Data: 6E
    crc[12] 8A733738 Data: 67
    crc[13] C1E404EC Data: 20
    crc[14] 17793037 Data: 54
    crc[15] 29C1DAD8 Data: 68
    crc[16] E42864A1 Data: 72
    crc[17] 4EEFC140 Data: 65
    crc[18] 9E251012 Data: 61
    crc[19] 6BFA1E94 Data: 64
    crc[20] 7BD5BBC0 Data: 78
    crc[21] 95CBF549 Data: 2E
    crc[22] 0141D083 Data: 2E
    crc[23] 7A647108 Data: 2E
    crc[24] 3C76EAD0 Data: 0A
    crc[25] B438A2AD Data: 0A
    crc[26] 7AD1087A Data: 00
    crc[27] 62A8A6A7 Data: 00
    crc[28] 7A07987E Data: 0A
    crc[29] 85105D30 Data: 0A
    crc[30] CEEB9EB2 Data: 61
    crc[31] 2318E651 Data: 63
    crc[32] F39503DE Data: 65
    crc[33] 75965CEF Data: 3A
    crc[34] D9ACA6F0 Data: 20
    crc[35] F7B4918B Data: 42
    crc[36] 75927D7D Data: 6F
    crc[37] C67621BF Data: 61
    crc[38] 371127A1 Data: 72
    crc[39] 393BC895 Data: 64
    crc[40] A98AFFEB Data: 5F
    crc[41] D11D877E Data: 69
    crc[42] CF64E26E Data: 6E
    crc[43] 4CA91ECC Data: 69
    crc[44] 17F47D2D Data: 74
    crc[45] A27FEF7F Data: 28
    crc[46] 50A864A3 Data: 29
    crc[47] A6E39573 Data: 20
    crc[48] CF131C7C Data: 63
    crc[49] 5673BD4F Data: 6F
    crc[50] 0734DDD4 Data: 6D
    crc[51] 03BEBCA1 Data: 70
    crc[52] 37D4EF3C Data: 6C
    crc[53] C082D232 Data: 65
    crc[54] 4D7D89FA Data: 74
    crc[55] B2FF1CD1 Data: 65
    crc[56] C3B11BCD Data: 0A
    crc[57] 3714E09B Data: 00
    crc[58] B5E8B1A1 Data: 00
    crc[59] 73669442 Data: 00
    crc[60] AA7640BB Data: 0A
    crc[61] 6ECE1AD7 Data: 0A
    crc[62] F06E372E Data: 61
    crc[63] DA9FBC97 Data: 63
    crc[64] 816BE301 Data: 65
    crc[65] 63886D4A Data: 3A
    crc[66] 7F06EFA6 Data: 20
    crc[67] 86A3BE4B Data: 50
    crc[68] 778EF958 Data: 6C
    crc[69] F3C195C1 Data: 6C
    crc[70] C546905B Data: 5F
    crc[71] 217ED855 Data: 49
    crc[72] B948C0A1 Data: 05
    crc[73] 736A3433 Data: 00
    crc[74] 6DA1E4AF Data: 00
    crc[75] 9406F010 Data: 00

    Output from CRC program that runs on objcopy .text export on Windows

    crc[0] E8B7BE43 Data: 61
    crc[1] E98478FB Data: 63
    crc[2] C55CD5B6 Data: 65
    crc[3] 36C97C53 Data: 3A
    crc[4] 1B380677 Data: 20
    crc[5] 1ACE860B Data: 45
    crc[6] EFC0B4DC Data: 6E
    crc[7] 0AE004E3 Data: 74
    crc[8] D6D3299C Data: 65
    crc[9] 9566F3DB Data: 72
    crc[10] F7F85BDE Data: 69
    crc[11] 1994A45A Data: 6E
    crc[12] 8A733738 Data: 67
    crc[13] C1E404EC Data: 20
    crc[14] 17793037 Data: 54
    crc[15] 29C1DAD8 Data: 68
    crc[16] E42864A1 Data: 72
    crc[17] 4EEFC140 Data: 65
    crc[18] 9E251012 Data: 61
    crc[19] 6BFA1E94 Data: 64
    crc[20] 7BD5BBC0 Data: 78
    crc[21] 95CBF549 Data: 2E
    crc[22] 0141D083 Data: 2E
    crc[23] 7A647108 Data: 2E
    crc[24] 3C76EAD0 Data: 0A
    crc[25] B438A2AD Data: 0A
    crc[26] 7AD1087A Data: 00
    crc[27] 62A8A6A7 Data: 00
    crc[28] 7A07987E Data: 0A
    crc[29] 85105D30 Data: 0A
    crc[30] CEEB9EB2 Data: 61
    crc[31] 2318E651 Data: 63
    crc[32] F39503DE Data: 65
    crc[33] 75965CEF Data: 3A
    crc[34] D9ACA6F0 Data: 20
    crc[35] F7B4918B Data: 42
    crc[36] 75927D7D Data: 6F
    crc[37] C67621BF Data: 61
    crc[38] 371127A1 Data: 72
    crc[39] 393BC895 Data: 64
    crc[40] A98AFFEB Data: 5F
    crc[41] D11D877E Data: 69
    crc[42] CF64E26E Data: 6E
    crc[43] 4CA91ECC Data: 69
    crc[44] 17F47D2D Data: 74
    crc[45] A27FEF7F Data: 28
    crc[46] 50A864A3 Data: 29
    crc[47] A6E39573 Data: 20
    crc[48] CF131C7C Data: 63
    crc[49] 5673BD4F Data: 6F
    crc[50] 0734DDD4 Data: 6D
    crc[51] 03BEBCA1 Data: 70
    crc[52] 37D4EF3C Data: 6C
    crc[53] C082D232 Data: 65
    crc[54] 4D7D89FA Data: 74
    crc[55] B2FF1CD1 Data: 65
    crc[56] C3B11BCD Data: 0A
    crc[57] 3714E09B Data: 00
    crc[58] B5E8B1A1 Data: 00
    crc[59] 73669442 Data: 00
    crc[60] AA7640BB Data: 0A
    crc[61] 6ECE1AD7 Data: 0A
    crc[62] F06E372E Data: 61
    crc[63] DA9FBC97 Data: 63
    crc[64] 816BE301 Data: 65
    crc[65] 63886D4A Data: 3A
    crc[66] 7F06EFA6 Data: 20
    crc[67] 86A3BE4B Data: 50
    crc[68] 778EF958 Data: 6C
    crc[69] F3C195C1 Data: 6C
    crc[70] C546905B Data: 5F
    crc[71] 217ED855 Data: 49
    crc[72] 63287871 Data: 6E
    crc[73] C10D5FA3 Data: 69
    crc[74] CA74A5A5 Data: 74
    crc[75] 41C164B5 Data: 28

  • 0 in reply to Arun Cherian
    TI__Mastermind 29348 points

    Hi Arun,

    Does this problem occur every time you execute the program, or is it intermittent / random? Does the problem always start with byte 72, or can the failure start at some other location from one run to the next?

    If you inspect byte 72 from the CCS memory window, does the data correctly show as 0x05?

    Have you tried linking the .text section to a different region in DDR?

    I'm wondering about your EMIF settings.

    Regards,
    Frank