I’m trying to troubleshoot a project. I had everything working - an imp01, April, sensor tail, 2 adafruit 7 seg displays - on my breadboard. So I soldered up everything with a different (sparkfun this time) April to build the project.
At first, things didn’t seem to work at all, so I spent some time with my multimeter and convinced myself that I had the wiring right - power works, continuity tested connections, checked for shorts between pins, etc.
Next day, try again, and things are working. Perfectly. For about an hour. Then the displays stop updating.
The imp still works in my other April, and connects to the IDE and agent.
Here’s the weird thing - the device boots up, flashes green, and I can ping it. But it isn’t checking in with the IDE. This makes me think that the April could somehow be the culprit. I saw from another thread that this could be the case. I tried my second imp, it doesn’t work either and responds to ping as well.
Is it possible to find out if my MAC - c:2a:69:4:6d:e2 - is maybe giving some error in the cloud? I can’t really think of anything I can do except unsolder the April and try with my other one, which isn’t much fun. It would be nice to know that the component is actually bad and I’m not potentially ruining it for no reason.
Put your active model aside and write a new one … just a simple LED blink. That will test your April board and Imp. Knowing they both work perfectly with a simple test would allow you to dig into other parts of the project. But if it fails a simple test, you’ll know that too.
From what I can see, the device is booting blank code.
Note that your code is associated with the april, not the imp. Moving the imp to a new april will not magically move the code over - you need to assign the new april to the old model in the IDE for it to run the right code.
(I can see that it was running a different model up until 2015-06-06T16:52:28 UTC, but at that point it was changed to the blank one and has just been running that blank code ever since)
The distinction is there for good reason, though - you could damage hardware by running the wrong software against it. Such are the dangers of swappable processors…
@richlangston007, the best way to think of it is that the device is the important thing, and the imp is secondary: it’s simply a means to give the device WiFi, a processor to run your code and Flash to store the code. What you’re building is the device - a garage door opener, a Twitter ticker, whatever – and that’s what your focus should be. The fact that one of your device’s components - the key component, in fact - is removable and can be put in a different device doesn’t make that component more important than the whole project. This is why this component, the imp, always takes on the ‘personality’ of the device it’s fitted into, not the other way round. And, as Hugo says, it’s safer this way too.
PS. Of course, the separation between imp and device becomes much less when you’re manufacturing a product with a soldered-down module such as the imp002 and imp003. Only the imp001 card is transferrable.
I think of the IMP001 as a gateway. It does of course do more than just relay information from the device to the Internet, but by just considering it as a gateway it makes best sense in my head.
