I am not using a watchdog anywhere in the application.
The devices are running firmware version 2.2.2.1000
If it boots to Loader mode mean firmware was corrupted.
If the application does run but you can ping TinyCLR means application was corrupted.
when call FlashAndReset(), application will be update first then firmware. If application is large (3.4MB) it may take time. And during reflash firmware, there is one time, system is busy and won’t response to user by indicator pin, around 3-4 seconds. Probably your user think IFU is done and reset the board?
Is there anyway we have these modules for investigation?
Can you reproduce it now?
I have the modules. All 3 are in Loader mode now.
I will see if I can reproduce the problem.
and check the loader pin, make sure it is not floating or pull to low with your design if this is custom board.
I have tried 4 or 5 times here and I can’t duplicate.
The customer stated that after the update, the screen went black and never came back on. After a few minutes of waiting they cycled the power and the screen never came back on.
Normally, the screen stays visible during the entire update process until the device reboots. After a few seconds, the display comes back up.
The loader pin is connected to a push button like the GHI dev boards.
When can we expect the fix to be release?
I ran an upgrade test toggling between two versions overnight and managed to brick the module at the office. Indeed, it is in loader mode.
I’ve made the change to kick the watchdog just before the FlashAndReset method is called but that does not seem to have solve our issue.
We are investigating on this issue.
Make sure that System.GC.Collect() does not run during the in-field process.
I had a System.GC.Collect() running periodically on another thread. If it hit at just the right time it would brick the board.
1 Like
Try 2.3.0.1000: Downloads (ghielectronics.com)
and let us know.
Hi,
I’ve updated our software stack to version 2.3.0.1000, but the problem persists. However, it seems that only the application is crashing, as I no longer need to flash the firmware just the application using TinyCLR Config.
Can you give us sample code that we can reproduce?
Hi,
I’ve been running some more tests, and so far, using the SCM20260D Dev board does not appear to have the issue. My current finding is that disabling UART8, to which our board has an EnOcean transceiver connected, might be causing the problem.
I’ll let our test setup run overnight and update you tomorrow.
And 5mins later the SCM20260D Dev board crashed after 10 successful updates over the day.
Is it enough if I send you two images that can be toggled between using USB sticks?
Yes, please send to us that one. We let the test run over weekend, start on Friday and it still works fine after we back on Monday, I guess few thousand times or more, so after 5min if we can reproduce that will be very good for us.
Please let me know where to email the images and documentation
to me directly if you can. dat.tran @ gh…
Finally had time to investigate further, and it appears that our issue is related to multithreading.
We experience the issue when calling InFieldUpdate.FlashAndReset() from a thread other than the main thread.
1 Like
To me, it is still bug and we still would like to have a sample project to reproduce, at least to know what kind of thread caused the issue. It should work fine on any thread.
But if you are happy with what you found, and need us help in the future, just let us know.