Firmware gone?!

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.

Thats with RC1, now im getting worried

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.

:thinking: 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.

Step 1: throw board against the wall …
But I think you’ll not be able to reload firmware ! :laughing: (Sorry !)

1 Like

Is this custom board?

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.

Yeah i know that, but im not talking about app running. There was no firmware on.

In this case, firmware is there and good. How do we know?

  • If no firmware then the device stay in Bootloader.
  • If firmware corrupted somehow, Bootloader check failed and also stay in Bootloader.

The device isn’t in bootloader, mean firmware is good. Something happen with application. You should erase application and redeploy again.

If you only erase firmware, it will clear some flag (disable app pin…) that you set before, cause another issue.

How do you know there is no firmware? Did Bootloader say that?

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 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.

(updating to rc2 now)

In your case, the App button will help. Hold it and hit reset. If you can ping TinyCLR then your application caused the issue. No need to Erase All.

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