Issues with trace recording

[alessandrop]

Hello PEAK-Support Team,

I'm using a PCAN-Router Pro FD exploiting the "ready-to-use firmware for tracing CAN data" mentioned in the user manual, and I've some questions.

The manual states that if TRC_MODE=2 in the config.txt file, the circular-append option should be set, implying that:

• If a new recording is started, existing trace files are kept.

• If the memory's maximum capacity is reached, the oldest file is deleted and a new file with an incremented file index is created.

Unfortunately, I'm not able to replicate such a feature. Figure "Issue_1" shows a case in which the device is powered ON, the Wake-up signal is ON, two traces are normally recorded, then at some point during the record of the third trace the memory card becames full, subsequently several 0 kB traces are stored. The device doesn't delete the old files to replace them with new ones. Sometimes, I'm able to obtain the expected behaviour retriggering the Wake-Up signal (ON-->OFF-->ON), but the new file doesn't have an incremented index and it doesn't happen all the times.

Moreover, I found also the following two issues:

• Assume that the device is powered ON, the Wake-up signal is ON, and the CAN traffic is ON. At some point, both the CAN traffic and the Wake-up signal go OFF, then some extra short (each 5 s long, like the parameter TRC_STOP_T15_TO) traces are recorded. Please, see figure "Issue_2", in this test such a phenomenon happened two times.

• Assume that the device is powered ON, the Wake-up signal is OFF, and the CAN traffic is ON. In this case, short (each 5 s long, like the parameter TRC_STOP_T15_TO) traces are recorded indefinitely. Please, see figure "Issue_3".

Could you please help me? In attachment, you can find the config.txt file.

Thank you,
Alessandro

[alessandrop]

Unfortunately, this morning I found a problem in the setup that I used yesterday for my tests. Basically, when yesterday I assumed that the CAN traffic was OFF, actually it was still ON for 10-15 s. This morning I solved this problem, so now I'm no more able to replicate the phenomenon reported in figure "Issue_2". So, please, excuse me and ignore that issue.

On the other hand, I tried to replicate the phenomena described by figures "Issue_1" and "Issue_3" and I still have both problems.

As a matter of clarification for "Issue_1", I produced two more screenshots describing whant I meant when I wrote Sometimes, I'm able to obtain the expected behaviour retriggering the Wake-Up signal (ON-->OFF-->ON), but the new file doesn't have an incremented index: please, see figures "Issue_1_addendum_1" and "Issue_1_addendum_2".
Basically, sometimes when the memory card is full, I'm able to obtain the circular-append option by retriggering the Wake-Up signal (ON --> OFF for at least 5 s --> ON), so that the oldest file is deleted as expected, but the new file doesn't have an incremented index, its index starts again with 1.
In principle, this is not a big deal. The real problem is that this behaviour doesnt' happen all the times. Sometimes the device behaves this way, sometimes behaves like reported in figure "Issue_1" in my original post of yesterday afternoon.

Could you please give me an help?

Thank you,
Alessandro

[M.Heidemann]

Hello,

Can you tell us the used Firmware?

Did you make sure that you also use a matching config file?

BR

Marvin

[alessandrop]

Hello Marvin,

Thank you for your reply.

The installed FW version is the 1.2.0.13, please see the attached picture.

In the meantime, I made other tests and I found six different cases that belong to three common scenarios: A, B, and C. Such scenarios are summarised in the attached pictures and in the following list:

• A: CAN traffic is OFF, device is powered ON, CAN traffic is still OFF, after at least 5 s the Wake-up signal goes ON, CAN traffic goes ON, memory card becomes full, Wake-up signal goes OFF for at least 5 s, Wake-up signal goes ON --> The feature circular-append doesn't work, several 0 kB traces are stored.

• B: CAN traffic is OFF, device is powered ON, CAN traffic goes ON for more than 5 s, Wake-up signal goes ON, memory card becomes full, Wake-up signal goes OFF for at least 5 s, Wake-up signal goes ON --> A short trace 5 s long is stored at the beginning. The feature circular-append doesn't work, several 0 kB traces are stored.

• B: CAN traffic is ON, device is powered ON, CAN traffic is still ON for more than 5 s, Wake-up signal goes ON, memory card becomes full, Wake-up signal goes OFF for at least 5 s, Wake-up signal goes ON --> A short trace 5 s long is stored at the beginning. The feature circular-append doesn't work, several 0 kB traces are stored.

• C: CAN traffic is OFF, device is powered ON, Wake-up signal goes ON in less than 5 s, CAN traffic goes ON, memory card becomes full, Wake-up signal goes OFF for at least 5 s, Wake-up signal goes ON --> The feature circular-append works, but the new file doesn't have an incremented index, its index starts again with 1.

• C: CAN traffic is OFF, device is powered ON, CAN traffic goes ON for less than 5 s, Wake-up signal goes ON, memory card becomes full, Wake-up signal goes OFF for at least 5 s, Wake-up signal goes ON --> The feature circular-append works, but the new file doesn't have an incremented index, its index starts again with 1.

• C: CAN traffic is ON, device is powered ON, CAN traffic is still ON for less than 5 s, Wake-up signal goes ON, memory card becomes full, Wake-up signal goes OFF for at least 5 s, Wake-up signal goes ON --> The feature circular-append works, but the new file doesn't have an incremented index, its index starts again with 1.

Does the device is intended to work this way?

Thank you,
Alessandro

[M.Heidemann]

Hello,

Let me ask you again, can you confirm, that the config file MATCHES the current Firmware?

Also, can you send us your config?

We'll need a reference to get any idea whats going on here.

BR

Marvin

[alessandrop]

Hello,

I already attached the config file in my first post, anyway you can find it also in this reply post.

Regarding the "matching config file" question: since I simply modified the original config file that was provided together with the data logger, I suppose that it should match the installed FW version.

Best,
Alessandro

[alessandrop]

Dear PEAK-Support Team,

Did you have time to investigate the issues that I reported in my previous posts?

Thank you,
Alessandro

[M.Heidemann]

Hello Alessandro,

Issues as involved as this might be a better fit for an email request, i have to admit i lost track due to a high volume of support requests, i'm terribly sorry.

Is this behavior replicable with both writing to EMMC as well as SD-Card?

Also, just as a suspicion on my side:

Can you re-download the DevPack and flash the latest firmware again and use the latest config file as well?

https://www.peak-system.com/quick/DLP-DevPack

The behavior is quite strange, i almost suspect something in regards of the firmware got corrupted,
let's see if we can replicate this with a fresh install.

And once again sorry for the long delay!

BR

Marvin

[alessandrop]

Hello Marvin,

Thank you for your reply. I re-download the DevPack using your link and flashed the device first with rprofd_bl_upgrade_2_1_0.bin bootloader version and then with the latest firmware version Logging-Firmware_1.2.1.15.bin.

I performed the tests described in my post of Thursday, 5th December, using the latest config file available, and I can replicate Scenarios A and B. Unfortunately, I can no longer replicate Scenario C, which was not optimal but was at least a working condition.

Do you have any idea to solve such an issue?

Thank you,
Alessandro

[M.Heidemann]

Hello,

so we don't lose track, what's the current behavior you do see?

Can you outline which behavior specifically is reproducable (you have multile items under A, e.g)

Best Regards

Marvin