arm-none-eabi toolchain output and test executable

[Jaeka2]

Hi, I am currently working on integrating unit tests using Ceedling for a NRF52832 system. It uses the arm-none-eabi toolchain which seems to be creating an issue when executing test outputs. After linking the output file, it "runs", displaying the .out file in the text editor, containing completely illegible contents. When the file is closed, the following is displayed in the shell:

ERROR: Test executable "test_util.out" failed.
> Produced no output to $stdout.
> And exited with status: [0] (count of failed tests).
> This is often a symptom of a bad memory access in source or test code.
rake aborted!

Interestingly, i altered the :tools: section of the YAML for the temp_sensor example to match, and encountered the same issue.

My :tools: section of the YAML is:

:tools:
  :test_compiler:
     :executable: arm-none-eabi-gcc              #exists in system search path
     :arguments:
        - -c ${1}
        - -I"$": COLLECTION_PATHS_TEST_TOOLCHAIN_INCLUDE               #expands to -I search paths
        - -I"$": COLLECTION_PATHS_TEST_SUPPORT_SOURCE_INCLUDE_VENDOR   #expands to -I search paths
        - -D$: COLLECTION_DEFINES_TEST_AND_VENDOR  #expands to all -D defined symbols

        - -c ${1}                       #source code input file (Ruby method call param list sub)
        - -o ${2}                       #object file output (Ruby method call param list sub)
        - -I"$": COLLECTION_PATHS_TEST_TOOLCHAIN_INCLUDE               #expands to -I search paths
        - -I"$": COLLECTION_PATHS_TEST_SUPPORT_SOURCE_INCLUDE_VENDOR   #expands to -I search paths
        - -D$: COLLECTION_DEFINES_TEST_AND_VENDOR  #expands to all -D defined symbols
  :test_linker:
     :executable: arm-none-eabi-gcc
     :arguments:
        - --entry=0x23000
        - ${1}               #list of object files to link (Ruby method call param list sub)
        - --specs=nosys.specs
        - -o ${2}            #executable file output (Ruby method call param list sub)

I was hoping I could receive some advice on making my output human readable, preferably in the shell. Thanks, Jake

[Letme]

Are you running your unit tests on an arm? Because this indicates more that you are not running a thing which is strange because .out file would be run in linux (unless you changed something as what it does by default) and it should fail because of the bad instruction for example (if you are not running them on proper ARM).

[Jaeka2]

Its probably worth mentioning that I am using Windows. That said however, Ceedlings example projects with the default gcc toolchain use .out executables which are then run through the windows shell without an issue - and to my knowledge i haven't touched anything that would alter this. Could it possibly be related to using the default (undefined) :test_fixture:?

I've been able to run the test using Unity rather than Ceedling by generating the runner, then semi-hosting on my board alongside the whole project.

[Letme]

Then for sure test_compiler: arm-none-eabi-gcc (and linker) is going to be wrong. That is an ARM compiler, most likely produces ELF as output which you then flash on the device.

So depends what you want to do. Do you want to run unit tests on device? Most of the time we run unit tests on PC or via simulator, not on the device itself. And for running on PC you use your native compiler, for via simulator you need to define additional tool (I think test_fixture indeed) which then instructs simulator to run the compiled binary (most likely takes elf or even hex) and report the result.

[Jaeka2]

Thanks for helping to clarify that for me! Unfortunately, this ultimately means that the subsequent issue I encountered is the real problem (I just wanted to check this was right before posting it). I have attempted to simulate the device, using :test_fixture: and setting my output extension to :executable: .hex. I have been using the free version of Jumper, however I have encountered the following issue:

ERROR: Test executable "test_util.hex" failed.
> Produced no final test result counts in $stdout:
+------------------------------------------------+
|  Update available from 0.3.66 to 0.3.79        |
|    Run pip install jumper --upgrade to update  |
+------------------------------------------------+
Loading virtual device
jumper run: error: jemu exited with a non-zero exit code: -1073741819
> And exited with status: [0] (count of failed tests).
> This is often a symptom of a bad memory access in source or test code.

rake aborted!

Other output types including .elf return errors due to incomplete binaries. I contacted jumper who no longer update their free version for Windows and are prioritizing support for paying customers. I'll probably make a separate issue for messing with Jumper, alternatively - Are there any documented, more affordable test fixtures/simulators you would recommend for use with the arm toolchain? Thanks!

[mvandervoord]

It can be some work to get it up and running, but qemu (https://www.qemu.org/) is a good free option for most ARM targets.

[Jaeka2]

Ah nice one! I'll check it out later today. Thank you both for your help :)

[Jaeka2]

Oof, doesn't look like they have any support for cortex-m4 systems that I could use as an emulation platform. I'll keep looking for somewhere capable of running arm-cortex-m4.

[Letme]

I seen in official kernel repo, that you can run Linux on cortex-m4... That would enable to actually natively run stuff :wink:

Easiest way is to run on PC and just mock (make IOs as RAM) the specifics. Its good enough for 95% of cases

[austinbes]

There's no way you could get Linux to run on an nRF52. I've never seen Linux boot with less than ~2 MB of RAM, and the nRF52 has only 64 kB (which should be enough for anyone, I guess...). It also has no external memory interface.

I would highly recommend compiling and running your unit tests natively (using vanilla gcc).

[Letme]

I am not saying nRF52, I am saying cortex-m4 board https://elinux.org/STM32

[Letme]

Can we close this?