I am using a Arduino Mega2560 and I have a lot (321 times according to "(F("-searchcount, but part of them are outcommented) of commands like serial.print(F("anything")) in my sketch. That seemed to be working perfectly. Until this morning, when I stumbled on an error i can not get my hands on.
The problem is that when adding another serial.print(F("anything")) to my sketch i get the following errormessage:
c:/program files/arduino/hardware/tools/avr/bin/../lib/gcc/avr/4.3.2/../../../../avr/lib/avr6/crtm2560.o: In function __vector_default': (.vectors+0x2c): relocation truncated to fit: R_AVR_13_PCREL against symbol __vector_11' defined in .text section in c:/program files/arduino/hardware/tools/avr/bin/../lib/gcc/avr/4.3.2/../../../../avr/lib/avr6/crtm2560.o
This can be solved by outcommenting another simular serial.print(F("anything")) (or by deleting the F( )-wrap) anywhere else in the program, so I think I hit some magic upperboundary for maximum allowed characters in Flashmemory, or the totalcount for times this command is used and this counter is overflowing. Or I am just talking bull, and there is another explanation.
If the program does compile, it gives the following data:
Sketch uses 48.174 bytes (18%) of program storage space. Maximum is 258.048 bytes.
Global variables use 4.583 bytes (55%) of dynamic memory, leaving 3.609 bytes for local variables. Maximum is 8.192 bytes.
So i am not running out of flashmemory.
I was using 1.5.5, and have already updated to 1.5.6-r2, but this doesn't make any difference.
Anyone who knows what is causing this? And probably a way to solve it?
econjack:
Try looking at calls to freeMemory() in loop() to see if you're hitting its max:
It's not an SRAM issue, and it's not related to running out of flash memory. It's a linker error- essentially, the linker is trying to use a relative jump/call to execute code, but the destination code is too far away to be reached by a relative jump/call. The issue has been discussed at various times. I don't remember the outcome but I'm sure that if you search for Arduino relocation truncated to fit you will find the discussions about it.
You can't necessarily draw that conclusion. The amount of SRAM used AT COMPILE TIME (that the message shows) and the amount of SRAM used AT RUN TIME are not the same. The run time use can be a lot higher.
Though, running out of memory is probably not an issue. We need to see your code, though, to be sure.
You can't necessarily draw that conclusion. The amount of SRAM used AT COMPILE TIME (that the message shows) and the amount of SRAM used AT RUN TIME are not the same. The run time use can be a lot higher.
I was talking about flashmemory, not SRAM
Though, running out of memory is probably not an issue. We need to see your code, though, to be sure.
It has nothing to do with the code, only with the size of code.
Searching for 'R_AVR_13_PCREL' learns me that it is probably due to the '--relax' option with forces the linker (compiler?) to use relative jumps (with are limited bij 4K) during compiling, and removing that option should solve the problem. Problem is that it should be done in the source file Compiler.java, and i have no experience with that.
I tried numerous work-arounds found on this forum, but none of those seems to work for me.
But I think I have to set up an development enviroment to be able to change that and compile it back together to executables. Am I right about that?
However, I did find a crazy workaround: If i get the errror, i just uncomment a dummy serial.print(F("anything")) i made in setup(). If error persist, i change length of that string and try again. And again. Then it works. Very strange is that if error is disappeared and i outcomment the dummystring again the error stays away while compiling.
Sorry to see arduino still has this issue, which could very like happen to me.. I have long projects. OP, I bet you can reduce your footprint by doing concise texts. Why should these messages be so long anyway? An alternative is to store them on an SD card. You probably have enough pins for that. Third option is to find duplicate messages and use pgm_read_byte. The flash helper never optimizes for duplicate messages.
Anyway good luck to your project. Anyone reaching such limit genuinely should be applauded for their work.
liudr:
Why should these messages be so long anyway?
They aren't long, max 30 bytes, mostly 10 to 12 bytes I quess. Just a lot of them for debuging purposes and for the program as well. Storage is not the problem as far as I can see, wrong options send to the compiler are.
The code is 213127 bytes at the moment, spread around 23418 words in 3426 lines. And there is no need to study it, because the problem is NOT in my code.
Using the --relax option seems like a last ditch effort to me.
Yeah. Me too. Unfortunatly, de linker does use the --relax option and I am not able to turn it off.
Anyway, I found a workaround as you have read a few post above, so I hope I can avoid the problem allong the way.
2 weeks+ have past, and the problem only occured occasionally in the 2 days after my previous post. Luckily, my workaround worked out every time.
And now it is totally gone. I have not encountered that compilerbug in the last 12/13 days. So anyone having the same problem, keep faith, it comes spontaneously en it will fade away likewise.
