We are still busy with other thing. But next thing is that issue we believe.
Thanks for reminding us.
Hi,
We just tried your project, and could not reproduce it. The speed we set is 1000msg/sec. Our software could not set higher than that, but x2 higher than your test (500 msg/second)
Also, temperature doesn’t go up, it is at 42-43 Celsius.
Also, we tried to receive messages in event, speed also higher than 1000mgs/second.
We ran around 400,000 message, no problem found. We pause to capture the screen so you can see MessageToRead is 0, not the bug we are talking about.
During this, network socket still sending and my Application Server still get data from SC20100 just fine.
Did you see the problem on the project you sent us, or your full project?
Thank you for trying it out.
I saw the problem in the project I sent you.
I find it weird you’re unable to reproduce the issue. What network did you use? A onboard PHY or the externel ENC like I’m doing?
Would it help further if I were to record a small video of my issue? Or would it be better to hop on a zoom call? Please let me know what I could potentially do to fix this problem. 
Unfortunately that would not help. We can only fix issues we can reproduce on our end.
Did you try a different board? Did you verify your power source?
I have not yet tried a different board. I’m hoping that I can do this next week.
The power source is fine, I checked it with my oscilloscope.
Please keep in mind that CAN specification calls for devices to go passive or even buss off after receiving numerous error to protect the other nodes on the bus. And the only way for the device to go back is by resetting the CAN controller. I would double check your bit timing, wires, termination resistors…etc.
Thats the thing. The error event is not being triggered from within my code. It feels as if the entire CAN controller class just locks up in this state. It doesnt come out until I run this code:
can.Disable();
can.Enable();
The bit timing is the one provided by GHI, as seen in my sample code. The wires consist of high quality CAN bus wire and the impedance is exactly 60 ohms. I think it’s safe to say that those are not the problem.
Also, the other nodes on my bus (not GHI TinyCLR but Arduino based) are still receiving the messages after the CAN controller of my tinyclr node locks up. This is a further confirmation my wires and impedance are correct.
I agree. So now we need a way to reproduce this on our end and need your help with that please.
Every system is different. Bit timing is a very complex subject. But with your earlier note, it seems as the problem is not bit timing if you see no errors.
Correct.
Step1:
Try ENC since we didn’t want to change any thing in your code first.
But we did change IP config and MAC which didn’t work for us.
Step2:
Change to Ethernet
Step3:
Change to WiFi
Step4:
Try to read message in event
Step5:
Add reading temperature.
Only thing we are not sure is the Application server where read data from the socket. We don’t have it and we wrote it by self. If you have then you can send to us.
Also, the CAN application that we are using to send 1000msg/ second can make different. How do you send the message from the host?
I am using the program PacketSender to open a UDP socket on my pc.
Also, the CAN application that we are using to send 1000msg/ second can make different. How do you send the message from the host?
I am using a Teensy 4.1 with a ISO1050DUBR CAN Transceiver from TI.
My offer to hop on a zoom call still stands. I think this will make reproducing the issue a lot easier.
The CAN peripheral does not fully lock up. I can still send messages when the read part stops working.
Also, how would you measure the temperature from within the code?
static void ReadTemperatureSensor()
{
var adc3 = AdcController.FromName(SC20100.Adc.Controller3.Id);
var Adc18 = adc3.OpenChannel(SC20100.Adc.Controller3.InternalTemperatureSensor);
var regTS_CAL1 = (IntPtr)0x1FF1E820;
var regTS_CAL2 = (IntPtr)0x1FF1E840;
const uint PERIPH_BASE = 0x40000000;
const uint D3_AHB1PERIPH_BASE = (PERIPH_BASE + 0x18020000);
const uint ADC3_COMMON_BASE = (D3_AHB1PERIPH_BASE + 0x6300);
var reTempetureWakup = (IntPtr)(ADC3_COMMON_BASE + 8);
var reTempetureWakupValue = Marshal.ReadInt32(reTempetureWakup);
reTempetureWakupValue |= (1 << 23);
Marshal.WriteInt32(reTempetureWakup, reTempetureWakupValue);
while (true)
{
var v = Adc18.ReadValue();
var ts1 = Marshal.ReadInt32(regTS_CAL1);
var ts2 = Marshal.ReadInt32(regTS_CAL2);
var t1 = (110 - 30) * 1.0;
var t2 = (ts2 - ts1) * 1.0;
var t3 = (v - ts1) * 1.0;
temperatureSensor = t1 / t2 * t3 + 30;
Thread.Sleep(1000);
}
}
That returns a temperature of between 700 and 760 degrees. I’m assuming that’s incorrect since the CPU has not melted away yet.
Make sure ADC must be opened before the enabled temperature wake up sensor.
Doesnt this part of the code open the ADC?
var adc3 = AdcController.FromName(SC20100.Adc.Controller3.Id);
var Adc18 = adc3.OpenChannel(SC20100.Adc.Controller3.InternalTemperatureSensor);I just replaced the SoC for a new one, that didnt fix it either. Just wanted to rule that out…
What hardware are you testing this on? I’m starting to suspect my ENC28J60 circuit to be at fault.
Do you have a schematic or reference design of the board you’re using to test so I can compare with my ENC28J60 circuit?
I used this:
Are you using a custom board?
Yes, my board is custom.
The reason I’m suspecting the ENC28J60 or something else network related to be at fault is because it works for 100% when I turn off this line of code:
sock.SendTo(data, endPoint);
Quick question, this line is commented out in my example program. Do you have it commented out as well during your testing? I’m expecting you don’t because as you said, you are receiving the packets but I just want to make sure.
Yes, we enabled that line.