Simulink Debugging for MATLAB function block not working in R2020a
68 visualizaciones (últimos 30 días)
Mostrar comentarios más antiguos
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 comentarios
Respuestas (5)
Friedrich Tuttas
el 3 de Dic. de 2021
2 comentarios
Co Melissant
el 19 de Dic. de 2023
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
el 27 de Ag. de 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
0 comentarios
Landon Wagner
el 7 de Dic. de 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.
Michael Jeschke
el 10 de Mzo. de 2021
Editada: Michael Jeschke
el 10 de Mzo. de 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.
3 comentarios
Stolniceanu Lucian
el 16 de Nov. de 2022
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 comentario
Michael Jeschke
el 17 de Nov. de 2022
Editada: Michael Jeschke
el 17 de Nov. de 2022
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".
Ver también
Categorías
Más información sobre Simulink Functions en Help Center y File Exchange.
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!