Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

Porting serialized app to STM32L4

Hi,

I would like to run application on STM32L4 and use nRF52832 as connectivity chip.

I run some serialized example on another nRF eval board, tried own trivial app on that board (successfully) and next step is to port my app to STM32 chip.

I have ported app_timer2, ser_phy_hci_slip, ser_app_hal, fstorage (for fds). But I am unable to compile nrf_sdh.c, because there are too many HW dependences to nRF chip and without it will not link. I dug into code in the serialized app running on eval board and found that the function called here (nrf_sdh_enable_request ) call serialized function, so it appears it is necessary to enable the SD.

I feel I have wrong setup, but can't find how to get rid of the nRF dependences in serialized app. What am I doing wrong?

Using  SES, nRF5 SDK 16.0.0.

Parents
  • Hi Tomas, 

    In our serialization code we will send all softdevice's API as serialized command to the connectivity chip. 
    If you look inside nrf_sdh_enable_request () you can find that all Softdevice API will use the serialization interface instead of calling Softdevice API directly. 


    For example  sd_softdevice_enable() is serialized in ser_softdevice_handler.c 

    So you don't need the softdevice on the host chip. You only need the softdevice on the nRF52 connectivity chip. 

  • Of course, I know I don't need softdevice on the host chip. The problem is I can't make the right cut and decide which files are necessary even in STM32 environment, which ones are usable and which ones must be omitted.

    Please follow this thinking scheme and tell me where do I wrong.

     - I take a serialized example, ble_app_hrs using HCI transport, and want to port it to STM32

     - make my own implementations for app_timer, UART driver and NVM etc.

     - In this example,there is BLE stack initialization (ble_stack_init()) function, calling nrf_sdh_enable_request().

     - This function is in nrf_sdh.c, and calls sd_softdevice_enable().

     - sd_softdevice_enable() is implemented in ser_softdevice_handler.c, and establish communication with connectivity chip. I made a conclusion I need this call.

     - So far so good, BUT: nrf_sdh.c includes nrf_sdm.h, it includes nrf.h, it includes HW definition header.

    My question is: is nrf_sdh.c usable for ported project? Or have I to call the sd_xxxx functions directly?

    I tried to google some example of ported project, but the only one was for nRF51, using old SDK.

  • Hi Tomas, 

    At the end of the day, what comes out of the HCI interface is most important. 

    As I can see some of the features in the nrf_sdh.c will not be used by the host chip, for example SD_EVT_IRQHandler() will not be used on the host. The event polling is handled in ble_evt_handler() in ser_softdevice_handler.c 

    I haven't done the porting myself, but I would suggest, if possible you can try to not modify the nrf_sdh.c and add the dummy nrf configurations. If that cause more trouble than benefit, then you will need to study the nrf_sdh.c and only port the sd_xxx API calls to your code. 

Reply
  • Hi Tomas, 

    At the end of the day, what comes out of the HCI interface is most important. 

    As I can see some of the features in the nrf_sdh.c will not be used by the host chip, for example SD_EVT_IRQHandler() will not be used on the host. The event polling is handled in ble_evt_handler() in ser_softdevice_handler.c 

    I haven't done the porting myself, but I would suggest, if possible you can try to not modify the nrf_sdh.c and add the dummy nrf configurations. If that cause more trouble than benefit, then you will need to study the nrf_sdh.c and only port the sd_xxx API calls to your code. 

Children
No Data
Related