💬 MySensors NRF5 Platform

[NeverDie]

Well, that's interesting. In the sketch I posted, I invoked sleep with:

  sleep(digitalPinToInterrupt(interruptPin), RISING, 3000);

which caused the mcu to wake up immediately after I press the button, but it didn't process the ISR.

Using an invocation like yours in the sketch you just posted above:

  sleep(3000);

the ISR executes and then terminates when I press the button, but the MCU doesn't wake and continue with the loop as it did with the prior incantation. Instead, it has to wait for the timer cycle to finish.

What I want is for it to wake up, do the ISR, and continue with the loop where it left off until it is explicitly put back to sleep again. How do I do that?

[d00616]

@NeverDie I have checked the sleep routine in all three variants. It's working with my setup.

There is no API stopping the sleep() by another ISR. Sleep only ends at one of the given conditions.

When you use the MY_CORE_ONLY define, please add "hwInit();" into the setup() routine.

[NeverDie]

@d00616 said in 💬 MySensors NRF5 Platform:

@NeverDie I have checked the sleep routine in all three variants. It's working with my setup.

There is no API stopping the sleep() by another ISR. Sleep only ends at one of the given conditions.

When you use the MY_CORE_ONLY define, please add "hwInit();" into the setup() routine.

Would you please post the three demo code examples that you tested?

[NeverDie]

@d00616 said in 💬 MySensors NRF5 Platform:

add "hwInit();" into the setup() routine.

OK, I just now did that, but I'm not getting any difference in the results.

[NeverDie]

In any case, I'm sure the question will ultimately turn from "How do I wake up based on a pin change?" to "How do I wake up based on the LPCOMP output, which has that pin as its input?" The reason: as covered earlier in this thread, much lower current consumption while sleeping if doing it via LPCOMP rather than the more straightforward pin monitoring.

[d00616]

@NeverDie said in 💬 MySensors NRF5 Platform:

In any case, I'm sure the question will ultimately turn from "How do I wake up based on a pin change?" to "How do I wake up based on the LPCOMP output, which has that pin as its input?" The reason: as covered earlier in this thread, much lower current consumption while sleeping if doing it via LPCOMP rather than the more straightforward pin monitoring.

It's a good question about, how to design the API to do this. I have no good idea.
Until an API, you can set MY_HW_RTC->CC[0] to (MY_HW_RTC->COUNTER+2). This ends sleep with some latency.

[NeverDie]

This post is deleted!

[NeverDie]

This post is deleted!

[NeverDie]

This post is deleted!

[NeverDie]

Is it just me, or does the myBoardNrf5 cause I2c to fail during initialization? I have code which worked fine on mNrf5Board but which now hangs during initialization when using myBoardNrf5. :( Is it working for anyone else?

[NeverDie]

@NeverDie said in 💬 MySensors NRF5 Platform:

Is it just me, or does the myBoardNrf5 cause I2c to fail during initialization? I have code which worked fine on mNrf5Board but which now hangs during initialization when using myBoardNrf5. :( Is it working for anyone else?

I've re-installed everything and am still getting no joy using I2C currently. The non-I2C stuff seems to be working fine though.
So, before I spin more cycles trying to figure it out, is i2c working for anyone else right now using the latest builds and myBoardNrf5? Or, is I2C currently broken?

[NeverDie]

It appears that the place where it hangs is this line here in Wire_nRF52.cpp:

  while(!_p_twim->EVENTS_LASTTX && !_p_twim->EVENTS_ERROR);

This is too bad, as I2C seemed to work fine prior to around a couple weeks ago. I think maybe (?) the latest update somehow broke it.

Please advise.

[NeverDie]

Well, since I'm dead in the water as things stand, I moved the code over to run on an nRF52 DK. Then, usingy Sandeep's code and none of the mysensors code, I was able to get the nRF52 DK to read an attached Si7021 temperature-humidity sensor. i.e. that worked without hanging.

So, it would appear that there's something about the mysensors code that is causing the problems. @d00616 Can we please get it fixed?

[d00616]

@NeverDie said in 💬 MySensors NRF5 Platform:

So, it would appear that there's something about the mysensors code that is causing the problems. @d00616 Can we please get it fixed?

I have no I2C Hardware for testing, but I take a look into the I2C and MySensors code soon.

[NeverDie]

The sooner the better. I'm pretty much stuck until it gets fixed.

[rmtucker]

@neverdie
I have been using The NRF5 with mysensors for a number of weeks with the si7021.
So it must be just a recent problem with the mysensors code?

[NeverDie]

@rmtucker said in 💬 MySensors NRF5 Platform:

@neverdie
I have been using The NRF5 with mysensors for a number of weeks with the si7021.
So it must be just a recent problem with the mysensors code?

I think so. Are you running the most current version? si7021 was working for me too on earlier versions. The latest update seems to have broken it. It's the one that uses myBoardNrf5 instead of myNrf5Board.

[NeverDie]

@rmtucker said in 💬 MySensors NRF5 Platform:

@neverdie
I have been using The NRF5 with mysensors for a number of weeks with the si7021.
So it must be just a recent problem with the mysensors code?

Would you mind trying the most recent version also to see if it breaks on you too? That would at least confirm it.

Right now my only alternative is to roll-back to the earlier version and just never upgrade again.

[rmtucker]

@neverdie
Where is myBoardNrf5 so i can check?

[NeverDie]

@rmtucker said in 💬 MySensors NRF5 Platform:

@neverdie
Where is myBoardNrf5 so i can check?

https://github.com/d00616/ArduinoHwNRF5