Help Needed with ARM Cross-Compilation Issues for nRF5340 on a Non-ARM MacBook Pro

[runqi]

Hello Nordic Community,

I am currently working on developing and programming applications for the nRF5340 using C, and I've encountered some challenges with cross-compilation that I hope to get some assistance with.

My development setup includes a non-ARM MacBook Pro. As part of my code, I've included some ARM assembly snippets. To compile my code, I initiated the shell with

nrfutil toolchain-manager launch --shell

 

However, I am facing difficulties in performing ARM cross-compilation. My first question is: Does the nrfutil toolchain-manager environment include a specific cross-compilation toolchain for ARM? If so, are there any additional configurations or steps that I might be missing to enable successful compilation for the nRF5340?

Additionally, I observed an interesting scenario. In an attempt to troubleshoot, I removed the ARM assembly parts from my code. During compilation, I noticed that __arm__ is automatically defined, even though my MacBook Pro does not have an ARM processor. I am puzzled about why this would be the case and am unable to locate where this definition is being set. Could someone please explain why __arm__ is defined in a non-ARM environment and how I might address any related issues?

Any insights or guidance on these matters would be greatly appreciated. I am eager to resolve these issues and continue my work on the nRF5340 platform.

Thank you in advance for your support!

Best regards,

Runqi

[Einar Thorsrud]

Hi Runqi,

Our tools (includign the toolchain manager) are tested on both ARM and Intel MACs so that should not cause any problems. Can you elaborate more specifically on what you are doing and how it is not working?

[runqi]

Hi Einar,

Thank you for your response and for confirming that the toolchain manager should work on both ARM and Intel Macs. I appreciate your help. Following your advice, I've delved deeper into the issue and have some additional details and questions.

I am working on incorporating ARM assembly code within my C project for the nRF5340. The issue arises specifically when trying to use a macro that includes inline assembly. Here's a simplified version of the macro causing the problem:

#define CDK_ASM_ROUTINE_START(proc_type, proc_name, proc_args)   \
                             proc_type proc_name proc_args;   \
                             asm ( "\n\t" \
                             ".section .text\n\t" \
                             "" #proc_name ": \n\t" \
                             // More assembly code follows

When I use this macro as follows:

CDK_ASM_ROUTINE_START(void, myFunction, (int param))

I encounter the following compilation error:

error: expected declaration specifiers or '...' before string constant

This error seems to be related to the inline assembly syntax within the macro. I have checked and confirmed that the syntax follows GCC's inline assembly guidelines. Here are the steps I have taken to troubleshoot the issue:

1. Verified that the inline assembly syntax is correct according to GCC documentation.
2. Checked that the macro expands correctly in other contexts.
3. Attempted to isolate the assembly code in a separate function to see if the issue persists.

Despite these efforts, the error remains. Could there be specific configurations or considerations for using inline assembly within macros for cross-compilation with the nRF toolchain?

I am using [Arm GNU Toolchain 13.2.rel1 (Build arm-13.7)] on a [MacBook Pro Core Intel i5] running [14.2.1 (23C71)].

Any further insights or suggestions you could offer would be greatly appreciated.

Thank you very much for your time and assistance.

Best regards,

Runqi

[Einar Thorsrud]

Hi Runqi,

I see you are using a gcc version higher than what is supplied in our latest toolchain, and I would advice that you use the toolchain from the toolchain manager as that has been used for our release testing and should work.

Regarding assemply that is not much used in the SDK, but there are some examples. I would not expect that inlining via macros should matter, as the preprocessor runds first, but perhaps it would make sense to avoide that until you get the bascs working to reduce compatibility. You can see examples of use of assemply in the SDK by searching for "__asm__"