DISTORTEC / distortos

object-oriented C++ RTOS for microcontrollers
https://distortos.org/
Mozilla Public License 2.0
434 stars 67 forks source link

link error for STM32F429 #20

Closed rahmanih closed 8 years ago

rahmanih commented 8 years ago

Hello,

I'm trying to build the distortos for the STM32F429I MCU: I'm doing the follwing steps:

but I'm getting the following error: [ 20%] LD output/test/distortosTest.elf output/STM32F429ZI.ld:49: undefined symbol '__rom_start' referenced in expression collect2: error: ld returned 1 exit status Makefile:247: recipe for target 'output/test/distortosTest.elf' failed make: *** [output/test/distortosTest.elf] Error 1

I'm on fedora 23 with arm-none-eabi-g++5.2.0

regards haithem.

FreddieChopin commented 8 years ago

Hello rahmanih!

Could you try with the bleeding-edge-toolchain mentioned on the project's website?

Configuration & building

To configure & build distortos you need: ...

  • arm-none-eabi bleeding-edge-toolchain; alternatively you can try any other arm-none-eabi toolchain, but C++ exception handling code will increase the size of binary and incorrect newlib’s _reent struct configuration will dramatically increase RAM requirements (bleeding-edge-toolchain has the exceptions properly disabled and uses small variant of _reent struct – see here) – such combinations are not tested extensively;

Using "standard" toolchain provided by ARM (or from anywhere else) is - as you see - not tested.

Could you also post full verbose compilation log with your current toolchain? Just do:

make distclean
make configure CONFIG_PATH=configurations/32F429IDISCOVERY/test/
make all VERBOSE=1

I'll try to fix the error you saw. In the near future you will be able to build distortos with any ARM toolchain - I'm going to solve the problem of C++ exceptions and _reent struct in a more generic way (;

FreddieChopin commented 8 years ago

The problem must be somehow related to the toolchain in fedora that you are using - most likely to the version of arm-none-eabi-ld. In here (on Arch Linux) I've tried with last two versions of the toolchain from https://launchpad.net/gcc-arm-embedded/+download (5.3.1 and 5.2.1) and for both of them the commands you posted work correctly - the linking is completed successfully.

Could you tell me what version of arm-none-eabi-ld do you have? In the toolchains that I tested now I have 2.26.0.20160310 and 2.25.90.20151217 (bleeding-edge-toolchain has 2.26.51.20160412).

EDIT: don't bother with the fix below, it's only partial - see next post

You could also try to modify the linker script generator (distortos/source/architecture/ARM/ARMv6-M-ARMv7-M/ARMv6-M-ARMv7-M.ld.sh) in your copy of distortos. It's a blind guess, but maybe it will help... Change line 88 from: PROVIDE(__${memoryName}_end = __${memoryName}_start + __${memoryName}_size);\n\n" to: PROVIDE(__${memoryName}_end = ORIGIN(${memoryName}) + LENGTH(${memoryName}));\n\n"

FreddieChopin commented 8 years ago

OK, I managed to reproduce the error with an even older version of the toolchain, where ld is 2.24.0.20141128. The change that I suggested above is only partial, so just ignore it. Please try with the attached linker script generator (replace your copy of distortos/source/architecture/ARM/ARMv6-M-ARMv7-M/ARMv6-M-ARMv7-M.ld.sh with extracted script). It fixed the issue for me, but I'd like to be sure it also fixes it for you before commiting it.

ARMv6-M-ARMv7-M.ld.sh.zip

rahmanih commented 8 years ago

arm-none-eabi-g++ -g -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -Wl,-Map=output/test/distortosTest.map,--cref,--gc-sections -Toutput/STM32F429ZI.ld output/test/SequenceAsserter.o output/test/PrioritizedTestCase.o output/test/priorityTestPhases.o output/test/wasteTime.o output/test/TestCaseCommon.o output/test/testCases.o output/test/OperationCountingType.o output/test/TestCase.o output/test/TestCaseGroup.o output/test/waitForNextTick.o output/test/main.o output/test/CallOnce/CallOnceOperationsTestCase.o output/test/CallOnce/CallOnceFunctionTypesTestCase.o output/test/CallOnce/callOnceTestCases.o output/test/ConditionVariable/ConditionVariablePriorityTestCase.o output/test/ConditionVariable/conditionVariableTestCases.o output/test/ConditionVariable/ConditionVariableOperationsTestCase.o output/test/Mutex/MutexPriorityProtocolTestCase.o output/test/Mutex/MutexPriorityInheritanceOperationsTestCase.o output/test/Mutex/mutexTestUnlockFromWrongThread.o output/test/Mutex/MutexErrorCheckingOperationsTestCase.o output/test/Mutex/mutexTestCases.o output/test/Mutex/mutexTestTryLockWhenLocked.o output/test/Mutex/MutexPriorityTestCase.o output/test/Mutex/MutexRecursiveOperationsTestCase.o output/test/Mutex/MutexPriorityProtectOperationsTestCase.o output/test/Mutex/MutexOperationsTestCase.o output/test/Queue/QueueWrappers.o output/test/Queue/FifoQueuePriorityTestCase.o output/test/Queue/queueTestCases.o output/test/Queue/QueueOperationsTestCase.o output/test/Queue/MessageQueuePriorityTestCase.o output/test/Semaphore/SemaphorePriorityTestCase.o output/test/Semaphore/semaphoreTestCases.o output/test/Semaphore/SemaphoreOperationsTestCase.o output/test/Signals/SignalsGenerationOperationsTestCase.o output/test/Signals/SignalCatchingOperationsTestCase.o output/test/Signals/signalsTestCases.o output/test/Signals/SignalsInterruptionTestCase.o output/test/Signals/SignalsWaitTestCase.o output/test/Signals/SignalsCatchingTestCase.o output/test/Signals/SignalsTestCaseCommon.o output/test/Signals/SignalsWaitOperationsTestCase.o output/test/Signals/abortSignalHandler.o output/test/Signals/signalsTestSelfOneSignalPending.o output/test/Signals/SignalsQueuedOperationsTestCase.o output/test/SoftwareTimer/SoftwareTimerOperationsTestCase.o output/test/SoftwareTimer/SoftwareTimerOrderingTestCase.o output/test/SoftwareTimer/softwareTimerTestCases.o output/test/SoftwareTimer/SoftwareTimerFunctionTypesTestCase.o output/test/Thread/ThreadPriorityTestCase.o output/test/Thread/ThreadFunctionTypesTestCase.o output/test/Thread/ThreadSleepForTestCase.o output/test/Thread/ThreadOperationsTestCase.o output/test/Thread/threadTestCases.o output/test/Thread/ThreadSchedulingPolicyTestCase.o output/test/Thread/ThreadSleepUntilTestCase.o output/test/Thread/ThreadPriorityChangeTestCase.o output/test/architecture/ARM/ARMv7-M/ARMv7-M-architectureTestCases.o output/test/architecture/ARM/ARMv7-M/ARMv7-M-checkFpuRegisters.o output/test/architecture/ARM/ARMv7-M/ARMv7-M-FpuThreadTestCase.o output/test/architecture/ARM/ARMv7-M/ARMv7-M-FpuSignalTestCase.o output/test/architecture/ARM/ARMv7-M/ARMv7-M-setFpuRegisters.o -Wl,--whole-archive -l:output/libdistortos.a -Wl,--no-whole-archive -o output/test/distortosTest.elf arm-none-eabi-objcopy -O ihex output/test/distortosTest.elf output/test/distortosTest.hex arm-none-eabi-objcopy -O binary output/test/distortosTest.elf output/test/distortosTest.bin arm-none-eabi-objdump -x --syms --demangle output/test/distortosTest.elf > output/test/distortosTest.dmp arm-none-eabi-objdump --demangle -S output/test/distortosTest.elf > output/test/distortosTest.lss arm-none-eabi-size -B output/test/distortosTest.elf text data bss dec hex filename 182252 2188 9804 194244 2f6c4 output/test/distortosTest.elf

works like a charm :+1: well done!

FreddieChopin commented 8 years ago

I assume you tested the modified linker script generator, right? If you'd use bleeding-edge-toolchain the test application would be much much smaller (; The size of .text section would be 2/3 of what you have (less than 110kB), you would also save about 3kB of RAM. Most importantly - with this "standard" toolchain each thread object is ~900 bytes bigger than with bleeding-edge-toolchain...

I've also tested distortos with "official" ARM toolchains. The test application works for one 4.9 toolchain that I tested, but fails for both 5.x toolchains. The failure is - as usually - related to very strict requirements of the tests. I'll try to fix the failing test cases quickly - necessary changes are very trivial - but for now please keep that issue in mind. The system is working fine, it's just the issue of the test application.

rahmanih commented 8 years ago

yes I used the new script you shared.

FreddieChopin commented 8 years ago

I've fixed the test application for "official" ARM toolchains - I think now it should most likely complete successfully on your toolchain as well.