Serialization between STM32 and ISP1705/nRF52

[sveenman]

I am trying to use serialization to connect an STM32F4 to an ISP1705. My goal is too connect to other BLE devices and read some measurements. I have tried a few of the examples (uart over ble etc) and got them working on the ISP itself. I have tried the BLE AT commands and got them working after some time as well. This doesn't have enough functionality for me to read measurements though. I have the connectivity firmware flashed on the nRF52, and can talk to it over UART from my STM. I have a basic code example working for this allowing me to send RAW uart messages and get a response. The binary message is the mesage from UART RAW protocol

uint8_t buff[] = {0x04, 0x00, 0x00, 0x78, 0x41, 0x03};
ble_send_raw(buff, 6);

which gives me the following response:

0x06
0x00
0x01
0x78
0x01
0x30
0x00
0x00

So the communication between the STM32 and nRF52 is working. 

The next step is to get the serialization library working on the host chip (STM32) so that i can use all API calls. This is where i am stuck, i have seen the Serialization page and Running a serialized application . I tried to look at the Heart rate application and base the files that i need on that. I copied the /components/serialization folder to my STM32 project, and the softdevice/s132/headers since it looked like it needed some of those files. But after this i dont know where to continue, how i need to compile all files correctly, where i need to start porting, what files to include to start using functions. I see the API functions in the middleware files. For example 'sd_ble_gap_appearance_set' in 'serialization/application/codecs/ble/middlewares/app_mw_ble_gap.c' yet i dont see where these functions are included from since the file doesnt have a corresponding header. When i try to call that function and go to its defenition it goes to the '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. 

I would love some direction in where to start actually porting the serialization library to a different processor and what needs to be done to compile and include everything correctly. Or maybe there an STM32 port that's already available?

Greetings

[Edvin]

Hello,

Have you seen this article?

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

 

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

[sveenman]

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. 

[Edvin]

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

[sveenman]

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. 

[sveenman]

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?

[Edvin]

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