Would it help if I ordered a dev board and the mikroe board you’re using?
Or do you think it would be better if I were to use the onboard PHY of the SC20100S? If so, is there any documentation on how to connect it, the correct impedance and what mag jack to use?
How easy were you able to reproduce ?
If 1-2 time in few hours then we will try more. But it happened every 500 messages easily then we are not on same page. If so then yes, you may need a dev board to see how different between yours and ours design.
I can reproduce this in a matter of seconds. It usually happens after 10 seconds of running the code.
What option would be best? The dev board or a board using the builtin PHY?
Are there any advantages over using a ENC over the builtin PHY?
Builtin PHY because 100Mbs. I think ENC is only 10Mbs.
Meaning CAN chip also different ?
Yes. The can chip is a ISO1500DUB by TI. I have used it for many years and never had issues with it.
Do you have documentation on what mag jack and impedance to use for the PHY?
Hi, how hard to you to get our SC20100S Dev board for testing the issue?
Just ordered a SC20100S dev board from Digi and a Mikroe ENC28 click to test it out. Should arrive in a few days, I will report back my findings afterwards.
I tried the same program using the dev board + mikroe click and the problem still occurs. The only difference is that the temperature sensor is now working properly.
Here you see that the problem occurs after having read 410727 messages, this occurs after 410 seconds (6 minutes) because the message rate is 1000 msg/sec.
After redeploying the same code, it seems to happen after a rather random amount of messages. Below are some more screenshots of this phenomenon.
This can be observed quicker if we send 2k msg/sec instead of 1k:
This should be possible for you guys to reproduce as it is happening at 1000 msg/sec.
I figured out why the temperature sensor on my custom board did not work. I forgot to add the connections between VREF/VDDA to VCC in my schematic. A quick wire bridge fixed the problem, next version will get a ferrite bead though.
Sweet, now we only focus on receiving message issue.
Is there anything more I can do to help? Are you able to reproduce the issue now?
Hi,
add this right after can.Enable(), it will work fine.
IntPtr add = (IntPtr)(0x4000a054);
var value = Marshal.ReadInt32(add);
value |= (1<<2);
Marshal.WriteInt32(add, value);
Hi,
Thank you for the help, will this code be included in the can.Enable() function in the next release?
This does seem to fix the issue where the messagestoread goes to zero (I’m still testing this), but it seems to decrease the amount of messages/sec I am able to process.
When sending 1000 msg/sec, the program only counts 830 of them per second and ocasionally a can error 1 (read buffer full) is spit out.
I just crossed a total of 10 million messages processed, at a rate of 600 msg/sec, without any failures or errors being tossed.
You did an awesome job @Dat_Tran and @Gus_Issa. Thank you guys so much for the help 
Thanks. That flag doesn’t do anything with the speed. That flag can be set/clear after can.Enable(), so you can implement a button to set/clear to compare the speed. (press to set, press to clear…)
At 1000 msg/sec, meaning your system has to process a message less than 1ms. Check anything change from last time where we already reach to 1000 msg.
When sending 1000 msg/sec, the program only counts 830 of them per second and ocasionally a can error 1 (read buffer full) is spit out.
Yes, that error is expected if system could not keep up the speed. You can increase the can.ReadBufferSize to 265 or 1024… depends how much memory left. But this just help in special time when system busy. If system is always busy and can’t keep up 1ms all the time, buffer may full then, just longer.
I tested this until it reached a total processed messages count of 52+ million.
Once again, @Gus_Issa and @Dat_Tran thank you for the amazing help and the amazing product you’re building. I am very very impressed. 
Millions … Sounds great 
I also found the performance problem. I had dialed down my SPI clock frequency while testing something and it was still at 1Mhz.
Performance of sending the CAN messages over UDP improved as soon as I increased this to the ENC28J60s max clock of 20MHz 