Serialization between STM32 and ISP1705/nRF52

RE: Serialization between STM32 and ISP1705/nRF52

Edvin — Wed, 23 Sep 2020 13:06:31 GMT

Yes. The serialized examples have SVCALL_AS_NORMAL_FUNCTION defined.

This means that when it says e.g.:

SVCALL(SD_BLE_GAP_ADV_SET_CONFIGURE, uint32_t, sd_ble_gap_adv_set_configure(uint8_t *p_adv_handle, ble_gap_adv_data_t const *p_adv_data, ble_gap_adv_params_t const *p_adv_params));

It means:

uint32_t sd_ble_gap_adv_set_configure(uint8_t *p_adv_handle, ble_gap_adv_data_t const *p_adv_data, ble_gap_adv_params_t *p_adv_params);

This is the declaration of this function.

Additionally, we have the define in app_mw_ble_gap.c:

#ifndef _sd_ble_gap_adv_set_configure
#define _sd_ble_gap_adv_set_configure sd_ble_gap_adv_set_configure
#endif
uint32_t _sd_ble_gap_adv_set_configure(uint8_t *p_adv_handle,
                                       ble_gap_adv_data_t const *p_adv_data,
                                       ble_gap_adv_params_t const *p_adv_params)
{
    ...

It is a bit confusing, but try to follow this:

if _sd_ble_gap_adv_set_configure is not defined (which it is not), then define it to mean sd_ble_gap_adv_set_configure. Done.

Then it says:

uint32_t _sd_ble_gap_adv_set_configure(...), but this is a macro that we just defined, so what it really says is:

uint32_t sd_ble_gap_adv_set_configure(...).

So this is the definition of the softdevice call sd_ble_gap_adv_set_configure() when SVCALL_AS_NORMAL_FUNCTION is defined.

If SVCALL_AS_NORMAL_FUNCTION is not defined, then you would have a double definition of the softdevice call, sd_ble_gap_adv_set_configure(), but the non-serialized examples doesn't contain the app_mw_ble_gap.c file, so that is why it works in the non-serialized examples.

Does that clarify things a bit?

If you have the defines correct, then you should be able to call sd_ble_gap_adv_set_configure() from main, and then set a breakpoint inside _sd_ble_gap_adv_set_configure(), and it should be hit (try to turn off optimization on the STM if you want to test this). Obviously, in order to compile, then ble_gap_adv_set_configure_rec_enc() needs to be defined, which leads to a tunnel of new requirements, but they should all lead out in not too many files, requiring you to implement the serialization layer that you are using, such as for example UART.

Best regards,

Edvin

RE: Serialization between STM32 and ISP1705/nRF52

sveenman — Wed, 23 Sep 2020 08:29:20 GMT

as an edit to my previous response, i started slowly pulling out parts of the serializing code to try to get something to work on the STM. during that i found that in the softdevice headers for "nrf_svc" there is a difference between serialized examples and non serialized ones.

#ifdef SVCALL_AS_NORMAL_FUNCTION
#define SVCALL(number, return_type, signature) return_type signature
#else

#ifndef SVCALL
#if defined (__CC_ARM)
#define SVCALL(number, return_type, signature) return_type __svc(number) signature
#elif defined (__GNUC__)
#ifdef __cplusplus
#define GCC_CAST_CPP (uint16_t)
#else
#define GCC_CAST_CPP
#endif
#define SVCALL(number, return_type, signature)          \
  _Pragma("GCC diagnostic push")                        \
  _Pragma("GCC diagnostic ignored \"-Wreturn-type\"")   \
  __attribute__((naked))                                \
  __attribute__((unused))                               \
  static return_type signature                          \
  {                                                     \
    __asm(                                              \
        "svc %0\n"                                      \
        "bx r14" : : "I" (GCC_CAST_CPP number) : "r0"   \
    );                                                  \
  }                                                     \
  _Pragma("GCC diagnostic pop")

#elif defined (__ICCARM__)
#define PRAGMA(x) _Pragma(#x)
#define SVCALL(number, return_type, signature)          \
PRAGMA(swi_number = (number))                           \
 __swi return_type signature;
#else
#define SVCALL(number, return_type, signature) return_type signature
#endif
#endif  // SVCALL

#endif  // SVCALL_AS_NORMAL_FUNCTION

in the serialized one the 'SVCALL_AS_NORMAL_FUNCTION' is defined. I beleive this is what causes _sd_ble_gap_adv_set_configure in app_mw_ble_gap.c to be used instead of a direct softdevice call? this is the kind of stuff i would like help with. By just copying the code and trying to compile it i will never figure out what all these devines mean and what needs to be defined.

Is there some sort of guide in getting the serialization code to compile or work on something else then a nRF52?

RE: Serialization between STM32 and ISP1705/nRF52

sveenman — Wed, 23 Sep 2020 07:28:03 GMT

After getting it to work the way i did before again it goes into the SVCALL line, and then into a SVC_Handler but that doesn't do anything. then moved on to the next line.

I understand how the serialization library works, i am just not getting it to compile and include correctly so that it uses UART to send it. We don't have two DK's for the serialized example, but i beleive that that example would work fine.

I would have liked to be able to include most needed files, compile them and try to port them to the STM32 so that it would work. It doesn't seem to be doable right now though. So i guess i will have to use the serializers and middleware code to try to rewrite most of it into my own library so that everything works correctly. I would have hoped to safe time in this part by including all files at once and only porting one part.

RE: Serialization between STM32 and ISP1705/nRF52

Edvin — Tue, 22 Sep 2020 14:47:38 GMT

The way that the serialization library works is that all the softdevice calls, that would normally be handled by the softdevice precompiled .hex file, and return a value, will now be translated into a UART command, and passed over UART to the nRF, which will execute that softdevice call, receive a return value, and then report that value back over serial (UART in this case).

I haven't looked into the implementation, like the part that you link to here. But perhaps it is waiting for the return value via serial. I think you should look into porting the serial part of the project, since this will indicate whether or not it is working.

Try to run the serialized application examples in the SDK, such as the SDK\examples\ble_peripheral\ble_app_hrs\pca10040\ser_s132_uart project, and look at how the softdevice calls are propagated. If you have two DKs, you can try to run them serialized using this guide.

As you can see from these examples, unlike in the normal examples, you have some source code for the softdevice calls, e.g. _sd_ble_gap_adv_set_configure in app_mw_ble_gap.c, which calls ser_sd_transport_cmd_write().

Are these reached in your STM project?

BR,

Edvin

RE: Serialization between STM32 and ISP1705/nRF52

sveenman — Tue, 22 Sep 2020 13:54:16 GMT

I have seen the article you mentioned. When looking at the article it mentions some files that have to be ported, but not any starting point in porting the application.

The SVCALL led to (if i remember correctly) the define, and stopped in the asm lines if i remember correctly.

#define SVCALL(number, return_type, signature)          \
  _Pragma("GCC diagnostic push")                        \
  _Pragma("GCC diagnostic ignored \"-Wreturn-type\"")   \
  __attribute__((naked))                                \
  __attribute__((unused))                               \
  static return_type signature                          \
  {                                                     \
    __asm(                                              \
        "svc %0\n"                                      \
        "bx r14" : : "I" (GCC_CAST_CPP number) : "r0"   \
    );                                                  \
  }                                                     \
  _Pragma("GCC diagnostic pop")

I haven't actually started porting any of the UART drivers or files mentioned in the "Porting serialization libraries" because i am prity sure the way my files are compiling / included isn't correct. I havent actually had to change any of the uart code which is most likely because they arent being used. I cant check what i had before anymore since i removed that code and tried something else with little success.

Currently i am stuck at starting the port, i dont know which files i have to include, how i should go about compiling and including them correctly and then where to start porting the driver code. If i am honest i find this part lacking, or i havent found it yet in the documentation. The documentation mentions which files need to be ported and whast the functions in those files have to do, but not how to start with compiling and what the total serialization package is. My STM32 project is in Attolic TRUESTUDIO, so i cant copy any of the example projects to get the serialization compiling correctly. I have to set ble / serialization part of the project up again in a different environment, this part i can't find anywhere on the documentation and i would love some pointers for this.

RE: Serialization between STM32 and ISP1705/nRF52

Edvin — Tue, 22 Sep 2020 13:39:02 GMT

Hello,

Have you seen this article?

I don't think we have any finished serialization projects for STM32, as far as I know, unfortunately.

[quote user=""][/quote]

SVCALL(SD_BLE_GAP_APPEARANCE_SET, uint32_t, sd_ble_gap_appearance_set(uint16_t appearance))' line in ble_gap.h and doesn't reach the function implementation in the middleware.

What happens during this call? Do you see any data on the UART lines from the STM? (Try to analyze them with a logic analyzer)

Best regards,

Edvin