2024-07-14 01:55 PM
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?
2024-07-14 02:16 PM
I seriously doubt anyone's got an apples-to-apples case for your issue / failure.
If you can't understand what your own code is doing, it's not clear how uninvolved parties are going to know.
Instrument things so you can better understand what's happening internally, and query / probe current state. Perhaps the ability to dump buffer, or memory structures, and reset buffering.
If using dynamic memory look at fragmentation and resource leaking.
2024-07-14 02:53 PM
Dear @sqwerize ,
Also check the Clocks used on your system , a long term jitter may affect CAN bus . If possible to share your setup - crystal , PLL etc.
Hope it helps.
STOne-32
2024-07-14 03:09 PM - edited 2024-07-14 03:16 PM
2024-07-15 12:40 AM
Hello,
You need also to check if there were some errors on CAN communication. So activate the error interrupts, check also TEC and REC counters.
2024-07-15 01:14 AM
Hey, I found a similar problem on another forum, so maybe it's not entirely a canbus problem...
https://forum.arduino.cc/t/stm32-performance-slowing-down-over-time/1005525
2024-07-15 02:03 AM - edited 2024-07-15 03:17 AM
To my knowledge, we didn't have a such kind of issues from our customers.
The link you provided, the guy is using STM32F103 which is completely different from yours (STM32H750): different architecture, different CAN cell: STM32F103 has bxCAN cell (classical CAN) while H7 has FDCAN cell were you are using it in CAN-FD mode. This means, most probably it's not related to the CAN HAL driver nor to the CAN cell. But from your usage of it: software of HW.
You need to instrument your code and check the CAN errors. There is no solution off the shelf in this kind of situation.
2024-07-15 02:58 AM
The count++ count-- method of determining capacity/usage is not thread safe
Instrument so you can check if head and tail diverge when count reports as zero.
2024-07-15 03:07 AM
This is almost certainly irrelevant to your situation.
Focus on understanding your own system dynamics and cause, not symptom of being slow.
Toggle a pin at 1 KHz in Systick and observe if you can scope 500 KHz signal. If it does, disabuse yourself that "STM32 running slowly" and move on to what the real problem is. If it does slow look at causes like unserviced interrupt storm or other saturation issues.
2024-07-15 03:21 AM - edited 2024-07-15 03:21 AM
This is a great idea to check the problem!!! Today I will try to do the tests this way and will come back with the results!
I don't use FreeRTOS because I had a very big performance drop and problems with accessing a resource at the same time, mutexes and semaphores didn't do very well.
Therefore, the main loop calls the function to flip data between can interfaces. In addition, timers add additional frames at intervals.