Henrik Glader

Stats

0 answers, 0 selected
2 questions, 0 solved
Member for 2 years, 5 months, 6 days
2969 profile views
Last seen 1 hour ago

Reputation

Total 17

0,0,0,0,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

October 1, 2024 Commented Hello there : ) I think I've finally got it!? Don't really know why c-source changes may trigger this *AT* omission but a decent linker script fix works: Originally the small sections were like: .sbss : { __gp = .; } > RAM .sdata : AT() { } > RAM This went sour on larger .sdata content with the effect the AT command semed ignored and fixed by reordering: .sdata : AT() { __gp = .; } > RAM .sbss : { } > RAM Later on even this fix triggered this phenomena. By forcing the background loop test in main: from for(;;){ } to while(SYSTEM.MSTPCRA.BIT.MSTPA19){ } All were fine again. Then I tried to tell the linker that really is *buddies*: .sdata : AT() { __gp = .; } > RAM .sbss . : { } > RAM A small change that in some way makes sense that works, even with a for-ever loop = ) I can imagine there is either a lack of understanding, unclear documentation or a bug behind this. Maybe other find this informative... Cheers /Henrik

+1

September 28, 2024 Commented Hello again : ) *edit* sometimes early mornings get the best of you... "while(1)" is needed, and no, the problem is still there... *edit end* *edit 2* I changed the test towards something the compiler coud not *resolve* like "while(solmething volatile that never is 0)" and this time it works, with the backgroud checks active. *edit 2 end* This work-around did eventually break too... The AT feature in the link script is ignored, as before. All the backed-up data and code is put in RAM instead of FLASH. By luck I noticed it happened with a slight change in main background.loop. "for(;;)" I changed it to "while(0)", nothing else and it works again. Therefore this behavior may probably be a combination of the compiler and the linker. What do you think? /Henrik

+1

August 26, 2024 Commented Hello there : ) I did what the manual and you told me but the output remains the same. This was not entirely unexpected!? due to this works until the smal data exceeds some magic size (lot less than set by -msmall-data). Then why does it work (as far as I can see) when i swap the order of .sbss and .data (keeping the __gp first)? The AT command just semes to stop work when thiis happens... Okay, I've got one *work around* that still works so I'll stick to it. However, if you catch the real culprit I'm all ears. Keep cool = ) /Henrik

+1

July 29, 2024 Commented Maybe I found a work around? I changed the order of the linker script by putting the .sdata before .sbss (see post number 3). All related references are moved accordingly. Don't know why but it works. Maybe I'm walking on egg shells? /Henrik

+1

July 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

Votes

0 votes received 0/100 0up 0down

0 votes casted 0/100 0up 0down

New questions

0 October 1, 2024 1 answers

Linker trashes initialized data at start-up?

0 June 11, 2024 1 answers

Interrupt routine trashes registers (GCC for Renesas RX)

Stats

Reputation

Votes

Top Answers

New questions