Simulink Debugging for MATLAB function block not working in R2020a

I have a huge Simulink model with a lot of masked MATLAB function blocks. These function blocks call external MATLAB functions that are saved in their own m-files. In R2016b I was able to put breakpoints into those external m-files and have Simulink stop at those for debugging purposes. In R2020a this does not work anymore. I can only get Simulink to peek into the code by pushing the "look under mask" button and putting a breakpoint into the now opened file. This also allows me to step into the external m-files. However, although I can see the breakpoints in that external file, the simulation will not stop at those when clicking "continue" but will stop at the breakpoint in the file of the MATLAB function block again, thus rendering the breakpoints in the external files useless.

Does anyone know of a change between R2016b and R2020a that might cause this?

[Jyotsna Talluri]

Could you attach a reference model?

[Friedrich Tuttas]

Unfortunately, I cannot because I do not know if I am allowed to publish the model. It is a model by the European Space Agency, which, in theory, should be free to be downloaded from their repository after contacting them:

https://essr.esa.int/project/gafe-generic-aocs-gnc-techniques-design-framework-for-fdir

It is, however, very bothersome to set up and get it running in the first place.

I had hoped that someone might know of a change between the versions R2016b and R2020a that might cause this behavior without the need to look at the code.

Answer 1

[Friedrich Tuttas]

In case anyone stumbles on this thread: I still have not been able to fully resolve this issue. Simply by updating to R2021b the execution will now stop at some breakpoints but will not at others. I have not found a pattern there. Also, the debugging is much slower than in R2016b. If the execution does stop at a breakpoint the execution of a single line (by clicking "Step") takes several seconds where R2016b would take a fraction of a second for the same line. Also, for some breakpoints the execution does stop but the Editor does not show the arrow next to the corresponding line. So, I do not know whether it actually stopped at the right line.

So, if anything the new MATLAB version made this issue even more mysterious.

[Co Melissant]

any updates?

we face similar issues running 20b. breakpoints ignored - or in other cases, required to have the correct functional behaviour during simulation!

[Friedrich Tuttas]

Unfortunately, I do not have any updates regarding this issue.

Answer 2

[Jyotsna Talluri]

I could not reproduce the issue as I don't have the model you are using .But in cases like in accelerator mode of simulation and in codegen mode the breakpoints are ignored .This is a known limitation .

There is a workaround that I could suggest.If you are able to pause the simulation at the call of a local function in a MATLAB Function block,you can use Step In and Step to further debug in the local function

https://www.mathworks.com/help/stateflow/ug/debugging-a-matlab-function-in-a-chart.html#f6-98444

Answer 3

[Landon Wagner]

Hi Friedrich, are you still having this issue? What is your system target file setting? (Under Model Settings -> Code Generation -> System target file") It's been long enough I assume you've resolved this but just in case, try setting it to "ert.tlc" if it isn't already. You handle matlab function block contents like I do with a function block referencing a .m file and I lost my .m file debug ability in 2020b too. It turns out my system target file switched back to grt.tlc at some point.

Compiling using grt.tlc is going to generate some .slxc files where ert.tlc will not. That makes sense given the contrast between them but it's subtle, especially since the output (for me) was directed to a folder far outside my working directory. I didn't dive too deep into the details once I got my referenced .m breakpoints back, but I believe I convinced myself that my .m files outside the model were being folded into the .slxc executable and thus had their debugability squashed. Maybe that's nonsense, but the switch brought back the capability.

[Friedrich Tuttas]

Hi,

thanks for your reply. I have not been able to solve this problem but swtiched back to R2016b for the last months instead because debugging worked in this version.

Now I have to switch to R2020a and have to deal with this problem again. I tried to follow your fix but I could not find the entry "Code Generation" in the Model Settings because I did not have Simulink Coder installed. So I installed it and now the entry "Code Generation" does appear. So I changed the "System Target File" from "grt.tlc" to "ert.tlc" but it did not seem to have any effect.

As for Jyotsna Talluri's answer: I am not using accelerator mode but normal mode (see "Normal" under "Stop Time") and I do not know what codegen mode is. You are right, I could use Step In and Step for Debugging once Simulink stopped at the external m-files but this is very bothersome since I would have to step through hundreds of lines of code to get to desired line in the internal m-files.

Does anyone have another idea?

Answer 4

[Michael Jeschke]

Hi Friedrich, hi Jyotsna,

I can perfectly confirm Friedrich's problem. I am facing exactly the same bug, and Friedrich's description matches my scenario pretty well. I have narrowed down the issue for you, Jyotsna & colleagues, and hope you'll be able to fix it in a near future Release. Here are the details of my setup:

- R2019b with Simulink and Stateflow

- A state chart with lots of Matlab code at different places:

• (a) MATLAB Function blocks that are called from within a state,
• (b) MATLAB Function blocks that are called from a transition condition, in [], not in {}. (note: I don't know how it behaves for actions in {}, I only have the conditions in [] at the transitions in my model),
• (c) External Matlab function in m-files on the "path" (=subdirectory of my Simulink model file) being called from the MATLAB Function block of kind (a),
• (d) External Matlab function in m-files on the "path" (=subdirectory of my Simulink model file) being called from the MATLAB Function block of kind (b),
• (e) External Matlab function in m-files on the "path" (=subdirectory of my Simulink model file) directly being called from a transition condition, in [].

While breakpoints are respected for (a), (b) and (c), the problem is for (d) and (e)! Hope this helps you to reproduce the bug!

So the problem is the combination of a [state transition conditon] from where an external m-file function is called - be it directly or by way of an intermediate MATLAB Function block.

And in case somebody is asking:

• 1.) Yes, the breakpoint is red, not grey, so it is active.
• 2.) Yes, I also tried carefully this: I closed Matlab, then even deleted all "slprj" directories and the generated *.slxc file, then I restarted Matlab and reopened the Simulink model, then opened the file in the MATLAB editor and I correctly set the breakpoint - all of this before finally pressing the "Run" button for compiling and running the simulation. --> Again the same problem.
• 3.) Yes, the code of this m-file (external m-function) is actually being executed and not left out. How can I know? Well, to test it I entered the following line of dummy code at the start of this file just next to the break point:

aa=[1 2 3 4 5]; bb=7; cc=find(aa==bb); dd=cc(1);

• --> While the compiler is accepting this, I get a runtime(!) error for

cc(1);

• when it tries to take the first element of the empty matrix cc. So I know for sure that the program code here is being executed! Just the breakpoint is being ignored.
• 4.) Yes, I tried several files for which (d) or (e) applies - all show the same problem.

Since also the "keyboard" command is not accepted by the compiler in my code of question, I think in the meantime the only workaround for debugging is to move this code, at least temporarily, from the external m-file to inside the MATLAB Function block, until the debugging is finished. This could be somewhat tedious of course.

PS: Just like Friedich, I do NOT use code generator and I do use normal mode, not accelerator mode.

[Michael Jeschke]

One more important observation, referring to problem case (d):

• I have the "MATLAB Function block" function that I call from a state [transition condition], let's call this function T.
• From T, I call another function that is 1:1 related to an external m-file on my path, let's call it A.
• From A, I call another function that is 1:1 related to an external m-file on my path, let's call it B.
• From B, I call another function that is 1:1 related to an external m-file on my path, let's call it C.

Now the funny thing is: Breakpoints in functions T work (as I already wrote, this is my case (b) from previous posting), and breakpoints in function C (=the "last function in this cascade") works as well!!!

However, the functions in the middle of this cascade, so here functions A and B, ignore all breakpoints!

Also the "Step" or "Step In" button do not help. When I stop at the breakpoint in T just wherer I jump into A, then after pressing "Step In" my next stop is not in A, also not in B, but only in C.

Edit: To make things even more mysterious: I have another MATLAB Function block T2 in the same model (also called from transition condition), for which the same explanation as above applies: T2 calls A1, and directly in the next code line T2 calls A2. Both A1 and A2 are already the last functions in the cascade, i.e. neither A1 nor A2 make any further function calls. So based on what I just wrote above, I had expected that breakpoints in A1 and A2 are possible. But they aren't! So whatever is the reason why some external functions called (via cascade ) from Transition conditions are "breakpointable" and others aren't - the rule seems to be more complicated than what I had thought...

Summary: T, T2 are MATLAB Function blocks called from a state chart transition condition [...], the others are functions inside their individual m-files on the MATLAB path.

* T ----> A ----> B ----> C (C calls no other function)

* T2 ----> A1 (A1 calls no other function)

T2 ----> A2 (A2 calls no other function)

Debuggable: T, T2, C

Not debuggable: A, B, A1, A2.

[Friedrich Tuttas]

Hello Michael,

thanks for the reply. Did you find find a solution to your problem?

[Michael Jeschke]

Hi Friedrich, nothing new from my side.

Answer 5

[Stolniceanu Lucian]

It's been a long time,

Here is my hint.

Insert this code into your my_file.m file.

It should exclude dbstop from code generation, enable debugging and create a conditional breakpoint in your file.

Adapt file name, line number and condition according to your needs.

coder.extrinsic('dbstop')
dbstop in my_file at 37 if n>5

[Michael Jeschke]

Hi Stolniceanu,

unfortunately this does not help (I am still on version 2019b). It works in those files that already work fine with manually set break points, but it fails for those cases where the manually set break points fail.

While your code does place a conditional break point (yellow circle) at the specified line in the Matlab editor when running the model, the breakpoint is actually just being ignored during the simulation run.

So it is the same behaviour as with a manually (F12) set break point. Also those break points do show in the editor (red circle) but are ignored during simulation run.

Again, it is important to note that the problem only occurs when the external m-function is called from a [state_transition_conditon] - as of case (d) or (e) of my post from 10 Mar 2021, whereas the entire problem does not show up when the external function is called from within a state - as of case (c) of my post from 10 Mar 2021.

So in my case that I just reproduced - acc. to case (d): A [state_transition_condition] calls a MATLAB function inside the state chart. That MATLAB function in turn calls an external m-function which is an m-file on the PC's file system. The problem is that all break points in that external file are ignored - no matter whether the break point is defined by "F12" or by your "code solution".