ARM Technical Support Knowledge Articles

Cortex-M4 Integration Kit test fails immediately with ** TEST FAILED ** (Time: 74920) or similar

Applies to: Cortex-M4


This Knowledge Article is relevant to chip designers who have licensed the ARM Cortex-M4 processor RTL for inclusion in their chip design. At the time of writing, the currently released version of Cortex-M4 is r0p1.

The RTL description of the processor is delivered to licensees together with an example MCU design, a testbench, and some test programs, known as the Integration Kit, or IK.

The processor design offers a number of optional features for the chip designer to select. Once the chip designer has selected the desired configuration, the IK tests should be run to verify that the configuration has been specified correctly.

One of the tests, called "config_check", is intended to perform a kind of two-factor authentication to ensure that the actual configuration specified matches correctly with a separately recorded indication of the expected configuration.

The expected configuration is specified through a number of "EXPECTED_" settings in the file ./integration_kit/validation/tests/IKConfig.h

The actual configuration is specified by a number of parameters associated with the instantiation of the Cortex-M4 processor. In the IK MCU example design as delivered, these are set by the default parameter values included in the top of the file ./integration_kit/logical/cm4ikmcu/verilog/cm4ik_sys.v, which are then passed down through the instantiation hierarchy into the processor instance itself.

In addition, if the processor is has been licensed together with the optional additional Floating Point Unit (FPU) hardware, and the FPU is included in the chip design, then the software compilation options need to be adjusted to indicate "COMPILE_FPU = 1" in the top of the "make" file ./integration_kit/validation/tests/Makefile

Therefore, to correctly include, and verify the presence of, the FPU, all three of these locations must be edited to indicate the presence of the FPU.


If the IKConfig.h file is edited to indicate "EXPECTED_FPU = 1", but cm4ik_sys.v is left with "FPU_PRESENT = 0", and the Makefile is left with "COMPILE_FPU = 0", then IK tests which do not use the FPU will pass. However, the "config_check" and the "fpu" tests will both fail with sensible error messages. For example:

    FPU PRESENT: 0x0        (Expected 0xf00000)     -       FAIL


    FPSCR contents: 0x0     (Expected 0x1c00000)    -       FAIL

respectively. (The "fpu" test successfully performs its various floating-point arithmetic tests, because the compilation of the program has been told to include software floating-point routines, however the test fails when it attempts to confirm the value in the FPSCR register in the FPU hardware, as this register is not present.)

If both the "EXPECTED_FPU" and "FPU_PRESENT" are set to 1, but the "COMPILE_FPU" is left at 0 in the Makefile, the "config_check" test passes, as the hardware configuration matches the expected configuration, but the "fpu" test will still fail in the same way as above, because although the FPSCR register is now present in hardware, the test program has not made use of it (the program is still using software routines to implement floating-point operations), so the FPSCR still does not contain the correct expected value.

However, if both the "EXPECTED_FPU" and "COMPILE_FPU" are set to 1, while the "FPU_PRESENT" remains at 0, this results in all of the IK tests failing abruptly at initialization.

The simulation is terminated by a check at the start of IKInit(); which checks for a mismatch between code being compiled for FPU but the processor configuration not containing an FPU. Unfortunately, the corresponding error message:

    MSG(("Exiting test: compiling with VFP instructions when no VFP present\n\n"));

is targeted to signal pins ./cm4ik_sys/EXTGPIOOUT[14:8], where the printed characters are presented as 7-bit ASCII codes on this signal interface. The testbench contains a function to print characters appearing at the corresponding top-level GPIO pins in this way, but at this point in execution of IKinit(), the GPIO output enable has not yet been asserted, and therefore the printed characters do not reach the top-level GPIO pins.

(Note that the term "VFP" in the message is equivalent in meaning to "FPU".)

So the result is that if the programs are compiled to expect the FPU to be present, but the IK example design RTL is compiled with the FPU excluded, then all of the tests (including "config_check") will terminate abruptly at an early stage (of which the exact time may vary between tests), with a message like:

    # ** TEST FAILED ** (Time:               75300)

The problem of the error message being suppressed can be fixed by editing the ./integration_kit/validation/tests/IKtests.c file and modifying the IKinit() code so that the second block of instructions, which enable the GPIO, are placed before the first block of instructions, which test for code being compiled for VFP (floating point) instructions when the processor does not include FPU hardware.

The IKinit() function then looks like this:

      // CM4IKMCU External GPIO - Used for Test Status, Comms with Debug Driver
      GPIO0->DATA[0].WORD = 0;
      GPIO0->IE.WORD = 0;

    #if __TARGET_FPU_VFP
      // enable FPU
      // Must check here, regardless of config since compiler
      // will choose to include vfp instructions.
      // If code terminates here, check --cpu does not have vfp
      // or that FPU is present and not disabled in design
      if((SCB->CPACR & SCB_CPACR_FPU) == 0)
        MSG(("Exiting test: compiling with VFP instructions when no VFP present\n\n"));

With this modification, the failing tests now result in the correct message, such as

  # Exiting test: compiling with VFP instructions when no VFP present
  # ** TEST FAILED ** (Time: 75340)

The problem of the tests failing is solved by either recompiling the hardware design with the FPU included, if the FPU was intended to be present, or by recompiling the software tests without the expected FPU and FPU compilation options, if no FPU was intended to be built into the chip.

Rate this article

Disagree? Move your mouse over the bar and click

Did you find this article helpful? Yes No

How can we improve this article?

Link to this article
Copyright © 2011 ARM Limited. All rights reserved. External (Open), Non-Confidential