Search results for:

Thanks for fixing :)

Hi

I recently had a strange issue with 1v62 - I'd got everything all setup to do some logging, and I left it running overnight. When I came back it had just stopped - USB disconnected, nothing happening.

I removed hardware and tried to cut back. I added a LED flasher interval - it still crashed after a while. When it crashed, the LED stopped.

Thoughts - I might have tripped the thermal fuse? I did have quite a lot of stuff hanging off it - but I removed quite a bit and it still crashed.

Just wondering about possible causes of a complete lock, and maybe ways to debug?

(Obviously I'll try 1V63 - but I'm also going to add a separate 3.3v regulator and tidy all the wires...)

Thanks

Martin

Wow - great set of additions - excellent work :)

Glad to hear it's looking good :) Been busy at work recently...

@Gordon, @Pat

After a big of slogging, I think I may have fixed Wiznet. (OK, a bit optimistic, but it looks more reliable now in my testing :)

I found three bugs

1. The HTTP code was using srcport and dstport both with the same value, which I think caused GETs to fail when they overlapped.

2. The DNS code wasn't releasing a socket, which caused "no free sockets" after 8 DNS queries.

3. The socket code wasn't clearing the nonblock status, which caused odd things to happen if a socket was reused.

I've submitted a pull request - hopefully Gordon can review and include these fixes in a future build - assuming I've not got anything wrong!

Martin

Pat

OK, my understanding

The timeout error happens because the WebIDE gets annoyed that Espruino is busy, and sends a ctrl-c, which breaks Espurino out of comms and causes the error. Ideally Gordon should give us a webide option to delay the ctrl-c

The Wiznet subsystem (i.e. wiznet+espruino) has at least two known problems: the -7 error and the out of sockets error. The -7 error means "socket has wrong state" - internally we're trying to do something on a socket that is closed. I don't yet know why.

Gordon has said that if you delay between GETS you don't run out of sockets, but I've not seen this - if I do repeated POSTS with a 2-minute delay I still run out after 8 POSTS.

When I have time, I'm still digging into this - I've got Espruino building and I've added logging to the code, but I've not quite got to the point where it's telling me anything useful...

Martin

Thanks for beating me to it :)

Ah - I guess I assumed it was their issue because they were looking at it - my misake!

@Gordon

Sorry if I misrepresented you - I was trying to save you typing time, but it clearly didn't work :(

If Wiznet get there first, great - if not, I'll make a test program to explore the repeated POST issue in more detail.

Martin

Thanks.

Hi @pat

I've been discussing separately with @Gordon - we can see that something isn't closing sockets. @Gordon believes this is a bug in Wiznet's code, and he's asked them to check it out - I suspect it's more on the Espruino side. I've been studing the network code over the weekend, and I have some theories, but I'm generally very busy.

My current experience is that it doesn't let go of sockets even if I give it a couple of minutes. @Gordon has suggested this may depend on the server I'm talking to

My code is a bit long and cluttered with other stuff. I'll try to get a smaller test program to show the problem more specifically and upload that soon. @Gordon has also suggested a few other things to try.

Thanks :)

Not for me :(

But your example is different to mine - you're creating one server socket and responding to events. I'm creating multiple sockets, and the problem is that they never get closed.

I'd expect your case to work, I think.

Perhaps we could have a parameter in Web IDE configuration to turn this off or change the delay?

(See my separate post on similar error messages in I2C)

DrAzzy

My problem was even simpler, just writing this in the IDE window:

while(true)
{

 I2C1.writeTo(0x26,1);

}

failed if the I2C was disconnected - the program stops with something that looks like a syntax error.

This isn't right, IMHO - a runtime communications failure should return an error code, not a system-stop!

Hi

I've been experimenting with Wiznet and I2C, and I've been caught out a couple of times by the lack of exception handling.

For example, with I2C, if there's something wrong it seems Espruino shows a "Timeout" error and the program aborts. I wanted to write a loop writing to the bus, so I could put a scope on it - and I don't seem to be able to do this at all, because the error is too fatal.

Anyone else have this problem? Right now I don't particularly want a full exception implementation - just something that allows transient errors to be non-fatal.

Thanks

Martin

Hi

I've been attaching my Espruino board to my existing I2C busses which have previously been tested with Arduino and other devices.

One interesting question is bus voltage: the I2C devices I'm using are on PCBs that require a 5V power supply. In the past, I've connected up a 3.3v Arduino - I just used pullups to 3.3v instead of 5v, and this worked. But it didn't work work with Espruino.

Then I realized that the Espruino pins used for I2C are 5V tolerant, so I've changed the pullup to connect to 5v - and it seems to work now :)

However, I am using 2k7 pullups, which I suspect may be a bit too low. I think the general advice is 4k7 to 10k?

Thoughts?

Update - it's better, but still a bit patchy. I'm still getting the socket -7 error. I also still get "no free sockets" but I was doing HTTP requests more quickly than every minute. The Internal SPI error I still see, but generally only get when sending a new program to the device after a socket error - in this case, it just loops showing this error

@Gordon

I've installed 1v63 from latest commit. Wiznet now works better, although I still got the following once:

INTERNAL ERROR: Timeout on SPI TX
INTERNAL ERROR: Timeout on SPI RX
INTERNAL ERROR: Timeout on SPI TX
INTERNAL ERROR: Timeout on SPI TX
INTERNAL ERROR: Timeout on SPI RX
INTERNAL ERROR: Timeout on SPI TX
INTERNAL ERROR: Timeout on SPI TX
INTERNAL ERROR: Timeout on SPI RX
INTERNAL ERROR: Timeout on SPI TX
INTERNAL ERROR: Timeout on SPI TX
INTERNAL ERROR: Timeout on SPI RX
INTERNAL ERROR: Timeout on SPI TX
INTERNAL ERROR: Timeout on SPI TX
INTERNAL ERROR: Timeout on SPI RX
at line 29 col 13
req.end(body);
             ^
in function "sendGrove" called from line 1 col 11
=undefined
=undefined
ERROR: Socket error -7 while sending
Callback
->{"message":"exception.LabradorException: Feed PUT call limit has been exceeded for address 77.100.6.154. One cal
->l every 10 seconds is allowed. ","errCode":"RATE_LIMIT_EXCEEDED","success":false}

I'm pleased to say that even after this, further GETs worked.

I can't quite give it a complete 100% bill of health, but it feels a lot better

Martin

@graf - OK !

@graf - you can if you have ethernet, because you can get the time from the internet on device startup. The combination of extra clock crystal and my date module seems to work for me :)

Also check this - currentmillis.com/api/millis-since-unix-epoch.php

If you have ethernet, you can use this to get the time without requiring NTP

I've also found an online web page which has the current date on it here - http://currentmillis.com/api/millis-since-unix-epoch.php - I'm using this with the Wiznet Ethernet adaptor to set the time.

I already tried the capacitor, but my electronics isn't quite good enough - it didn't help. Anyway, I don't actually need to solve the problem - I was just documenting it for others

Thanks for the help.

Ah, I can rename some files :)

Thanks :) Flow control overlaps with the 'dropped character' issue discussed elsewhere which I think is relatively significant. A faster web-IDE would be nice, but to me is much lower priority.