STM32H750 Performance slows down after time

[sqwerize]

Hi!
I have a problem with the canbus gateway project, I have a very good ring buffer that works without delays and transfers data between can1 and can2. All data copying is done through the main while loop where I check the buffers for can1 and can2 to see if there is anything to send and handle it. The project works great, but after 2-3 hours of driving, strange anomalies start to happen... There is a second delay in data transfer, when I press the reset button on the art-pi board, everything returns to normal and works properly for the next 2-3 hours. I thought it might be a buffer overflow problem which can hold 512 messages for each can. However, when I turn off the vehicle and after a minute there are no frames on the bus and I restart the vehicle, the delay is still there... So it's not the buffers' fault. Has anyone encountered such a problem?

[Tesla DeLorean]

Add a buffer reset function that clears head, tail, count, to see if that recovers the latency/lag situation. 

[SofLit]

Besides the "slowness" you're facing, and as you are using two CAN instances in your application, there is an errata related to this situation on STM32H750.

Refer to the errata sheet rev 12. Errata 2.24.2 

[sqwerize]

Thank you for the information... It seems very possible... Is there any way to solve such a case? Maybe interrupt priorities will help something here? At the moment the interrupts for CAN1 and CAN2 are 0 so they have the same priority, but I wonder if slowing down any of them will cause communication delays which may result in errors in the car :(

In the canbus configuration I separated the offset for the message, but this is unlikely to have anything to do with the problem?
hfdcan1.Init.MessageRAMOffset = 0;
hfdcan2.Init.MessageRAMOffset = 1280;

[SofLit]

I don't think the errata I mentioned is related to your problem. Just wanted to highlight it as you are using two FDCAN instances and the errata consists of an issue of data integrity not the performance of the communication. And as indicated by the errata, unfortunately, there is no workaround: