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?
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.
I appreciate you bringing this bug to our attention. In the power budgets of my projects, I’m constantly managing the quiescent draws of several components, and they can really add up quickly. I’m curious, in your tests were you able to observe the brown-out resets while in deep-sleep? I agree that it’s a fairly significant bug, especially for those projects focused on low-power operation.
I did not try to observe them. I was only deep-sleeping long enough to get stable current readings (on the order of 10 seconds). Here is the exact text from the errata document:
Under certain conditions and setup, the SIMOBUCK mode of voltage regulation may lock up and fail to
regulate both the VDDC and VDDF power domains. The voltage domains will degrade to low voltage and
cause a brown out event to occur.
The terms "certain conditions and setup" are pretty vague, but they must be broad enough that there is no more specific workaround for the A1 than to leave part of the ASIC powered so that it can't ever drop into a true deep sleep.
The only solution for this bug is B0 silicon. However, you could still design in an Artemis and prototype with an A1 as long as you know that a B0 will be available when you need it. That’s why I am asking about a Sparkfun upgrade plan.
robin_hodgson:
The only solution for this bug is B0 silicon. However, you could still design in an Artemis and prototype with an A1 as long as you know that a B0 will be available when you need it. That’s why I am asking about a Sparkfun upgrade plan.
Does anyone know if SparkFun is yet to ship B0 silicon? I am ready to order a small batch of Nanos, but definitely want to avoid the deep sleep issue. Thanks.
I have been asking since October. I have sent multiple requests for information via official channels to the moderators of this forum, and have asked the same question on the product website. My most recent request last week is still sitting in my outbox, meaning that they haven’t even read it. I think they are getting tired of me asking the same question.
For complete transparency, I did get one response saying that the Sparkfun boards have switched over to B0 silicon, but there was another comment on the sales part of the site stating that it was a running switch, which indicates to me that there is no clear way to know if you will get A1 or B0.
Regarding the ability to order modules with B0 silicon, it has just been a wall of silence. Given that this whole issue would go away instantly if the answer was ‘yes’, one would have to assume that the answer is “nope”. My theory is that Sparkfun has a ton of A1 modules on hand that they are worried about being stuck with so they are either actively ignoring the issue or pretending that it’s a non-issue. That’s a shame. The A1 is perfectly useful for a wide variety of applications, but not if your customers want to be the masters of the coin cell, as per your T-shirt.
Forgive me if I am sounding cranky, but the wall of silence has finally gotten to me. I even gave up and ordered a couple of mystery modules last week, just so I can practice the process to solder them down. Even if the soldering works, if the modules turn out to be A1 silicon, they will not be useful for my target application.
So do I wait and not buy anything now, or…do I buy and return and buy more and return until I get the right B0 silicon? (Basically doing a shift register through your inventory?)
I bought a couple of modules on Dec 2 2019 to test my soldering process. The good news is that the soldering test worked. The bad news is that the soldered modules report as A1 silicon:
Artemis RTOS Current Sensor Dec 21 2019 07:20:23
Processor revision: A1
Processor Freq: 48 MHz
Sparkfun: your customers include engineers who actually read data sheets and errata docs and do their best to understand the silicon implications before they design a new part into their own system. You want your moonshot. We want to be your customers. But a business needs to sell what the customers want if their goal is to make money from those customers. You have a set of customers who need B0 silicon, and a set who don’t, but those sets are not interchangeable. So sell the A1’s for $1 off and clear them out. They are perfectly usable for systems that don’t run on small batteries. Or sell B0’s for $1 more and let the coin cell crowd pay a premium. But whatever you do, don’t just stonewall your potential customers by acting like your logistics and stock management issues are more important than our system design issues. Why would a potential customer needing B0 silicon design in an Artemis if there is no way to actually buy B0 silicon? Don’t let your moonshot end up in the Atlantic ocean because you can’t/won’t manage a simple silicon revision change.
FWIW, I ordered 4 Nanos when they went on sale a couple weeks ago. I suspected they might have marked them down to move the A1 stock out, but figured I’d roll the dice anyway. Just tested them and they are all B0, so that’s cool. (Thanks to Nathan for posting the example script to check the Rev.)
I ordered direct from SparkFun btw, not Amazon, reseller, etc. YMMV.
That adds to the anecdotal evidence to indicate that Sparkfun has cut over to putting B0 modules on their own products that use the modules. But if you order plain modules, my experience is that they are still shipping A1 silicon. If anyone has received modules with B0 silicon, post a reply.
For what it is worth, I sent a snail mail letter to Nate (Mr. Sparkfun) in yesterday’s mail. I thought it might be worth a try given that the question is just being ignored in the forums and private messaging. Who knows, maybe I will get a response. But honestly, I can’t see why anyone considering the Artemis module for a low-power would design it in at this point if they have no way to order the silicon they need.
I just tested 2 modules from the latest batch of Artemis modules… they were B0s. However, we just started looking into the IC version issue. Depending on what we find out, we’ll either create a new SKU for the B0 version or add a notification to the product page that about what version users should expect to receive.