With just SDIO8787 .net35 and the standard 2.2b4 image, it crashed again with the re-boot test after about 4 hours.
Today, I will run just the evaluation kit with 2.2b4 and nothing else and leave it run for as long as possible.
Please confirm that you are trying to re-produce this in your lab. There should be enough information here for you to reproduce in a few hours testing.
Dear @kswain,
Thank you for sharing all the details. I am trying to reproduce the issue and get back you as soon as if I have an update for you.
We have run .NET35 and 2.2b4 image overnight twice without any crash (No SDIO878). It seems that SDIO8787 is part of the problem.
To reproduce, just install SDIO8787 and reboot continuously with 20 pings in autorun. It should lockup in about 4 hours or less.
We continually ran .NET 3.5 and 2.2b4 without SDIO8787, and the re-boot test ran all weekend plus Friday without crash.
We have concluded that the SD8787 driver/SDIO stack or something to do with wired/wiressless combination is the cause of the failure.
The setup MUST have the SDIO8787 driver and card installed for it to fail. I attached the exact installer package for driver on this ticket already. Our setup simply has the board re-boot continually until networking fails. Usually, the ping doesn’t make it to 20 times, and there is a lockup. After that both wired and wireless is unresponsive.
In our test without the SDIO8787, we re-booted continually for 4 days without fail. With the SDIO8787 installed, we couldn’t make it past 4 hours.
Dear @kswain,
Thank you for your patience.
We have been trying last 4 days to reproduce the issue with Wi-Fi Adapter connected but couldn’t able to reproduce. Attached logs here.
Could you please take backup of all the files using UpdateTool as described here and share with us, let me program the same binary and configuration and try to reproduce the issue.
Did WiFi adapter connected with any access point(created a preferred profile) for the testing? From your log, I guess it is not connected with any access point.
Could you please share more details about how the power cycle hardware setup is done and maybe a picture would be helpful? Is it easy make on our side or running netsend.exe application on another toradex module and controlling target board power?
Our setup has already been outlined. I previously attached the software we are using here. All is based on the latest 2.2b4 loaded with UpdateTool:
https://share.toradex.com/dl7suunp8u5keik?direct
We narrowed it down to just .NET35 and SDIO8787 driver. In our later tests, we did not use any registry additions. A picture of our setup was also attached previously here:
https://share.toradex.com/u64htu6pjrc1sg8?direct
We eliminated .NET35 because without the SDIO8787 driver, we ran for four days without a crash. We tried both “associated” and “not associated” to access point, and both failed. It did seem to fail faster with access point though, although that could just be coincidence.
Our autorun batch file is just:
ping 192.168.0.210 -n 20 -w 1000
\FlashDisk\netsend.exe
netsend.exe is just an application that sends a command over Wired Ethernet to re-boot the system. If there is a problem with the network layer, the re-boot never happens. It is nearly irrelevant though, as most often the crashes happen somewhere in the 20 ping requests. We never make it that far. With this setup, we end up re-booting about once a minute, and crash in 1-4 hours.
I’ve attached a backup of our disk here. There isn’t much different from your stock 2.2b4. We add .NET35, SDIO8787 driver, set IP address to static 192.168.0.200, and add our netsend.exe and autorun batch file. That’s it. You may want to try both associated and not associated to access point. We found both failed, but I feel that associated might fail faster.
