Simulink Debugging for MATLAB function block not working in R2020a

55 次查看（过去 30 天）
Friedrich Tuttas
Friedrich Tuttas 2020-8-22
评论： Friedrich Tuttas 2023-12-30
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 个评论
Friedrich Tuttas
Friedrich Tuttas 2020-8-25
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.

请先登录，再进行评论。

请先登录，再回答此问题。

回答（5 个）

Friedrich Tuttas
Friedrich Tuttas 2021-12-3
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.
  2 个评论
Co Melissant
Co Melissant 2023-12-19
any updates?
we face similar issues running 20b. breakpoints ignored - or in other cases, required to have the correct functional behaviour during simulation!

请先登录，再进行评论。

Jyotsna Talluri
Jyotsna Talluri 2020-8-27
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
Landon Wagner
Landon Wagner 2020-12-7
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 个评论
Friedrich Tuttas
Friedrich Tuttas 2021-3-9
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?

请先登录，再进行评论。

Michael Jeschke
Michael Jeschke 2021-3-10
编辑：Michael Jeschke 2021-3-10
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.
  3 个评论
显示 1更早的评论
Friedrich Tuttas
Friedrich Tuttas 2021-12-3
Hello Michael,
thanks for the reply. Did you find find a solution to your problem?

请先登录，再进行评论。

Stolniceanu Lucian
Stolniceanu Lucian 2022-11-16
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
  1 个评论
Michael Jeschke
Michael Jeschke 2022-11-17
编辑：Michael Jeschke 2022-11-17
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".

请先登录，再进行评论。

类别

在 Help Center 和 File Exchange 中查找有关 Simulink Functions 的更多信息

标签

Community Treasure Hunt

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

Start Hunting!

Translated by