SmittyHalibut/EleksTubeHAX

Compiles ok, crashes at Rtc.Begin

Closed this issue · 9 comments

Actually my clock (HARDWARE_SI_HAI_CLOCK) worked fine for a year, but the GEOLOCATION_API_KEY had worn out,
so I decided to start from scratch with this beautiful software. Had to do some updating in Arduino IDE, since it was all a bit dated.

Now I run into this problem. Clock crashes, reboots, crashes again, with the following ouput on the serial monitor:

Searching for CLK clock files... 4 fonts found.
.
Connected to WNAP10
IP address: 192.168.1.176
RTC was not actively running, starting now
Guru Meditation Error: Core 1 panic'ed (IllegalInstruction). Exception was unhandled.
Memory dump at 0x400d346c: 2502ad80 0000fff4 39004136
Core 1 register dump:
PC : 0x400d3472 PS : 0x00060c30 A0 : 0x800d34a2 A1 : 0x3ffb2210
A2 : 0x3ffc41a4 A3 : 0x3ffd4478 A4 : 0x3f401a3c A5 : 0x00000000
A6 : 0x00000000 A7 : 0x00000001 A8 : 0x800d3472 A9 : 0x3ffb21f0
A10 : 0x3ffc41a8 A11 : 0x00000080 A12 : 0x00000045 A13 : 0x00002d00
A14 : 0x00000010 A15 : 0x000a0000 SAR : 0x00000006 EXCCAUSE: 0x00000000
EXCVADDR: 0x00000000 LBEG : 0x40084ac5 LEND : 0x40084acd LCOUNT : 0x00000027

The exceptiod decoder gives me this:

Decoding stack results
0x400d346f: RtcBegin() at C:\Users\Frank\Documents\Arduino\libraries\Rtc_by_Makuna\src/RtcDS1302.h line 106
0x400d349f: Clock::begin(StoredConfig::Config::Clock*) at C:\Users\Frank\Documents\Arduino\EleksTubeHAX-main10mrt23\EleksTubeHAX/Clock.cpp line 72
0x400d3725: setup() at C:\Users\Frank\Documents\Arduino\EleksTubeHAX-main10mrt23\EleksTubeHAX/EleksTubeHAX.ino line 72
0x400df4b6: loopTask(void*) at C:\Users\Frank\AppData\Local\Arduino15\packages\esp32\hardware\esp32\2.0.7\cores\esp32\main.cpp line 42

I am using RTC by Makuna, version 2.3.5

Exception decoder points to here, line 106 in RtcDS1302.h

    void SetIsRunning(bool isRunning)
    {
        uint8_t ch = getReg(DS1302_REG_CH);
        if (isRunning)
        {
            ch &= ~_BV(DS1302_CH);
        }
        else
        {
            ch |= _BV(DS1302_CH);
        }
        setReg(DS1302_REG_CH, ch);
    }

Any ideas where to look for? Probably some silly configuration thing(s) playing up, but I have no clue where to look...

If I uncomment this Rtc.begin stuff, the clock starts further, but crashes on the GeoLocation stuff. But since I am used to tackle things top-down, I did not dive into that yet.

Thank you for your time!

Best wishes,
Frank

I am a bit worried about your second sentence, about Arduino IDE update. If you went from 1.8 to ver 2, this may cause quite a few weird things. Happened to me at one different project. I suggest you keep IDE ver 1.8 for this project and it should be okay.

Yes, good point, but I am at 1.8.19 - have not made the switch yet to 2.0 for the same concerns. I also am trying to compile it now in platformio, but have other problems there..
Getting this error, with platformio:

src/Clock.cpp: In function 'uint32_t RtcGet()':
src/Clock.cpp:39:28: error: cannot convert 'RtcDateTime' to 'uint32_t' {aka 'unsigned int'} in return
     return Rtc.GetDateTime(); 

But that seems to be that the returned value is a RtcDateTime - and when diving into that I also come to the conclusion my c++ knowlegde is not good enough. Not that it stops me, of cource.

Well, made some progress...

Back to the Arduino IDE, because my other attempt with Platformio gives me some other issues, not relevant here.

About the crash around RtCBegin in clock.ccp, line 9 I see this:
uint32_t RtcBegin() {

Changed that, because this function does not return anything, into:
void RtcBegin() {

That fixed the crash with RtcBegin.

The other crash I had with the GeoLocation stuff, I was also able to fix.
In IPGeolocation_AO.cpp, line 28:
bool IPGeolocation::updateStatus(IPGeo *I){

Function is supposed to return a true or false, which is the case in most fault situtations,
but not when succesful.
After line 148:
DEBUGPRINT(I->current_time);
I added:
return true;

Now, I know that usually if you don't do that, it is usually just not more than a compiler warning, but somehow with
my setup it seems that the compiler does adjust the stack if an expected return value is not given, and resulting in a crash.
I am not sure, just a wild guess here, Anyway, clock is running now, geostuff works also.

Cheers,
Frank

That's fantastic! I'm sorry I'm not following the changes super closely. Are those bugs in our code here, or in the libraries we depend upon?

If those changes are in EleksTubeHAX code, please submit a Pull Request so we can merge your change in to the main branch.

Thank you, just created that pull request.
I don't follow changes 24/7 either, but I just stumbled upon.

Perfect. PR looks good. Merged.

To be clear: does that resolve this issue? If so, please close it. If not, please document what's left.

Thank you again!! :-)

Yes, as far as I can see, this tackles it. Will close it 😉

Closed.