How do I get the SFunction builder to create an SFunction that uses a signed 64 bit integer as input/output?

Hi,

I'm using R2015b with embedded coder, simulink and stateflow. I'm using Simulink/Stateflow to generate firmware for a device that uses a Cortex-M3 core and I'm having trouble getting the S-Function builder to create an S-Function that accepts 64 bit values as inputs or outputs. I have several variables that need to be able to handle either signed or unsigned 64 bit values.

For one of these S-Function blocks (which I'll use as an example of the problem even though this is not the only block that exhibits this problem), I've used the S-Function builder to generate blocks that contain wrapper functions that will use the data. I used the Fixed-point: Binary Point Scaling option with the word length set to 64, the fraction length set to 0, and the signed box checked. When the builder generates the wrapper function and I look at the generated source code, the variable has a type of int64_T, which is exactly as I expected it to be. The problem arises when I try to use the block in a model. When I attach the block to a test Stateflow chart output that was configured using the Model Explorer as the exact same data type I described before (signed fixed point binary with a word length of 64 and a fraction length of 0) I get the following error:

Data type mismatch. Output port 1 of 'GenFuncTestIntLibs/Number_to_String/Number' is a signal of data type 'sfix64'.
However, it is driving a signal of data type 'sfix64_OBSOLETE'.

This means that the S-Function created by the builder for some reason was generated using some obsolete data type. I can't find a reference to this in the generated .tlc or .c files, and once again the generated *_wrapper.c file uses the int64_T data type, exactly as expected. How do I get the block to use a data type that's obviously recognized by MATLAB since it's possible to use the Model Explorer to define a variable of that type? I really need to be able to manipulate this data if I'm going to be able to use Simulink to generate the source code for the firmware, which is the only reason my company has paid the exorbitant licensing fee associated with this software.

I have attached images of the data type settings in the S-Function builder and the model explorer to verify that I'm setting things up correctly. Any help with this is greatly appreciated. Thanks in advance.

Settings for the data type in the S-Function Builder (Generates obsolete data type):

Settings for the data type in the Model Explorer (Generates usable data type):

Answer 1

[Mark McBroom]

Hi Chris, It appears that there is an error in s-function builder in 15b. I was able to reproduce your problem in 15b but then get the same model to work properly in 16a. Do you have access to 16a?

Answer 2

[Chris Hack]

Mark,

I do not currently have access to 16a, sorry... I may be able to upgrade in the near future but for now I'm stuck with the 15 release.

-Chris

Answer 3

[Chris Hack]

Mark,

I do have 2014b installed... was this a bug that was present until 2016a, or did it just manifest itself in 2015b?

-Chris

Answer 4

[Mark McBroom]

If you can't migrate to 16a, then here is how you can work around it. It will require you to manually change your .c file and .tlc files after running "build" from the s-function builder GUI. I am attaching the .c and .tlc file generated in 16a. You will see 1 line of code difference in the files. You will need to make the same changes in your .c and .tlc files for each s-function and then rebuild the .mexw64 files by typing this command for each s-function:

mex sfun_num2string8.c sfun_num2string8_wrapper.c -lfixedpoint

Answer 5

[Chris Hack]

Mark and anyone else out there who's used version 2016a Simulink models to generate code,

I upgraded to 2016a just to try to simplify the process of creating new S-Functions with the builder, and now I'm running into a different set of problems. When I generate code with 2015b, the ert_main.c file that's generated (I'm using the ARM Cortex-M3 as my deployment hardware) looks like this:

int main(void)
{
     volatile boolean_T runModel = 1;
     float modelBaseRate = 0.0005;
     float systemClock = 14;
     SystemCoreClockUpdate();
     UNUSED(modelBaseRate);
     UNUSED(systemClock);
     rtmSetErrorStatus(GenFuncTestIntLibs_M, 0);
     GenFuncTestIntLibs_initialize();
     runModel =
          rtmGetErrorStatus(GenFuncTestIntLibs_M) == (NULL);
     while (runModel) {
          rt_OneStep();
          runModel =
               rtmGetErrorStatus(GenFuncTestIntLibs_M) == (NULL);
     }

       /* Disable rt_OneStep() here */
       return 0;
  }

However, when I use 2016a to generate code from the EXACT SAME MODEL, there's a new reference to a non-existent function called ARMCM_SysTick_Config() and rt_OneStep() is no longer included in the while loop that actually runs the model, which means that nothing will ever be run. Here's the main function as generated by 2016a:

int main(void)
{
     volatile boolean_T runModel = 1;
     float modelBaseRate = 0.0005;
     float systemClock = 14;
     SystemCoreClockUpdate();
     rtmSetErrorStatus(GenFuncTestIntLibs2016a_M, 0);
     GenFuncTestIntLibs2016a_initialize();
     ARMCM_SysTick_Config(modelBaseRate);
     runModel =
          rtmGetErrorStatus(GenFuncTestIntLibs2016a_M) == (NULL);
     __enable_irq();
     __enable_irq();
     while (runModel) {
          runModel =
               rtmGetErrorStatus(GenFuncTestIntLibs2016a_M) == (NULL);
     }

       /* Disable rt_OneStep() here */
       __disable_irq();
       return 0;
  }

The new function (ARMCM_SysTick_Config()) seems to be attempting to call the SysTick_Config() function that's defined in the CMSIS library, but with the wrong name... I can't seem to find a reference to the newly named function anywhere in any known CMSIS library and 2016a seems to have installed its own version of CMSIS, whereas the previous versions had you download and install the library on your own and simply pointed MATLAB to where you could find it. Would removing references to the support package's version of the library and redirecting it to the older version of CMSIS work better for this? Honestly, I'm confused about how an upgrade like this could completely dismantle a running model...

As always, thanks in advance for any and all help you can provide.

-Chris