Duinomite to low power mode

[KeesZagers]

Hello Johnny,

I think you did not quite understand me concerning the PAUSES. When the processor comes out of sleep, the video interrupt routine is started again and it lasts about one second to synchronise again with the monitor. If the loop directly continues the interrupt is disabled again. I don't know what is happening with the synchronisation process, but I do know that without the pause the screen will not come back. That is why I included the PAUSE 5000. Also the PAUSE 1000 makes sense, because it is possible that not all previous I/O commands are finished before the SLEEP starts. So the PAUSES are not a replacement of the SLEEP, just some protection.

If you don't need the VGA monitor in the real process, you can also disable that by OPTION VIDEO OFF. However for the moment I think it is good to see on the monitor that the system comes out of the SLEEP.

I did the test with my Duinomite with writing to a logfile a number which increments after every sleep. A number of minute timeouts and also stops by the keyboard and the USER switch and with the OPTION USB OFF it was incremented up to 100 without problems. Also with the monitor coming back everytime.

Kees

[KeesZagers]

Hello Johnny,

Some additional information. I succeeded now in reproducing your problem with the original firmware on one of my Duinomite MEGA's. Used SLEEP SECOND and after that mostly within one minute it does not come out of the sleep. However with another unit running my modified code I cannot reproduce it. As far as I can see now I just included some millisecond delays directly after the sleep and the new initialisation of the SD card. I have seen anyway that the orignal code has a bug concerning the SD card. It will never come back if no drive B is found. I will change that also. However for the time being I like to finish my own project first. After that I will see if I can make the essential changes also available in the original DMBasic 2.7. So I hope you still have some patience.

Kees

[johnny]

Hallo Kees,

We are on page 2 already... I also did some testing today, confirming you latest findings :

This program did run the whole afternoon, no problems :

10 REM pin 1 tot 3 analog inputs
20 OPTION USB OFF
30 OPTION VIDEO OFF
40 SETPIN 1,1
50 SETPIN 2,1
60 SETPIN 3,1
70 SETPIN 4,1
130 PIN(0) = 1
140 PAUSE 1000
150 PIN(0) = 0
155 PAUSE 1000
170 SLEEP MINUTE
180 PAUSE 5000
190 GOTO 40

Then I added what I need :

10 REM pin 1 tot 3 analog inputs
20 OPTION USB OFF
30 OPTION VIDEO OFF
40 SETPIN 1,1
50 SETPIN 2,1
60 SETPIN 3,1
70 SETPIN 4,1
80 F$ = "B:"+RIGHT$(DATE$,7)
90 OPEN F$ FOR APPEND AS #1
100 V$ = DATE$
110 PRINT #1,V$,TIME$,MM.SLEEP,PIN(21),PIN(1),PIN(2),PIN(3),PIN(4)
120 CLOSE #1
130 PIN(0) = 1
140 PAUSE 1000
150 PIN(0) = 0
155 PAUSE 1000
170 SLEEP MINUTE
180 PAUSE 5000
190 GOTO 40

and this one does not run long, so indeed, writing on the card does case a issue. I'm writing on drive b and power it on by a USB power supply.

Just to find a quick (and dirty) solution, can I reboot the board from in software, for me it would be fine if I log the data, sleep a minute and reboot. The reboot command seems not well documented or even hidden :-)

Many thanks for your time and information, it does make a difference.
Johnny

[KeesZagers]

"Quick and dirty (operating system)" made Bill Gates very rich, so let us give it a try :-)

Indeed there is no REBOOT command in DMBasic. After the initialisation of the system the system comes in an endless loop. The only exit of this is doing something wrong like PEEK or POKE to an address which is not allowed. This will reboot the system, however in a predefined state (error message with the PEEK or POKE question) and unfortunately it does not start the "AUTORUN.BAS". So the very Q&D method does not work.

However I think there is simple Q&D method which should work, at least it should re-init the SD card in a correct way. You should give your filename another name as "AUTORUN.BAS", e.g "DATALOG.BAS". Now change line 190 RUN "DATALOG.BAS". This will stop the program execution and load and run the same program again. To start the system automatically add "AUTORUN.BAS" with just one line: 10 RUN "DATALOG.BAS".

I have not tested this with the original DMBasic 2.7, but I guess it should work.

Kees

[KeesZagers]

A few more suggestions:

You can add:
21 POKE &HBF88,&H5080,0
22 POKE &HBF88,&H5210,158
These two lines will switch off the USB Power and Interrupts. You will hear the correct disconnection beep on your PC. Now you have to disconnect your terminal. If you include some END condition in your program and you would like to connect again, you need to execute the following statements:
1000 POKE &HBF88,&H5080,9
1010 POKE &HBF88,&H5210,159
1020 OPTION USB ON
Now you can connect to the Duinomite again without resetting.

Concerning the power consumption.

1. As far as I have seen now, it is best to set all IO to digital input before you start the sleep: FOR x=1 to 22:SETPIN x,2:NEXT. As long as the analog circuit is active or outputs are configured they can draw extra current.

2. Olimex seems to have not designed with low power in mind. There is no possibility to switch the Power LED off. In my MEGA it is even connected via a resistor of 330 ohm to the 5 Volt. This means about 10 mA. In the other Duinomites it is 1k, but this still means 3 mA for the power LED. Maybe it is an option to disconnect.

Kees

[johnny]

Hallo Kees,

A short update, the call from one program to a other with the

10 RUN "DATALOG.BAS"

in autorun.bas and at the end of datalog.bas does not make the sleep stable, it still stops after a while, so it did not solve the issue.
Cheers,
Johnny

[KeesZagers]

Hello Johnny,

It is a pity, but like I said it is not a real reboot.

I have noticed it is a quite complex issue. The original implementor of the SLEEP command also tried to wake up from the serial ports and did not succeed in that. I'm still fighting with that and with the wake up from the CANports. I'm also studying what is really done by calling the SLEEP routine. The implementor just called a routine from a standard Microchip library, but my experience with the CAN library is: debug these libraries before you use them; Microchip did not do this for you.

Kees

[KeesZagers]

A short update for further testing.

I checked what happens if the Duinomite does a softreset (like with x=PEEK(0,0)). At the startup it simply checks the PIC32 RESET register and if the bit for "softreset" is set, it sets "autorun=false" in stead of "autorun=true" like in a cold start. Just for testing I changed this to always "autorun=true". Now the autorun file is always executed also when you make a mistake in your program. This is very tricky as you can imagine. That is why you should have an autorun file which gives you the possibility to stop after reboot. I did some small test and up to now did not detect problems.

In www.si-kwadraat.nl/olimex/sl_test/sl_test.zip I have included 3 files. The HEX file with the new image which can be installed by using the standard firmware program of Olimex, a possible autorun file and the program as was intended to run at your site. I know you will have the problem that with the reset also the real time clock is reset, so you have to calculate the new time from the last measurement.

I hope you are willing to test this and I can use the results also for my further developments.

Kees

[KeesZagers]

I don't know if Johnny or anyone else tested the modified code, but I think we are looking in the wrong direction. I still see the problem; after some time the unit does not reboot after the sleep. Actually I believe it is not really coming out of the sleep (although the current goes back to 120 mA). I did some googling and it seems that more Microchip PIC32 users have problems with the sleep option. Probable causes for the problems are always related to the power supply or to spikes on the I/O. I will do further investigations in this direction.

Kees

[johnny]

Hallo Kees,

I was out for some time, I will check your code at the end of this week.

Many thanks for your help,

Johnny

[johnny]

Hihi,

I did download the firmware to the board, autorun.bas and the logging code, and the device is running now for about 4 hours.

Current goes down to just under the 10mA when at sleep.

More tests to be done, but for now, it looks like the restart in the new code does the job, thanks !

Cheers,
Johnny

[KeesZagers]

That is good news. I believe that my last problem was caused by the fact that I wanted to do the test too fast. If you do a reboot before the SPI connection to the SD-card has been stabilized, you probably run into problems. I have another issue here. For a project I needed some extra digital inputs and I wanted to use PIN 7 up to 10 for this purpose. After SDDISABLE this is no problem. If I want to use the SD card again this can be done by SDENABLE. As long as I don't change the configuration of the PINs this works perfectly, but if I changed the PINs to inputs the SD card is not recognised again. If I first do SETPIN 8,8 and SETPIN 10,8 and after that PIN(=0 and PIN(10)=0 and after that SDENABLE, it works again. I don't know why, because it seems that this is also done in the SDENABLE command. It has probably something to do with timing. SD card will stay a critical issue at the Duinomites I believe.

Kees

[johnny]

Morning Kees,

I did let the code run overnight and after 395 minutes (= 395 entrys in the log), it did stop logging. At the moment I checked, the unit was not in sleep (checked at the power consumption). A reset did start it again and went into sleep, no idea why it did stop...

Cheers,
Johnny

[KeesZagers]

A few additional suggestions:

1. Take care of a very good supply. I have seen that the Duinomite does not boot with every USB adapter, because it supplies a voltage of over 5 Volts. Best is to use an adapter from 9 to 24 Volt. But as I understood you will use a battery anyway.

2. I found a better way to do a real reset. The built-in watchdog of the PIC32 controller is disabled in the DMBasic. The instruction POKE &HBF80,&H0001,128 will switch it on with a default time of 1 ms. So as soon as the instruction is seen, it will activated. This is not a soft reset as far as I know, but has the same function as pressing the RESET button.

3. To further reduce the current I would suggest to cut one of the connections to the power LED. On the Duinomite it draws about 3 mA of the 5 Volt (3 Volt over 1 kOhm).

Kees

[johnny]

Good morning,

Ok, good news today, my setup did run for 24h, first time since the start on this topic :-)

A summary :

"Sleep" command does cause problems and is not stable. The work around for now is to do download the new firmware Kees made, sleep and then reboot the device, a working way to reboot is :

190 POKE &HBF80,&H0001,128

In short :
autorun.bas :
10 PIN(0)=1
20 PAUSE 2000
30 IF PIN(0)=1 THEN GOTO 60
40 PIN(0)=0
50 RUN "log.bas"
60 REM Here comes evaluation software

log.bas :
10 REM pin 1 tot 3 analog inputs
20 PRINT "starting routing"
30 PIN(0)=1
35 PAUSE 100
40 SETPIN 1,1
50 SETPIN 2,1
60 SETPIN 3,1
70 SETPIN 4,1
80 F$ = "B:"+RIGHT$(DATE$,7)
90 OPEN F$ FOR APPEND AS #1
100 V$ = DATE$
105 NO=NO+1
110 PRINT #1,NO,V$,TIME$,MM.SLEEP,PIN(21),PIN(1),PIN(2),PIN(3),PIN(4)
120 CLOSE #1
125 PIN(0)=0
130 PAUSE 1000
140 POKE &HBF88,&h508,0
150 POKE &HBF88,&H5210,158
170 SLEEP MINUTE
180 PAUSE 1000
185 PRINT "resetting"
190 POKE &HBF80,&H0001,128

It consumes about 80mA when writing, about 9mA when at sleep.

For my project, I still have some open topics :

- I'm still wondering how I could include a correct timestamp, if the duinomite is without power for some time, I may not have this in the log file. A external RTC seems overkill, so it does make since to get the sleep command stable..

- I did take out the resistor for power on red LED, but still it consumes 9mA, a lot more then what is in the manual for this board(30uA, page 5 of the manual, a big difference for battery powered applications),.

Many thanks to Kees for his work on this topic.