Search results for:

Thanks Gordon, that is a great fallback for now. So this will still work in the condition where getTime is returning the same value ?

Hi Sacha, Can you please generate the fault - using the bad power supply - and then run Gordons code, there may still be a software improvement that could be made

OK, will try that next time I catch one. The main problem is that in many weeks of operation, across several units I have only seen this definitely once (but probably once in the field), so it could take a while to appear again.

We are putting more units into the field in the next few weeks so hopefully this can be trapped before then.

It is a standard Pico running latest firmware as of a week ago.

I noticed my code had stopped from lack of activity on the LCD so hooked up right away to the IDE. I am not convinced that the clock stopped when I removed DC to the charger but it is possible.

I checked the error flags and nothing was set. Turning on the watchdog did not reboot. The Pico seemed responsive in all the normal ways apart from getTime returning the same value and hence no set interval functions being called.

I am 99.9% sure that setTime is what started it again. FYI I also use a Clock object and regularly set the Clock object time to what I get from the SIM800 module. (Can't remember if I create a new object or call setClock)

I do need to get a more accurate Pico clock running for the case where the GSM connection is down, do I need to add an external crystal to achieve that? Currently the clock runs about 10% fast.

But the most important thing is I need to detect and recover from the stopped clock as it is a 24x7 logging application and so cannot manually re power to fix.

I have just observed the clock stopping ie every call to getTime() returns the same number. This obviously causes my code to stop as all the setInterval code stops firing. Doing a setTime() started it again

My unit is battery powered and I think this happened after I removed the external DC power which feeds the battery charger - so there may have been some sort of voltage event that occurred.

We have another unit working in the field for several weeks and then stop - so I am thinking the same thing happened.

Any ideas what is going on ? How can I recover from this as setting the watchdog did not seem to help.

Just looking at it now I see that the 'send' function is waiting for the socks entry to be set from 'Wait' to either 'true' or 'undefined', the latter will then trigger the -1 return in the case of the error. So in theory without the throw this should be working - I will check that again

Yes I have already removed the exception throws but I thought that was not enough to get the error to come back through the network library - but maybe I should recheck that. I currently have my own callback in both the CIPSTART fail and CONNECT FAIL case - but then I dont know when the socket etc is freed.

I am making POST requests to a web server via SIM800. I have a req.on('error', function(e)) in place but I find that only catches one particular error (I cant remember the code right now)

However in the SIM900 code if either the CIPSTART command fails or there is a CONNECT FAIL, even though the SIM900 code was throwing an exception and setting the socket to undefined - the http request function does not generate an error. I assume there is no mechanism to ripple those errors back through.

So for now I have implemented my own callbacks from the SIM900 code to capture those errors so I can retry. But the question is, how do I ensure the existing http request is properly killed off so I dont leak memory from retries ? Or worse the request code ends up returning something (error or not) after I have already captured an error and begun a retry.

Great that there is a simpler example ! It only started showing for me when the code was more complex.

By the way I have been running 1v85.499 for the last week or two and the problem has not come back even though my code has changed a lot.

Thanks would be most appreciated. Let me know if i can supply any other debug info

Hey Gordon not sure if you have been getting my private messages but this is still a real problem for me. How do i progress on this?

Yes - deep sleep is set - will try that !

I have a little piezo I am turning on by
analogWrite(A5, 0.5, { freq: f } );

While I am debugging and connected to USB it works fine. When I disconnect USB and leave it to run on battery it sounds but does a funny chirp - I assume the PWM is getting messed up somehow.

I dont have a scope to check what is going on - any ideas ? Anything to do with A5 ?

Yes it is running the latest firmware. I will message you some code

Actually not that as now a different part is getting corrupted - this is in the flip function for the ST7565 module. It was working fine earlier today

Uncaught Error: Function "wtite" not found!
 at line 2 col 37
...)b.write([176|a,0,16],f),b.wtite(new Uint8Array(this.buffer,...
                              ^
in function "flip" called from line 348 col 10
  g.flip();
         ^
in function called from system
Uncaught Error: Function "wtite" not found!
 at line 2 col 37
...)b.write([176|a,0,16],f),b.wtite(new Uint8Array(this.buffer,...

Yes - that is what I would expect ! That is not in my code though - it is in module code and getting corrupted somehow.

It seemed to be the way my LCD update function was being called. It was being called by various async events throughout the system. When I changed to a single interval checking a flag for LCD updates it has come right.

I dont understand how that was the problem as I thought this was all single threaded ?

My code was working fine, came back 3 hours later made a small change and getting this error - same error if I go back to my original code.

WARNING: Expecting a number or something iterable, got undefined
Uncaught ReferenceError: "Uint8Arsay" is not defined
 at line 2 col 47
...176|a,0,16],f),b.write(new Uint8Arsay(this.buffer,g*a,g));c....
                              ^
in function "flip" called from line 347 col 10
  g.flip()

What is causing something like a type to get corrupted ?

Great - thanks for that, a helpful starting point.

I am wanting to update code over GSM. I have seen a few discussions on this but they are a little old. Is there a working example of this for the Pico? I assume the extra flash page could hold the code that it's always run on boot? Any pointers welcomed.

Yes I was having a look at those type of cells last night. In my application the sensor/pico/nrf are going to be located inside a fridge and at those temperatures the voltage drops to around 3.2V, so I would probably need to use a couple of smaller cells. The DS18b20 have a min of 3V and the NRF a max of 3.6V hence probably need to use the regulator, unless I protected the NRF at room temperature.

But in principle these look like the right kind of battery to be using.

Good point re 18650, I had not considered the self discharge rate so will cross them off the list !

I have a similar application where I was looking at using a Pico as a remote temperature node. It needs to wake up every 30s, take a measurement from 2x DS18b20 temp sensors then transmit the values using a nrf2401. I was looking to run it off a single 18650 battery - but my theoretical calcs say it wont last the 18months I would like it too.

I am making the assumption that the full Pico run current is used while waiting for the DS18b20 to convert and return - or is that not the case ?

Gordon - I saw in another post you mentioned it could be possible to slow the STM clock to save power in run mode - is that something that is implemented/quantified as to the savings ?

I know I should probably also do some practical measurements here, but dont want to spend that time if this is never going to fly.

I have found another little Arduino board setup for this kind of thing which has a 5mA run current - but would prefer to use a Pico as the other half of the project is also Pico based.

@Ducky. Did you manage to get this driver up and running ? I am getting some LCDs shortly which use the same ST7567 controller - although they will be 128x64 displays

This is the one I am going to get some samples of
http://jlxlcd.cn/china/productshow.asp?nClass=97&PClass=0&ID=319

It uses the ST7567 driver which I see someone else on the forum may have already got running ? The ST7567 also seems to require fewer components around it to work which is a bonus.

Where would I send one to you ?

From China already mounted on a PCB with the same driver for USD4.16

http://www.aliexpress.com/store/product/12864G-573-PN-128-64-LCD-modules-wide-temperature-range/1798337_32339942088.html

Could be interesting to try out if you could help out with the driver ?