Are there recorder buffer size limitations for FreeMASTER 3.1 desktop app?

[lucabarbiero]

Hi,

I am downloading a 2MB recorder buffer (using an external RAM chip on target side) with Freemaster 3.1 desktop app. It kind of works, but it seems the desktop app struggles to receive a buffer of this size. Download is actually split in two consecutive tranches, of which the second one is initiated by a subsequent trigger. Despite no error, this is not really what I would expect. I would like buffer data to be downloaded and displayed in one go.

Is this behavior expected? Are there limitations for the desktop app with respect to the recorder buffer size it can handle in a single download session? I tend to think there is no issue on embedded target side. But of course I could also be misled.

Regards,

Luca

[lucabarbiero]

On the other hand changing FMSTR_COMM_BUFFER_SIZE to 508 in UDP mode does not seem to be a solution for me.

[lucabarbiero]

Dear @MichalH ,

I don't know what was the issue with my setup, but I can confirm that there is no tool limitation in handling a 2MB recorder buffer. I can now download the complete SDRAM. I achieved this with UART communication at 2.56 Mbps in 3'40'' download time.

Then I went further and I tried UDP communication to hopefully cut down that transfer time. In general the communication works, but I do see issues when attempting to download my large recorder buffer.I am getting a lot of "Response timeout" errors when I try to download anything larger than 40 Kb.

To investigate this issue, I inserted test pins in the freemaster driver code, before/after the invocation of _FMSTR_ReadMem (track 0, black) and _FMSTR_ReadMemBaseAddress (track 1, brown)  in freemaster_protocol.c.

And I noticed that _FMSTR_ReadMem is the one mostly used to access my SDRAM. There are bursts of invocations every 5ms (the rate at which I call FMSTR_Poll) separated by long idle intervals. Which may be the problem? I also had a look at the communication log which reports the occurrence of timeouts.

I tried to play with the FMSTR_COMM_BUFFER_SIZE define (make it larger or smaller) and the Timeout parameter of the UDP/TCP communication plugin (which seems to influence the duration of those idle times displayed in the logic analyzer trace posted above):

But no ultimate solution. Any idea?

Regards,

Luca

[MichalH]

Hello Luca, 

thanks for the report. Let me investigate what could be wrong with the UDP. This communication should be quite reliable on the wired Ethernet without packet losses (which I think causes the timeout and delays). But still a few timeouts should not break the whole transfer. 

Let mi investigate on my side. In the meanwhile, is it possible for you to:

• decrease the FMSTR_COMM_BUFFER_SIZE to 508
• try TCP transfer

Thanks,
Michal

[lucabarbiero]

Hi Michal,

TCP seems to work. I will check more thoroughly but from a quick attempt it looks good. I agree with you that there shouldn't be packet losses in a wired host-target ethernet connection. But apparently there are (at least in my setup) and likely it is the connection orientation of TCP that fixes this with re-transmissions.

These re-transmissions are probably slowing down the recorder buffer transfer, which could be faster otherwise. But it is already an achievement. Thanks for advising.

Luca

[MichalH]

Hello Luca,

good to hear the TCP works better. I did a quick re-test with UDP and even larger 8MB recorder buffer and it downloads reliably over my local network (I use i.MX-RT1064). For UDP, it takes about 20 seconds, for TCP, the same buffer takes about 30 seconds.

FreeMASTER protocol was not really designed for large data transfers. The PC tool should retry up to 10% of lost (timeout) frames when loading a large memory blocks, but even this does not seem enough in your setup. The TCP is a good solution here as it ensures the retries and delivery by itself.

Thanks,
Michal

[lucabarbiero]

Hello Michal,

Thank you for testing! Today I can't reproduce that same faulty behavior myself.. but before testing, I installed the very latest Freemaster 3.1 version from 22/03. I don't know if that's the thing, but this is a difference I can report. I will test this more, until I get a consistent behavior. Today I could download less than the required 2MB with the first triggering of a recorder after opening freemaster. Then if I trigger again a new session, it manages to download the whole buffer as wanted. I will let you know of any findings.

Thanks for your prompt support as always,

Luca

[MichalH]

Hello Luca,

this seems to be an issue of recorder download logic in the PC application. Let me verify.

Thank you for the report.
Michal

[MichalH]

Dear Luca,

I cannot repeat the issue on my side. I have tried an i.MX-RT1060 UDP and TCP demo applications from SDK 2.11, modified to run from external SDRAM and with a recorder buffer of 2M. The example recorder which samples var8, var16 and var32 variables seems to operate correctly, loading approximately 600.000 points.

As all test variables constantly increment so I think it would reveal the issue of "split download" as you have described. The waveforms look correct: var8 overflows above 255 and var16 overflows above 65535 just once. The var32 seems linear - which kind-of proves the recorder was fully stopped during the whole download.

What is the setup on your side? What MCU, what communication?

Can you try to repeat the issue with a simple example application?

Thanks,
Michal