assembler message

514 views
Skip to first unread message

Kostiantyn Shyrokov

unread,
Aug 27, 2022, 8:27:06 AM8/27/22
to ThrowTheSwitch Forums
Hello all
I have legacy project. When I try to include tested module header file, I'm facing strange error reports:

Compiling dfu_mode.c with coverage...
C:\Users\x\AppData\Local\Temp\ccWSMM9E.s: Assembler messages:
C:\Users\x\AppData\Local\Temp\ccWSMM9E.s:28: Error: number of operands mismatch for `ds'
C:\Users\x\AppData\Local\Temp\ccWSMM9E.s:57: Error: number of operands mismatch for `ds'
C:\Users\x\AppData\Local\Temp\ccWSMM9E.s:474: Error: no such instruction: `mrs %eax,primask'
C:\Users\x\AppData\Local\Temp\ccWSMM9E.s:504: Error: no such instruction: `cpsid i'
C:\Users\x\AppData\Local\Temp\ccWSMM9E.s:577: Error: no such instruction: `msr primask,%eax'
ERROR: Shell command failed.

but none of my include or source files have exactly this commands...
where are this instructions from?

David Arbinger

unread,
Sep 5, 2023, 7:56:21 AM9/5/23
to ThrowTheSwitch Forums
Hi,
i have kind of the same error as you!

I use the Cube IDE for my project and have ceedling in a docker container running in parallel.

I tried to build up my project just as it was done in the course from throwtheswitch.

This is the exact error code after i run ceedling test
_____________________________________________________________________________________________________________________________________________________________
Test 'test_main.c'
------------------
Compiling main.c...
In file included from Drivers/CMSIS/Device/ST/STM32L0xx/Include/stm32l052xx.h:111,
                 from Drivers/CMSIS/Device/ST/STM32L0xx/Include/stm32l0xx.h:139,
                 from Drivers/STM32L0xx_HAL_Driver/Inc/stm32l0xx_hal_def.h:29,
                 from Drivers/STM32L0xx_HAL_Driver/Inc/stm32l0xx_hal_rcc.h:27,
                 from Core/Inc/stm32l0xx_hal_conf.h:188,
                 from Drivers/STM32L0xx_HAL_Driver/Inc/stm32l0xx_hal.h:29,
                 from Core/Inc/main.h:30,
                 from Core/Src/main.c:20:
Drivers/CMSIS/Include/core_cm0plus.h: In function ‘__NVIC_SetVector’:
Drivers/CMSIS/Include/core_cm0plus.h:951:23: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
  951 |   uint32_t *vectors = (uint32_t *)SCB->VTOR;
      |                       ^
Drivers/CMSIS/Include/core_cm0plus.h: In function ‘__NVIC_GetVector’:
Drivers/CMSIS/Include/core_cm0plus.h:970:23: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
  970 |   uint32_t *vectors = (uint32_t *)SCB->VTOR;
      |                       ^
Drivers/CMSIS/Include/cmsis_gcc.h: Assembler messages:
Drivers/CMSIS/Include/cmsis_gcc.h:142: Error: no such instruction: `cpsid i'
ERROR: Shell command failed.
> Shell executed command:
'gcc -I"/var/lib/gems/2.7.0/gems/ceedling-0.31.0/vendor/unity/src" -I"/var/lib/gems/2.7.0/gems/ceedling-0.31.0/vendor/cmock/src" -I"build/test/mocks" -I"test" -I"test/support" -I"Core/Src" -I"Core/Startup" -I"Drivers/STM32L0xx_HAL_Driver/Src" -I"Core/Inc" -I"Drivers/STM32L0xx_HAL_Driver/Inc" -I"Drivers/STM32L0xx_HAL_Driver/Inc/Legacy" -I"Drivers/CMSIS/Include" -I"Drivers/CMSIS/Device/ST/STM32L0xx/Include" -DSTM32L052xx -DTEST -DGNU_COMPILER -g -c "Core/Src/main.c" -o "build/test/out/c/main.o" -MMD -MF "build/test/dependencies/main.d"'
> And exited with status: [1].

#<Thread:0x0000564cd07148f0 /var/lib/gems/2.7.0/gems/ceedling-0.31.0/lib/ceedling/par_map.rb:7 run> terminated with exception (report_on_exception is true):
Traceback (most recent call last):
        11: from /var/lib/gems/2.7.0/gems/ceedling-0.31.0/lib/ceedling/par_map.rb:10:in `block (2 levels) in par_map'
        10: from /var/lib/gems/2.7.0/gems/ceedling-0.31.0/lib/ceedling/task_invoker.rb:97:in `block in invoke_test_objects'
         9: from /var/lib/gems/2.7.0/gems/rake-12.3.3/lib/rake/task.rb:183:in `invoke'
         8: from /var/lib/gems/2.7.0/gems/rake-12.3.3/lib/rake/task.rb:194:in `invoke_with_call_chain'
         7: from /var/lib/gems/2.7.0/gems/rake-12.3.3/lib/rake/task.rb:194:in `synchronize'
         6: from /var/lib/gems/2.7.0/gems/rake-12.3.3/lib/rake/task.rb:214:in `block in invoke_with_call_chain'
         5: from /var/lib/gems/2.7.0/gems/rake-12.3.3/lib/rake/task.rb:273:in `execute'
         4: from /var/lib/gems/2.7.0/gems/rake-12.3.3/lib/rake/task.rb:273:in `each'
         3: from /var/lib/gems/2.7.0/gems/rake-12.3.3/lib/rake/task.rb:273:in `block in execute'
         2: from /var/lib/gems/2.7.0/gems/ceedling-0.31.0/lib/ceedling/rules_tests.rake:17:in `block in <top (required)>'
         1: from /var/lib/gems/2.7.0/gems/ceedling-0.31.0/lib/ceedling/generator.rb:99:in `generate_object_file'
/var/lib/gems/2.7.0/gems/ceedling-0.31.0/lib/ceedling/tool_executor.rb:88:in `exec': ShellExecutionException (ShellExecutionException)
rake aborted!
ShellExecutionException: ShellExecutionException
/var/lib/gems/2.7.0/gems/ceedling-0.31.0/lib/ceedling/tool_executor.rb:88:in `exec'
/var/lib/gems/2.7.0/gems/ceedling-0.31.0/lib/ceedling/generator.rb:99:in `generate_object_file'
/var/lib/gems/2.7.0/gems/ceedling-0.31.0/lib/ceedling/rules_tests.rake:17:in `block in <top (required)>'
/var/lib/gems/2.7.0/gems/ceedling-0.31.0/lib/ceedling/task_invoker.rb:97:in `block in invoke_test_objects'
/var/lib/gems/2.7.0/gems/ceedling-0.31.0/lib/ceedling/par_map.rb:10:in `block (2 levels) in par_map'
Tasks: TOP => build/test/out/c/main.o
(See full trace by running task with --trace)
ERROR: Ceedling Failed
_____________________________________________________________________________________________________________________________________________________________

I just modified the paths and defines in my project.yml file like so:

:paths:
  :test:
    - +:test/**
    - -:test/support
  :source:
    - Core/Src/**
    - Core/Startup/**
    - Drivers/STM32L0xx_HAL_Driver/Src**
  :include:
    - Core/Inc/**
    - Drivers/STM32L0xx_HAL_Driver/Inc**
    - Drivers/STM32L0xx_HAL_Driver/Inc/Legacy**
    - Drivers/CMSIS/Include**
    - Drivers/CMSIS/Device/ST/STM32L0xx/Include/**
  :support:
    - test/support
  :libraries: []

:defines:
  # in order to add common defines:
  #  1) remove the trailing [] from the :common: section
  #  2) add entries to the :common: section (e.g. :test: has TEST defined)
  :common: &common_defines #[]
    - STM32L052xx
  :test:
    - *common_defines
    - TEST
  :test_preprocess:
    - *common_defines
    - TEST


Do you already have a solution for this error?

I am really not sure how to solve this.

Thanks in advance for the help!

Ted Wood

unread,
Feb 22, 2024, 11:21:14 AM2/22/24
to ThrowTheSwitch Forums
I have this problem too. Did anyone find a solution?

Mark Vander Voord

unread,
Feb 22, 2024, 11:26:02 AM2/22/24
to throwth...@googlegroups.com
Can you tell us a bit more about what you're seeing? What version of the tools are you using? What compiler? linker? Do you have assembly enabled? Are you using assembly files anywhere purposefully? Perhaps you can post your project.yml file and the command you ran to see the problem? From the original blurb, it appears that user was using gcov. Is that true of you also?

Mark



--
You received this message because you are subscribed to the Google Groups "ThrowTheSwitch Forums" group.
To unsubscribe from this group and stop receiving emails from it, send an email to throwtheswitc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/throwtheswitch/3c2ab27c-669a-4e5a-8846-6370b2cdddffn%40googlegroups.com.

Ted Wood

unread,
Feb 23, 2024, 7:53:31 AM2/23/24
to throwth...@googlegroups.com

image.png

The error message looked like this.

I tracked it to this piece of code in a header cmsis_gcc.h

image.png
and fixed it like this:

__STATIC_FORCEINLINE void __DSB(void)

{

#ifndef CEEDLING

__ASM volatile ("dsb 0xF":::"memory");

#endif

}


I'm using the latest Ceedling, Cmock etc. Compiling for an STM32 using gcc under eclipse

I have CEEDLING defined in my project.yaml file



You received this message because you are subscribed to a topic in the Google Groups "ThrowTheSwitch Forums" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/throwtheswitch/9PLYnxVDRxs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to throwtheswitc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/throwtheswitch/CAAu8-XE9kCAQhbhu-VLAeOTTzF171TLqRO1Xt%2BMYVpVjndS4mQ%40mail.gmail.com.


--




Ted Wood
Principal Software Engineer
(+44) 7904 321155



Mark Vander Voord

unread,
Feb 23, 2024, 10:01:20 AM2/23/24
to throwth...@googlegroups.com
Ted:

Thanks for the update!  Were you building tests using your stm32 compiler also and then running them on a simulator? Or the releases were built using STM, and the tests were built using native gcc and run locally. I suspect the latter, based on the errors you were getting... so the host environment didn't understand your assembly?

Mark

David Arbinger

unread,
Mar 18, 2024, 9:13:15 AM3/18/24
to ThrowTheSwitch Forums
Hi,
I tried to escape this error by using a simple #ifndef TEST...
/**
  \brief   Disable IRQ Interrupts
  \details Disables IRQ interrupts by setting the I-bit in the CPSR.
           Can only be executed in Privileged modes.
 */
__STATIC_FORCEINLINE void __disable_irq(void)
{
  #ifndef TEST
  __ASM volatile ("cpsid i" : : : "memory");
  #endif
}

This works for me...

I now have a question regarding the :paths: in the project.yml

i configured now the cmsis_gcc.h file above with this #ifndef... but i still use the cubeIDE (!!pain!!!). I run into the problem, that the cube IDE always kicks my user code away and then i always run into the same error!

i tried to resolve this by just make a copy of the cmsis_gcc.h file and modify it to my needs (with the #ifndef TEST... etc) and then give it in the test/support folder.
Now i thought that when i link this file in :paths: -> :support: -test/support, ceedling would use this file here first instead of the other file...
thats at least what i understand from the documentation from ceedling -> https://github.com/ThrowTheSwitch/Ceedling/blob/master/docs/CeedlingPacket.md#search-path-order

Search Path Order

When Ceedling searches for files (e.g. looking for header files to mock) or when it provides search paths to any of the default gcc toolchain executables, it organizes / prioritizes its search paths. The order is always: test paths, support paths, source paths, and then include paths. This can be useful, for instance, in certain testing scenarios where we desire Ceedling or a compiler to find a stand-in header file in our support directory before the actual source header file of the same name.

Or did i miss sth here?
Reply all
Reply to author
Forward
0 new messages