I've noticed that FreeMaster will drop communication to my S32K144EV in certain situations. If add a certain amount of complexity to a working model, it no longer will connect to the board. For instance, if I have a tapped delay and I go above a certain number of delays. Or I add a signal generator. I'm not sure why that would happen but it seems dependent on the CPU load from the rest of the model because I can get more delays in a simple model than a slightly more complex model.
Does it make more sense to use 16 or 32 hardware average samples and take my delay reads down by the corresponding factor? Will this reduce the CPU load and let the hardware pick up some of the slack?
Also, I noticed that when I try to use hardware samples I also sometimes lose communications in FreeMaster. Why would that make any difference to the communications? Sometimes just adding hardware averaging causes it while sometimes changing the number of samples causes it. Without changing anything except hardware average sample number, I can run fine with 4,8, and 16 but when I switch to 32 I get a communications error. Doesn't seem like that should have any effect on the comms.
I found that if I simplify the model, I can get 32 hardware samples to read in FreeMaster so again it seems like FreeMaster communications is CPU load dependent.
We never discussed losing comms with the board in that thread, only that the update rate was not as fast as the actual ADC read. This is a totally separate issue. FreeMaster stops working completely depending on what I do with the blocks. I found that putting the FreeMaster config block priority at zero makes it work better but it still drops communication if I have enough things going on in the model. I will upload my model when I get a chance. I'll upload one that works and a copy with one change that breaks the comms.
Sorry about this situation. I was thinking that the mentioned thread already answered some questions.
FreeMaster communication basically adds an overload to the already running program by answering some requests over UART.
There are multiple ways of handling FreeMaster data in the generated code: Polling (in which the code only reads and replies Freemaster requests only in the main loop), Short interrupt (where the requests are received inside UART interrupt and replies are sent in the main loop) and Long interrupt (where everything happens inside the interrupt).
Now, requesting a variable at intervals of 0s basically faster read, the FreeMaster will flood the serial with requests regarding that variable, trying to bring as much data as it can.
In the models you sent us, the step function is triggered less than 100us, the PDB is triggering interrupts every each ADC conversion and if you add more code, probably the s32k will not reply to all the FreeMaster requests so the communication will fail. This is why if you change some interrupts priorities, the FreeMaster will work better because the hardware will choose to handle FreeMaster requests first.
For your scenario, when you want to see a sinus I recommend using the recorder. It will store locally the converted values and when the buffer is full it will send to FreeMaster scope.
Hope this helps,