• I noticd the save(); at the end of the code. Give it a try without that.

    During development - until my code is settled - I use this

    setTimeout(onInit,999); // while dev'g - remove before upload for save()
    

    Using this timeout let's the upload 'thread' complete and then start as if it would be a power-on w/ saved code. At the same time it makes my development life cycles easy, because I do not need to type onInit(); into the console after every upload to get the code (ball) rolling, nor do I save 'half baked' / dynamic states.

    When I'm done w/ developing, I remove or comment this line, make an upload, and then enter save() in the console. That way I do not save any intermediate, not recoverable states, and also do not start things twice... because that could be some of your issues that you have races going on.

    Upload of code to Espruino is different from uploading code to Arduino or a-like. Yes, @Gordon catered for that mode too, but that is using switches in the ide... Having save() in the code (at the end of it) is for sure calling for trouble, because Espruino is not designed for that.

    Regarding the pull-up resistors: if they are fixed - external - you cannot control them with software. To achieve absolute low power use the pins need to be re-configured to not cause any load - current flow - on the pins. Could you measure what is going on in regard to current sourcing/sinking by (all) your pins? And since you are an electronic engineer I assume you already took of potential noise creation states that would last over extended time periods.

    PS: May need to make myself a bit more familiar w/ your code to see what it going on and what the used coding pattern mean compared to the patterns more familiar to me in Espruino context.

  • Thank @allObjects for the explanation regarding the save() command, it's very interesting. I will remove it from my code and enter it manually as you suggest.

    To achieve absolute low power use the pins need to be re-configured to not cause any load - current flow - on the pins. Could you measure what is going on in regard to current sourcing/sinking by (all) your pins?

    Thanks for the suggestion, however as I tried to show with the clearWatch() command, the problem must be located in the code (or in the way Espruino handles low-power mode on the NRF52832) and not in the hardware. Since entering the clearWatch() instruction doesn't change any pin configuration, the issue must be elsewhere.

    As I'm reading this, at normal operation, 100uA is observed and during a BLE event, 1mA is consumed. Where, when is the 7mA drain observed as this value is far in excess of normal operation? Are the readings before or after the LDO? What are the values of the pullups?

    The 7 mA drain is observed when the setWatch() are "active". If I clear them, the current decreases to 100 uA. This current is measured with a multimeter directly from the laboratory voltage source, which is at 6V to simulate two 3V batteries in serie. I will post the schematic tomorrow.

    Do you get the high power draw if you upload just the setWatch commands, or what if you make the functions they call empty?

    I will try tomorrow.

    Thanks guys for your inputs :-)

About

Avatar for allObjects @allObjects started