Handling 64-bit data types with freemaster desktop application (bug report)

[lucabarbiero]

Hello,

I am working with latest Freemaster 3.1.4.5, and I think there is a bug in the way the application handles 64-bit data types. More specifically, the problem seems to exist in the recorder functionality but not in the watch window. Following is what I did:

1. First of all I made sure that 64-bit data is received correctly from the target. I recorded a 64-bit variable with a known, constant hex pattern and I checked with Wireshark the existence of that pattern in the TCP/IP packets payload. Additionally, I can tell that the same 64-bit pattern is displayed correctly in the watch window. Therefore I can exclude any issue on target side, and I can restrict the focus on the recorder feature.

2. When I record the same hex pattern and I use the "data capture" feature to export this variable to a text file, I notice that the least significant bits are replaced with zeros! The same if I connect to Freemaster via ActiveX. I can't tell about the recorder graph, because I wasn't even paying attention to it. Probably the problem is there too. Anyway I want to export data to MATLAB for further processing.

Can you repeat the same exercise and let me know? Are you able to correctly record/export a 64-bit variable with a known pattern, for example 0xFF123456789ABCDE? Please try both signed and unsigned 64-bit: I see differences, but there is corruption in both cases.

Many thanks!

Luca

[lucabarbiero]

Hi Michal,

Thank you, that explains.

I am trying to record 24 bytes of raw data within a very fast 5us interrupt time frame. Which turns out to be feasible only if I record that data as 3x 64-bit words. If I attempt to record the same data as 6x 32-bit words I run out of time and the recorder doesn't work, unless I introduce a down-sample factor of 2 (which would be undesirable).

Probably because for each variable to record there is some overhead. So not only the size, but really the number of variables we want to record has an impact on the recorder processing time. My experience shows that it's faster to pack data in less (but larger) variables than to record the same in smaller (but more numerous) variables.

In the end my workaround will be to accept the downsampling, or to drop some of that data. I can record 3x 32-bit words in that short time-frame. Which can be acceptable too. Unless you have some other idea?

Regards,

Luca

[MichalH · Accepted solution]

Hello Luca,

yes, you are correct. The FMSTR_Recorder() iterates over all variables to be recorded and copies each value to the recorder buffer. The loop iteration is slower than the memory copy so the less variables in total, the faster processing even if the variables are larger.

I think the only way to speed it up is to modify the freemaster_rec.c and the _FMSTR_Recorder2() code. Here are some tips - they will corrupt the standard behavior of the recorder, but it could work for your use case:

• Remove the trigger evaluation code and replace it by some other/faster mechanism (e.g. testing a some global variable)
• Replace FMSTR_MemCpyFrom() call which is used to copy a variable value into the recorder buffer. The FMSTR_MemCpyFrom is perhaps too complex for your simple use case as it does extra checks on memory alignment and tries to access the memory with the largest possible aligned access. Replacing it by simple memcpy could save some microseconds too.
• An extreme case would be to get rid of the variable-iteration loop and just hardcode your variable copying to the buffer (still you will need some code which would call the _FMSTR_TriggerRec)

But maybe a much better alternative would be to "record" your data yourself into a temporary array and use the FreeMASTER ArrayViewer to download it and capture to a file. In this case, you could define the array viewer as 24 single-byte variables and use it as is without affecting any other FreeMASTER functionality.

Regards,
Michal

[lucabarbiero]

Hi Michal,

Thank you for all these tips. I partially looked into these options, but you gave me useful additional info.

I think this tool and the team behind it are just amazing. It helps me so much.

Keep up the good work!

Luca

[MichalH]

Hello Luca,

This behavior is there by design. The Oscilloscope and Recorder process data as double type so the large 64bit integer values get rounded. The double type can only handle 53bit integers without loosing precision.

For the purpose of recorder data capture, you can try to record the value in two halves (two 32bit values) and then post-process them. One variable would be 4 bytes long at the proper address X and the other would be another 4 bytes at address X+4.

Only be careful with synchronization - reading the two "variables" takes place in the FMSTR_Recorder() call. It should not be interrupted by any code which modifies the 64 bit value.

Regards,
Michal