Problem including ble_advdata.h compiling with gcc

RE: Problem including ble_advdata.h compiling with gcc

RK — Wed, 12 Aug 2015 07:26:08 GMT

The GNU C++ compiler just has a slightly different set of error checks than the C one does, it seems to be pickier about variable types in asm statements, why I don't really know, in general the C++ one does more type checking all over the place.

RE: Problem including ble_advdata.h compiling with gcc

Susheel Nuguru — Wed, 12 Aug 2015 07:22:41 GMT

I have created a ticket for the SDK team to investigate this, i am not sure why the cast is needed in C++ (that is because i know C++ very little), can you enlighten me RK.

RE: Problem including ble_advdata.h compiling with gcc

RK — Wed, 12 Aug 2015 05:05:31 GMT

I think you only get the error when compiling c++, which might explain why Aryan wasn't seeing it and why TheBarrelShifter was the first to see it. The cast should be there, I just modified my SDK.

RE: Problem including ble_advdata.h compiling with gcc

TheBarrelShifter — Fri, 07 Aug 2015 11:41:35 GMT

Thankyou for the clarification - This explains why I had problems with linking when defining SVCALL_AS_NORMAL_FUNCTION.

In fact, the name is misleading, it is not possible to call them as normal functions because the implementation only exists for the serialisation case.

In summary, the softdevice API functions can only be called as SVC calls, and there is no corresponding 'normal' function.

Thanks again.

RE: Problem including ble_advdata.h compiling with gcc

Susheel Nuguru — Fri, 07 Aug 2015 10:00:07 GMT

This define is used in serialization. Where the nRF_Serialization API has exact same function API like softdevice API. but instead of SVC calls they are normal functions.

In your case, All sd_xx translate to a call to SVC hence you do not see the implementation of sd_xxx calls anywhere. If you define when you define SVCALL_AS_NORMAL_FUNCTION , then the macro

#define SVCALL(number, return_type, signature) return_type signature. Taking sd_flash_write as example

SVCALL(SD_FLASH_WRITE, uint32_t, sd_flash_write(uint32_t * const p_dst, uint32_t const * const p_src, uint32_t size));

This translate to

SVCALL_AS_NORMAL_FUNCTION not defined

__asm( \
    "svc %0\n" \
    "bx r14" : : "I" (number) : "r0" \
); \

SVCALL_AS_NORMAL_FUNCTION defined

uint32_t sd_flash_write(uint32_t * const p_dst, uint32_t const * const)

For the former, the compiler is not looking for implementation of functions. For the later, it needs implementation of the function definition that the macro defined.

RE: Problem including ble_advdata.h compiling with gcc

TheBarrelShifter — Fri, 07 Aug 2015 09:03:38 GMT

OK, yes I understood that bit - I meant whether it would still work correctly, whether there are any caveats to defining them as a normal function.

Yesterday I managed to get everything to compile with SVCALL_AS_NORMAL_FUNCTION defined, but it would not link. Ultimately I had to fix the problem this post was originally about in nrf_svc.h (by adding the cast) to get a compiled and linked binary. So for me at least, SVCALL_AS_NORMAL_FUNCTION did not achieve what I expected.

RE: Problem including ble_advdata.h compiling with gcc

Susheel Nuguru — Fri, 07 Aug 2015 09:00:41 GMT

If you see in this file you can see that if you define SVCALL_AS_NORMAL_FUNCTION then SVCALL is defined as

#define SVCALL(number, return_type, signature) return_type signature

This means that the call will be converted to a normal function call and not a SVC call with different exception to the CPU and different priorities. This will that none of the sd_xxx function will work as this functions wont be able to penetrate into softdevice memory addresses.

RE: Problem including ble_advdata.h compiling with gcc

TheBarrelShifter — Fri, 07 Aug 2015 08:37:19 GMT

Yes, these are good questions, and ones I am unable to answer, but I agree it does seem unlikely I am the first. Also I'd be surprised if Linux gcc doesn't require the cast too.

Please could you direct me to information that can explain what the outcome of defining SVCALL_AS_NORMAL_FUNCTION would be?

RE: Problem including ble_advdata.h compiling with gcc

Susheel Nuguru — Fri, 07 Aug 2015 08:34:00 GMT

Then it is something that should be looked into, I will redirect this to right people. I am now wondering why others did not get this error? are you the first one compiling SDK with GCC on MacOS? that seems unlikely.

RE: Problem including ble_advdata.h compiling with gcc

TheBarrelShifter — Fri, 07 Aug 2015 08:31:58 GMT

P.S. - Nothing has changed with gcc on MacOS, I am unable to compile 7.2.0 without the cast using the older gcc 4.9 2014 q4 either.

RE: Problem including ble_advdata.h compiling with gcc

TheBarrelShifter — Fri, 07 Aug 2015 08:12:35 GMT

You're right, when I freshly unzip the 7.2.0 SDK it is not there - I must have modified 7.2.0 too and forgotten about it.

I'm willing to bet that the casting is required for Linux too.

RE: Problem including ble_advdata.h compiling with gcc

Susheel Nuguru — Fri, 07 Aug 2015 07:22:31 GMT

I cannot see the casting in 7.2.0 SDK. I wonder what has changed with GCC on Mac OS?

RE: Problem including ble_advdata.h compiling with gcc

TheBarrelShifter — Thu, 06 Aug 2015 16:39:32 GMT

Also seems like it would be better to have the cast, unless there was a reason for removing it?

RE: Problem including ble_advdata.h compiling with gcc

Susheel Nuguru — Thu, 06 Aug 2015 16:02:33 GMT

seems like :)

RE: Problem including ble_advdata.h compiling with gcc

TheBarrelShifter — Thu, 06 Aug 2015 16:01:07 GMT

Fixed,

It was missing a cast to uint16_t in the following line:

"bx r14" : : "I" ((uint16_t)number) : "r0" \

The cast was present in the 7.2.0 SDK, I replaced it, and it now compiles.

Perhaps Windows gcc 4.9 is a bit less picky

RE: Problem including ble_advdata.h compiling with gcc

TheBarrelShifter — Thu, 06 Aug 2015 12:51:58 GMT

No, I'm running on Mac OS. Does your Makefile have SVCALL_AS_NORMAL_FUNCTION defined? If so it would explain why. I am using this as a workaround, but am uncertain what the ramifications are - Are you able to enlighten me?

RE: Problem including ble_advdata.h compiling with gcc

Susheel Nuguru — Thu, 06 Aug 2015 12:29:42 GMT

you are running this on windows? Why does it not happen on my desk with exactly same gcc version Have you updated your current path in nRF51_SDK_9.0.0_2e23562\components\toolchain\gcc\Makefile.windows?

RE: Problem including ble_advdata.h compiling with gcc

TheBarrelShifter — Thu, 06 Aug 2015 12:20:58 GMT

gcc 4.9 2015 q2 - Don't think it gets much more recent than that

RE: Problem including ble_advdata.h compiling with gcc

Susheel Nuguru — Thu, 06 Aug 2015 12:19:37 GMT

which GCC version are you using? if it is old, try upgrading it

RE: Problem including ble_advdata.h compiling with gcc

TheBarrelShifter — Thu, 06 Aug 2015 12:02:38 GMT

Doesn't seem to be, replacing __asm with __ASM there are still problems:

Nordic/nRF51_SDK_9.0.0_2e23562/components/softdevice/s110/headers/ble.h:427:1: note: in expansion of macro 'SVCALL' SVCALL(SD_BLE_OPT_SET, uint32_t, sd_ble_opt_set(uint32_t opt_id, ble_opt_t const *p_opt)); ^ Nordic/nRF51_SDK_9.0.0_2e23562/components/softdevice/s110/headers/ble.h: In function 'sd_ble_opt_get': Nordic/nRF51_SDK_9.0.0_2e23562/components/softdevice/s110/headers/nrf_svc.h:56:18: error: expected ')' before ':' token "bx r14" : : "I" (number) : "r0" \

RE: Problem including ble_advdata.h compiling with gcc

Susheel Nuguru — Thu, 06 Aug 2015 09:30:12 GMT

probably related to this