FreeMASTER JSON-RPC variable write taking so long

[plinioandrade]

When using a webpage to send commands to FreeMASTER via ajax request using JSON-RPC I noticed it takes a long time (10+ seconds) to return the result of a write when FreeMASTER is open and some variables (~20) is being watched in the FreeMASTER application.

The problem disappear if I select a sub-group in the FreeMASTER that doesn't contain any watched variables.

I'm using FreeMASTER 3.1.

Can someone confirm that it is a common issue? Can NXP fix that?

Sincerely,

[MichalH]

Dear user,

we are not able to replicate the issue locally. Can you tell more about your communication options and about the variables in the Watch which cause the slow response? Here are some questions:

1. What is the communication type (UART/CAN/..) and baudrate?
2. What is the sampling period of the variables in the Watch?
3. Does it help to set all variables in the Watch to a larger sampling period (e.g. 2 seconds)?
4. What is the target MCU device and are you sure it responds promptly?
   FYI: The FreeMASTER always waits for the MCU response and blocks other communication, so if MCU is slow in responding (and not too slow for a timeout to expire), it may affect the overall communication speed significantly. The response timing can be observed in the Tools/Debug Log with logging details set to "All".

Thanks,
Michal

[plinioandrade]

Michal,

To answer all your questions and show the issue I recorded a video of my Desktop and I talk through it showing what's going on.

My recorded video is 85MB and cannot be uploaded here. I saved it on my OneDrive:

https://purdue0-my.sharepoint.com/:v:/g/personal/pandrad_purdue_edu/Eb305-E1Zj5InfvXWkEV58YBhLcQXMil...

Something that is not shown in the video is that I'm requesting 29 variables every 500mS on my page. Code is attached.

Please let me know if you can replicate the issue and what would be a good solution for it.

Sincerely,

[plinioandrade]

Any news regarding this issue?

[MichalH]

Hello,

unfortunately, the PD-BDM transport is the least effective one from all options, as it intensively communicates over JTAG and the access is not very fast. Having the variables sampled at 0 (fastest) period probably makes the communication thread occupied, not letting the JSON-RPC thread to get processing time. I need to do more experiments locally to be able to solve the issue, but here is what you can try to do as a quick workaround:

• Reduce the number of variables in the Watch and increase the sampling period from 0 to e.g. 100. This should give the JSON-RPC thread at least some window to jump in.
• Enable direct access to variables in the PD-BDM plug-in configuration (see screenshot below). This will enable FreeMASTER to make just a single JTAG access per one variable read instead of four accesses which are normally needed in PD-BDM protocol communication.

Let me know if this has helped at least a little. And I think you should consider using UART or CAN communication instead of PD-BDM which are definitely faster options.

[MichalH]

Hello,

have you been able to get the JSON-RPC communication working with the suggested workaround?

My local experiments do not show the same problem as you are facing even if I have several variables in the Watch sampled at the fastest rate. I wonder what could be different in your case. 

Thanks,
Michal

[plinioandrade]

Michal,

If you cannot recreate the issue I'm suspecting it is something to deal with my company security software that frequently slows down the engineering computers with too many process monitoring.

I will request IT to disable their system for a little bit so I can test again and I will let you know.

Sincerely,