I was just testing my code, the usual, debug/deploy/stop and all of a sudden the board cant be recognized anymore, switched to another usb, tried tinyclr config, nothing.
Then I tried ldr+reset, and its in bootloader with no firmware, what action can erase firmware besides with tinyclr config? (something with watchdog??)
A week or two ago, I had one unit returned which stopped working for no reason. I tried to see what’s going on with tinyclr and I just quickly installed firmware and app. I thought maybe I forgot to upload an app to this unit, now I know its not the case. Because it worked for some time.
Did you try APP+Reset? To start the board up but prevent your application code from running, that is at least confirm that it is not something in the application causing a problem.
Yeah i disabled the app button so it can be used as gpio.
Also when in bootloader i tried to install RC1 firmware again, it finished but never restarted, so i ended up again in bootloader, tried for several times, FW just didn’t stick.
And finally i had a restart pending with new windows version, after the restart and update i could flash the FW and all started working again.
im just gonna put this on gremlins in the machine for now.
It should be near possible to lose the firmware. My guess is that your application crashed the firmware and this is why you could not deploy again. If the firmware was not there then the device will automatically stay in the loader mode.
If you manage to reproduce and give us the steps we need to crash the firmware then we can fix on our end.
Once you re-flash firmware, the disable flag is gone and the app button become active. If your custom board is pull down this pin then the app doesn’t run.
I should report the same or similar situation repeatedly happened for me.
I realized my application was crashing.
In this case i was setting the constructor of the SpiConnectionSettings to use ChipSelect internally along with assigning a GPIO with the ChipSelectLine parameter.
Then the application would trying to configure that same GPIO for use as an externally controlled ChipSelect.
I loaded and launching debugger, and as a consequence the device would crash and completely disappear as a USB device.
At this point starting Tiny Config the device would only be recognized after pressing the boot loader button. I could see the firmware version listed as the default (not 2.1.0.5000) and and there was no application.
I could only recover by first Erase All, then reconnecting and re-Update Firmware to the version stated above. (only to repeat the problem until i realized my SPI error)
It is my belief that if SPI is configured to use ChipSelect a GPIO and then trying to configure and use that same GPIO externally, in that order, and not catching the error, it should have a good chance to reproduce this problem.
I apologize in advanced if this proves not exactly the repro steps but im positive it is close.
Indeed the device could not be pinged, as it was completely unrecognized on the USB bus.
Did i mis refer the App button to the boot loader button? Regardless, the button on the Flea board needed to be pressed in order to have the USB bus recognize the device again.
No doubt it was the application, as i was able to find the fault as noted, the important note here is that the board appeared to have lost not only the Application, but the firmware, similarly to OPs report. After pressing the App button as noted the default firmware was noted in TinyConfig, not the firmware that had been installed for RC1
im just gonna put this on gremlins in the machine for now.
(Sorry !)