As a hint, a possible reason you’ve had this “lock up” is because your code does something that means the rest of the debugging system can’t get any processor cycles, so it looks unresponsive. While you’re testing this, you can do a few things to protect yourself from this - add a thread.sleep(5000) for example to give yourself 5 seconds before your process kicks in, or even better have your code wait for a button press before proceeding - either way you should have a sufficient break that you can erase your app without having to erase your firmware via DFU.
And as a hint on why RTC may be misbehaving, you did add the crystal and load caps didn’t you? the above link has a note on that as well.
@ Brett -
Thanks for the info. I could not get the DFU mode to work on my development PC so I went to an older .net 4.2 install and put Tinybooter_22.214.171.124 on it. Then went back to my development PC and updated the firmware. So it is now alive again.
Thanks for reminding me about the crystal. I was looking on the PCB for the pads for this. I forgot they were on IO lines. I had the same issue a couple years ago with the same problem.
I really wish GHI would fix these Methods. The SetDateTime function should not hang the entire platform if the hardware is missing (crystal and caps) it should throw an exception.