Linux/am3359: CPU frequency governor effect on DCAN

ARieck9

Part Number: AM3359

Tool/software: Linux

We recently enabled the CPU frequency scaling (Linux) and set CPU_FREQ_GOV_ONDEMAND=y. Since then the can-bus seem to have problems when the CPU Governor changes frequencies while experiencing a load change. We are using socketcan() and the observation is that in the switching period the TX CAN-Buffers are not getting emptied fast enough and time critical Messages are delayed by about 2 seconds. Our assumption was that changing the CPU-Frequency would not really affecting interfaces in general. That does not seem to be correct assumption. Is there anybody with similar observations? Does CPU Frequency Scaling and socketcan() work together on the AM335x? Is there anything we have to consider when using CPU Frequency Governor and socketcan()? Greetings A.R

over 8 years ago

0 Biser Gatchev-XID over 8 years ago

TI__Guru**** 393215 points

What Linux version is this?

0 ARieck9 over 8 years ago in reply to Biser Gatchev-XID

Prodigy 40 points

We are using a 4.4.19 Kernel.

0 Schuyler Patton over 8 years ago in reply to ARieck9

TI__Mastermind 41570 points

Hi,
I have not heard of any issues with scaling frequencies and socketcan. Depending on what you are trying to do with frequency scaling you could first determine if lower frequencies are causing an issue by seting the governor to user space and then select one of the available frequencies.

Could you please post the result of "uname -a" from your console?

Best Regards,
Schuyler

0 ARieck9 over 8 years ago in reply to Schuyler Patton

Prodigy 40 points

uname:
Linux ml_Hz_06 4.4.19-phy2 ....
This is a modified TI-kernel from the module vendor phytec.

We recently changed our system to CPU_FREQ_GOV_ONDEMAND after a request to optimize power consumption.
Since then we experience problems of the application so far only in the CAN-area after 20 - 200h runtime.
We changed back to CPU_FREQ_GOV_PERFORMANCE and its back working again (several systems run stable with that setting/kernel for about a 18month).
The problem could be anywhere and we might only see the effect on time-based messaging of the can bus.
In our case it is the CAN-Open Heartbeat @ 1Hz which is delayed by more than 1 second and leads to a CAN-Open System error. The CAN-Open stack sits on top of socket-can.

Our assumption was that changing the CPU frequency would not affect peripherals, sockets, timers etc..
Maybe that assumption is not correct.

We are still struggling to isolate the problem from our application and creating a test case which shows the error in shorter time.

0 Schuyler Patton over 8 years ago in reply to ARieck9

TI__Mastermind 41570 points

Hi,

Thanks for posting the kernel info. I am assuming this is not an RT PREEMPT kernel. TI will only be able to support questions on the released SDK kernels. You may have to ask Phytec about this since they modifed the kernel.

Is it possible to run a TI kernel on the board? Do you have a TI EVM?

Were you able try what I mentioned in the previous post? Setting the governor to user space and then selecting an available frequency?

It sounds like you are familiar with this page but I am posting for follow-on readers:

processors.wiki.ti.com/.../Linux_Core_Power_Management_User's_Guide_(v4.1)

This link below is about setting user space and then setting one of the available frequencies, this would lock the MPU to this frequency and see if the lower frequency meets your product requirements. If it doesn't perhaps the next frequency up does.

processors.wiki.ti.com/.../Linux_Core_Power_Management_User's_Guide_(v4.1)

Best Regards,
Schuyler

0 ARieck9 over 8 years ago in reply to Schuyler Patton

Prodigy 40 points

Update on this topic: We were able to isolate the problem and nailed it down to a linux timerfd issue. See: stackoverflow.com/.../linux-cpu-frequency-scaling-affects-timerfd-accuracy This is not a frequency governor socketcan() or DCAN issue.

Processors

Processors forum

Linux/am3359: CPU frequency governor effect on DCAN