MATLAB Answers

Simulink Debugging for MATLAB function block not working in R2020a

75 views (last 30 days)
Friedrich Tuttas
Friedrich Tuttas on 22 Aug 2020
Edited: Michael Jeschke on 10 Mar 2021
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?
  2 Comments
Friedrich Tuttas
Friedrich Tuttas on 25 Aug 2020
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:
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.

Sign in to comment.

Answers (3)

Jyotsna Talluri
Jyotsna Talluri on 27 Aug 2020
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

Landon Wagner
Landon Wagner on 7 Dec 2020
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.
  1 Comment
Friedrich Tuttas
Friedrich Tuttas on 9 Mar 2021
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?

Sign in to comment.


Michael Jeschke
Michael Jeschke on 10 Mar 2021
Edited: Michael Jeschke on 10 Mar 2021
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.
  1 Comment
Michael Jeschke
Michael Jeschke on 10 Mar 2021
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.

Sign in to comment.

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by