Henrik Glader

Henrik Glader
15 ポイント. 0 回答 2 質問 0 フォロワー 0 フォロー
フォロー

統計

  • 0 answers, 0 selected
  • 2 questions, 0 solved
  • 1 年, 8 ヶ月, 9 日 のメンバー
  • 1049 プロフィール閲覧
  • Last seen 8月 28, 2024

ポイント

Total 15
0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
+1
7月 26, 2024 Commented Hi there : ) When I removed the two AT() from the linker script the resulting .mot file did not change compared to the bad one. There may be some problems with ld.exe... Anyway, here are some snipplets: Source code regarding .sbss .sdata initialization: - - - - - - - - - - - - - - - - - - - - - - - - - static int InitiateSmallData(void) { register int R1 __asm__ ("r1"); // SMOVF/SSTR.L target address and return register register int R2 __asm__ ("r2"); // SMOVF/SSTR.L source address/data register register int R3 __asm__ ("r3"); // SMOVF/SSTR.L 32-bit/8-bit word count register __asm__ __volatile__ ( // zero initiate GP->_sbss "MOV %5,%1\n\t" // R1->_sbss "TST #3,%1\n\t" // PSW(SZ) = 0b11 & &_sbss "BNZ LDataBad\n\t" // non-even alignment -> FAIL "MOV #0,%2\n\t" // R2 = 0x00000000 "MOV %6,%3\n\t" // R3->_sbss_next "TST #3,%3\n\t" // PSW(SZ) = 0b11 & &_sbss_next; "BNZ LDataBad\n\t" // non-even alignment -> FAIL "SUB %1,%3\n\t" // R3 = sizeof(_sbss) "SHLR #2,%3\n\t" // R3 /= sizeof(int) "SSTR.L \n\t" // memset(_sbss,0,sizeof(_sbss)) // initiate GP->_sdata "MOV %7,%1\n\t" // R1->_sdata "MOV %9,%2\n\t" // R2->_idata "MOV %8,%3\n\t" // R3->_sdata_next "SUB %1,%3\n\t" // R3 = sizeof(_sdata) "SMOVF \n\t" // memcpy(_sdata,_idata,sizeof(_sdata)) // initiate GP (all possible gp registers) "MOV %4,r13\n\t" // R13->_gp - gcc view (when int-register plus pid is 0) "MOV %5,r12\n\t" // r12->_sbss - lkr view (when int-register plus pid is 1) "CMP r13,r12\n\t" // PSW(OSZC) = lkr - gcc "BNE LDataBad\n\t" // different view -> FAIL "MOV r13,r11\n\t" // r11->_sbss "MOV r13,r10\n\t" // r10->_sbss "MOV r13,r9\n\t" // r9->_sbss "MOV r13,r8\n\t" // r8->_sbss "LDataGood:\n\t" "MOV #0,%1\n\t" // R1 = 0 (OK) "LDataBad:\n\t" // R1 always non-zero :"=r"(R1),"=r"(R1),"=r"(R2),"=r"(R3) :"i"(&_gp) // %4 ,"i"(&_sbss) // %5 ,"i"(&_sbss_next) // %6 ,"i"(&_sdata) // %7 ,"i"(&_sdata_next) // %8 ,"i"(&_idata) // %9 :"memory" ); return(0); } Corresponding e2-studio disassembly (in-line): - - - - - - - - - - - - - - - - - - - - - - - fffa2f0a: mov.l #0x1800, r1 fffa2f10: tst #3, r1 fffa2f14: bne.b 0xfffa2f5a fffa2f16: mov.l #0, r2 fffa2f18: mov.l #0x5da0, r3 fffa2f1e: tst #3, r3 fffa2f22: bne.b 0xfffa2f5a fffa2f24: sub r1, r3 fffa2f26: shlr #2, r3 fffa2f28: sstr.l fffa2f2a: mov.l #0x5da0, r1 fffa2f30: mov.l #0xfffac530, r2 fffa2f36: mov.l #0x7e04, r3 fffa2f3c: sub r1, r3 fffa2f3e: smovf fffa2f40: mov.l #0x1800, r13 fffa2f46: mov.l #0x1800, r12 fffa2f4c: cmp r13, r12 fffa2f4e: bne.b 0xfffa2f5a fffa2f50: mov.l r13, r11 fffa2f52: mov.l r13, r10 fffa2f54: mov.l r13, r9 fffa2f56: mov.l r13, r8 LDataGood: fffa2f58: mov.l #0, r1 387 __asm__ __volatile__ LDataBad: Excerpts from the map file: - - - - - - - - - - - - - - ... .sbss 0x0000000000001800 0x45a0 load address 0x00000000fffb0000 0x0000000000001800 . = ALIGN (0x4) 0x0000000000001800 __gp = . 0x0000000000001800 __sbss = . *(.sbss.*) ... *(B) ... *(B_1) ... *(B_2) ... 0x0000000000005da0 . = ALIGN (0x4) 0x0000000000005da0 __sbss_next = . .sdata 0x0000000000005da0 0x2064 load address 0x00000000fffac530 0x0000000000005da0 . = ALIGN (0x4) 0x0000000000005da0 __sdata = . *(.sdata.*) ... *(D) ... *(D_1) ... *(D_2) ... 0x0000000000007e04 . = ALIGN (0x4) 0x0000000000007e04 __sdata_next = . ... .idata 0x00000000fffac530 0x2064 0x00000000fffac530 . = ALIGN (0x4) 0x00000000fffac530 __idata = . 0x00000000fffae594 . = (. + SIZEOF (.sdata)) *fill* 0x00000000fffac530 0x2064 ... I hope you find something useful there... In the mean time I just adjust the .sdata section to get by. BTW, I don't know how you attach files in here... Cheers /Henrik
+1
7月 3, 2024 Commented Hello again : ) This is odd, yesterday I created that sample project twice to ensure it really happened, and it did. Today it will not happen. Unfortunately, I deleted all the files in between as I easily replicated the problem (back then). As I recall, the problem was when the "jsr _HardwareSetup" vas taken, it jumped somewhere in the Exception table (just somewhere ahead) with the fatal rte. The real project amounts to nearly 2000 source files and still have this problem. What I can see, the initialized data transfers from flash works incorrectly. the size of .sdata is 8 bytes larger than the .idata and therefore it mis-alignes somewhere the near end. This happens only when .sdata ends on an even boundary, like 0x6000 so my work around is to put another int (dummy) in the .sdata section when it happens. Now, I suspects our linker script may be the culprit? Maybe someone with better knowledge can tell: 8X - - - - SECTIONS /* * * Random Access Memory * * */ { /* * * unique input sections first * * */ .kernel (NOLOAD) : {*(.coredata)} > RAM .system (NOLOAD) : {*(.system)} > RAM .scode : AT(__icode) {. = ALIGN(4); __scode = .; *(.scode) . = ALIGN(4); __scode_next = .;} > RAM .ustack (NOLOAD) : {. = ALIGN(SYS_RANGE); *(.ustack)} > RAM .istack (NOLOAD) : {. = ALIGN(4); *(.istack)} > RAM /* * * zero-initiated data sections then * * */ .sbss : {. = ALIGN(4); __gp = .; __sbss = .; *(.sbss.*) *(B) *(B_1) *(B_2) . = ALIGN(4); __sbss_next = .;} > RAM /* * * initiated data sections then * * */ .sdata : AT(__idata) {. = ALIGN(4); __sdata = .; *(.sdata.*) *(D) *(D_1) *(D_2) . = ALIGN(4); __sdata_next = .;} > RAM /* * * versatile input sections last * * */ .bss : {. = ALIGN(4); *(.bss) *(.bss.*) *(COMMON)} > RAM } SECTIONS /* * * Program Flash Memory * * */ { /* * * unique input sections first * * */ .cfm : {*(.rodata.cfm)} > APPL .stall : {*(.text.halt)} > APPL .reset : {*(.text.reset)} > APPL /* * * versatile input sections then * * */ .text : {*(.text.*) *(C) *(C_1) *(C_2) *(P)} > APPL .rodata : {*(.rodata.*)} > APPL /* * * initiation data section last * * */ .idata : {. = ALIGN(4); __idata = .; . += SIZEOF(.sdata);} > APPL .icode : {. = ALIGN(4); __icode = .; . += SIZEOF(.scode);} > APPL } - - - - X8 Note: the RAM/APPL is defined in a device specific ld-file. Hopefully this was not too much of a wall of text... Thank you for your time /Hen

投票数

0 投票獲得 0/100 0up 0down
0 票獲得 0/100 0up 0down

Top 回答

回答がまだありません

新しい質問

0 8月 26, 2024 1 回答
Linker trashes initialized data at start-up?
0 6月 11, 2024 1 回答
Interrupt routine trashes registers (GCC for Renesas RX)
Henrik Glader のほかの質問 閲覧→
サポート