RTC on CerbuinoBee

I am trying to use the RTC on my CerbuinoBee with .net 4.3

I used sample code provided but it crashes on the funciton RealTimeClock.SetDateTime(DT);

After crashing the cerbuino is bricked until I erase the code using the firmware updater.

I have attached a battery to the RTC suuply pins.

Can anyone help explain what would cause this?

Well, now I can not even erase the program so its seems to be completely bricked. Does anyone one a way to erase the firmware? Can I use DFU mode somehow?

Hi,

yes, you need to boot into DFU mode and reapply the firmware. [url]https://www.ghielectronics.com/docs/46/fez-cerb-family-developers-guide[/url] has the steps listed for you.

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

I don’t know whether the actual problem you’re seeing is the processor locking up, not just netmf. That isn’t something GHI could fix, or something netmf could handle gracefully…