SparkFun Forums 

Where electronics enthusiasts find answers.

What are we doing right with Artemis? What are we doing wrong? Let us know here!
#208325
I was reading the chip errata document and like any chip, there are bugs. A fair number of the bugs are resolved with "fixed in revision B0". I checked the revision of the chip on my board using the contents of the MCUCTRL register CHIPREV (address 0x4002000C). It indicates that the chip on my Artemis is a revision A1.

That made me a bit sad since there are some pretty annoying bugs in the pre-B silicon. One issue is Errata 019 where the buck power converter can malfunction in deep sleep mode causing a brown out reset. The workaround is to never let the part go into deep sleep. This is accomplished in the HAL software library by turning on the PDM peripheral. It is the peripheral that uses the least power, but having it turned on prevents buck converter bug from manifesting itself. The downside is that instead of the advertised 2 uA deep sleep, the best that a real system can do will apparently require 20-30 uA, or an order of magnitude worse.

So a question for the Sparkfun people: Assuming that B0 silicon is actually available, when do you plan on using more recent silicon on your modules? What will the process be for upgrading your modules? Will there be an announcement or a part number change?
#208381
To determine the impact of the deepsleep brownout bug in the A1 processor, I made a deepsleep configuration testing program today. The program is designed to continuously alternate between two different chip setup modes in subsequent 8 second deep-sleep iterations, where the 8 seconds allows the current meter to settle. The point was to create a very well controlled environment where it would be clear how the test configuration changes could affect power consumption in the two sleep cycles. The first test I did was to power the PDM for one sleep cycle, and then for the second, leave it turned off, with that being the only change. The program showed that with the PDM off, the processor could deepsleep at 2.4 uA. With the PDM on (as required to avoid triggering the bug), deepsleep went up to 38.0 uA. So it's a significant bug for projects that really need the lowest power.