Henrik Glader’s reputation | Open Source Tools for Renesas

Henrik Glader’s reputation

Henrik Glader 17 Rep.

Follow

Henrik Glader's 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

+1

July 25, 2024 Commented Hello : ) All is good until .sdata extends some magic border. The initialization code is correct, however when it fails, .idata is put into RAM not in ROM if you look into the .mot file. Actually it rather looks like neither AT() behaves, putting the lot into RAM. This is after increasing the .sdata with one byte extra, no other changes. /Henrik

+1

July 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

+2

July 2, 2024 Asked Linker trashes initialized data at start-up?

+1

June 11, 2024 Commented Hello again : ) Yes, I get the same result. Now I realize I've not fully understand the purpose of the -mint-register. I read the manual as this option reserves registers from the compiler but free to use, where time is critical. As you could optimize speed using registers as buffer pointers, reducing register save/restore and initialize, but as the compiler trashes them, this use is void. With this said, the benefit for this option is not that great I once thought, I will keep these dirty __asm__. Thanks for the great work = ) /Henrik

+1

June 10, 2024 Commented I reckon the fix have been postponed and not included in the 8.3.0.202405 version. This one trashes r12/r13 instead but other than that, identical result. Good that documentation reflects the register limitation for this specific optimization. Cheers /Henrik

+1

April 29, 2024 Commented That was easy = ) I created a new project "GCC for Renesas RX C/C++ Executable Project" (RX231 custom target). Added "-mint-register=2 -msmall-data-limit=512" at Properties/C/C++ Build/Settings/Compiler/Command (rx-elf-gcc -mint-register=2 -msmall-data-limit=512) Added _gp to the linker script in .data section: .data : AT(_mdata) { __gp = .; _data = .; *(.data) *(.data.*) *(D) *(D_1) *(D_2) _edata = .; } > RAM Wrote a simple main and fast interrupt: // start code unsigned char Buffer[32]; unsigned char* pHead; unsigned char* pTail; volatile unsigned char Data; void ServiceFastRXI1(void) __attribute__ ((fast_interrupt,optimize("-O2"))); void ServiceFastRXI1(void) { *pHead++ = SCI1.RDR; *pTail++ = Data++; if(&Buffer[32] == pHead) { pTail = pHead = &Buffer[0]; } ICU.IER[15].BIT.IEN6 = 1; return; } void main(void) { int i; pTail = pHead = &Buffer[0]; i = (int)&ServiceFastRXI1; return; } // end code The compiled interrupt becomes: 19:../src/MTX.c **** void ServiceFastRXI1(void) __attribute__ ((fast_interrupt,optimize("-O2"))); 20:../src/MTX.c **** void ServiceFastRXI1(void) 21:../src/MTX.c **** { 9 .loc 1 21 1 view -0 10 ; Note: Fast Interrupt Handler 11 0000 6E 15 pushm r1-r5 12 .LCFI0: 22:../src/MTX.c **** *pHead++ = SCI1.RDR; 13 .loc 1 22 2 view .LVU1 14 .loc 1 22 8 is_stmt 0 view .LVU2 15 0002 FB 52 00 00 00 00 mov.L #_pHead, r5 16 0008 EC 53 mov.L [r5], r3 23:../src/MTX.c **** *pTail++ = Data++; 17 .loc 1 23 17 view .LVU3 18 000a FB 12 00 00 00 00 mov.L #_Data, r1 19 .loc 1 23 8 view .LVU4 20 0010 FB 42 00 00 00 00 mov.L #_pTail, r4 22:../src/MTX.c **** *pHead++ = SCI1.RDR; 21 .loc 1 22 8 view .LVU5 22 0016 71 32 01 add #1, r3, r2 23 0019 E3 52 mov.L r2, [r5] 22:../src/MTX.c **** *pHead++ = SCI1.RDR; 24 .loc 1 22 17 view .LVU6 25 001b FB 2E 20 A0 08 mov.L #0x8a020, r2 26 0020 89 2A mov.B 5[r2], r2 22:../src/MTX.c **** *pHead++ = SCI1.RDR; 27 .loc 1 22 11 view .LVU7 28 0022 C3 32 mov.B r2, [r3] 29 .loc 1 23 2 is_stmt 1 view .LVU8 30 .loc 1 23 17 is_stmt 0 view .LVU9 31 0024 CC 12 mov.B [r1], r2 32 .loc 1 23 8 view .LVU10 33 0026 EC 43 mov.L [r4], r3 34 .loc 1 23 17 view .LVU11 35 0028 71 2C 01 add #1, r2, r12 36 .loc 1 23 8 view .LVU12 37 002b 71 3B 01 add #1, r3, r11 38 .loc 1 23 17 view .LVU13 39 002e C3 1C mov.B r12, [r1] 40 .loc 1 23 8 view .LVU14 41 0030 E3 4B mov.L r11, [r4] 42 .loc 1 23 11 view .LVU15 43 0032 C3 32 mov.B r2, [r3] 24:../src/MTX.c **** if(&Buffer[32] == pHead) 44 .loc 1 24 2 is_stmt 1 view .LVU16 45 .loc 1 24 4 is_stmt 0 view .LVU17 46 0034 EC 53 mov.L [r5], r3 47 0036 74 03 00 00 00 00 cmp #_Buffer+32, r3 48 003c 20 15 beq .L5 25:../src/MTX.c **** { 26:../src/MTX.c **** pTail = pHead = &Buffer[0]; 27:../src/MTX.c **** } 28:../src/MTX.c **** ICU.IER[15].BIT.IEN6 = 1; 49 .loc 1 28 2 is_stmt 1 view .LVU18 50 .loc 1 28 23 is_stmt 0 view .LVU19 51 003e FB 5E 00 70 08 mov.L #0x87000, r5 52 0043 CE 54 0F 02 mov.B 527[r5], r4 53 0047 78 64 bset #6, r4 54 0049 CB 54 0F 02 mov.B r4, 527[r5] 29:../src/MTX.c **** return; 55 .loc 1 29 2 is_stmt 1 view .LVU20 30:../src/MTX.c **** } 56 .loc 1 30 1 is_stmt 0 view .LVU21 57 004d 6F 15 popm r1-r5 58 004f 7F 94 rtfi Note that this trashes both r11 and r12... /Henrik

+1

April 19, 2024 Commented Hi, thank you for your reply = ) Yes, indeed I've read the manual and set aside r13 and r12. Further more, I've recognized r10 will be used by the compiler regardless your demands on r13 thru r10 (it's used as a stack frame pointer?). The problem resides in the manual page 365: Quote - - - The actual register chosen to hold the constant data base address depends upon whether the ‘-msmall-data-limit’ and/or the ‘-mint-register’ commandline options are enabled. Starting with register r13 and proceeding downwards, registers are allocated first to satisfy the requirements of ‘-mint-register’, then ‘-mpid’ and finally ‘-msmall-data-limit’. Thus it is possible for the small data area register to be r8 if both ‘-mint-register=4’ and ‘-mpid’ are specified on the command line. By default this feature is not enabled. The default can be restored via the ‘-mno-pid’ command-line option. - - - End quote By this statement I shuld get (-mno-pid): r13 as global reserved register not used by gcc. r12 as above r11 as small data pointer (_gp) featured by gcc. Would you not agree?

+1

April 18, 2024 Commented Side noted: The core in use RX23E/RX231. Optimization level -O2 Toolchain 8.3.0.202104 but no change with newer ones.

+2

April 17, 2024 Asked Interrupt routine trashes registers (GCC for Renesas RX)

+1

January 10, 2023 registration

Support