Blackfin DSP Bugs

[marknorton]

Regular readers will know that the M8 uses a Blackfin Digital Signal Processor made by US company, Analog Devices, Type ADSP-BF561.

To give you an idea of what it's like working with this beast, here is a list of the 97 bugs which have been found in the chip, "Silicon Anomalies" as they like to call them and the recommended workarounds. The chip revision level on the camera I dismantled is 0.3. so the entire list of bugs on pages 2 - 4 of this document applies to the processor used in early M8s. There's a cleaner version of the chip, revision level 0.5 but even it has some unresolved bugs.

They euphemistically refer to "Infinite Stalls" which to you and me are battery out lock-ups.

http://www.analog.com/UploadedFiles/...sp-bf561&la=en


DSC_0007-2.jpg

[mhoutman]

mark, please tell what you are trying to say

michiel

[stunsworth]

If you're waiting for bug free software you've got a long wait to look forward to.

[gabriel]

It would be interesting to know how many of the workarounds have been applied by Leica in the firmware updates that have been issued to date.It is good to see that issues are being recognised by the chip manufacturer and corrections being issued, but how serious is Leica in applying the relavent ones

[arthury]

Originally Posted by stunsworth

If you're waiting for bug free software you've got a long wait to look forward to.

uh ... eh ... it's hardware.
And, you would expect the hardware guys to be less like the software guys.

[marknorton]

Sorry, I realise this is not of much interest to many (maybe just a passing interest to a few) but it highlights that the role of the firmware programmer is not just to program the function and algorithms required but to do so in a way which avoids the hardware bugs which are present in every M8 out there - and will be forever - by consistently using the workarounds suggested by Analog Devices.

So while it's easy to blame Leica's firmware when your M8 freezes, it might also be down to bugs in the chips they use.

[marknorton]

Originally Posted by stunsworth

If you're waiting for bug free software you've got a long wait to look forward to.

Steve, these are hardware bugs, not software bugs. There are errors in the chip design - the silicon - and it's akin to trying to use a calculator which sometimes gives the wrong answer. Remember the Intel Floating Point Problem?

[stunsworth]

Originally Posted by arthury

uh ... eh ... it's hardware.

Yeah I know, I was wondering if it worked under program control rather than being hardwired.

[diogenis]

So, this is what happens with endless integration, against using discrete components. I wanted to reply in your other thread, to him that raised the question of whether M8 is state of the art or not... That's what you get from endless competition for better, smaller and faster chips...
Silicon anomalies... LOL
At least there is hope: now they know what is wrong, the will try to avoid the problems circumventing it, and then maybe issue some sort of upgrade to replace the whole chip

[Peter D Lux 2]

Mark,

Very interesting information, thanks.

Originally Posted by marknorton

... the hardware bugs which are present in every M8 out there - and will be forever - ...

Are you saying it's difficult, impossible or too expensive to put in another chip, as part of a camera upgrade for instance?

[adan]

Hmm - I read Steve's original post as meaning "if it's a HARDWARE issue, you may wait a long time for a SOFTWARE solution to the problem." Which seems accurate.

If an engine has a broken piston rod, rewriting the instruction manual won't make it run better.

Remind me, Mark - was the M8 you dissected one of the REALLY original, banding, mirroring M8s? I'm just wondering if replacing/upgrading this chip was part of that fix.

[marknorton]

What you cannot see is that under the chip are 297 connections - tiny balls on the bottom of the chip bedded into an array of pads and soldered in place by hot air when the board was made. Impossible to remove the chip without wrecking the board. If any component on the board fails (not sure about the battery or SD card holder), my guess is it's a new board.

That DSP must be expensive, right? Not so. Buy 1000 of them (a months M8 production or so) and AD will sell them to you for around $27 a piece.

Andy, the M8 I took apart was pre-fixed and it looked like the whole recall was down to replacing two chip components by hand on the back of the sensor board.

With a population of M8s out there with the 0.3 chip, any firmware has to run on the oldest chip and so cannot take advantage of fixes to the Blackfin in the meantime.

[dpattinson]

Originally Posted by marknorton

With a population of M8s out there with the 0.3 chip, any firmware has to run on the oldest chip and so cannot take advantage of fixes to the Blackfin in the meantime.

I know nothing about firmware programming - is it not possible to query the version of the chip and have conditional behavior in the firmware?

[marknorton]

Good point, the program can find out the revision of the processor it's running on and, in theory, you could code one version for the old and one for the new. In practice, that doubles the testing load and I expect Leica want one size fits all.

If in the future they produce a revised DSP board, they could update the firmware for it making the assumption that every instance of the board out where will be at a later revision level.

[dalippe]

Mark,

Thanks for the information! You certainly provide a wealth of useful and interesting facts.

This could well be the explanation for the vast majority of cases requiring battery ejecting/reinsertion. I am (was?) about to send my M8 to Solms to have them try to fix this, but if this is indeed the cause, then the only thing Solms could do to repair my specific camera would be to replace the circuit board with one using the newer chip. According to your link it does not suffer either of the infinite stall problems. But I have no way of knowing if they will do that. And given past experience I can't imagine that I'll be able to find anyone to tell me. To send or not to send, that is the question!

David

[stunsworth]

Originally Posted by diogenis

So, this is what happens with endless integration, against using discrete components

There's a thought. How big would an M8 be if it used valves rather than chips?

[guy]

Originally Posted by stunsworth

There's a thought. How big would an M8 be if it used valves rather than chips?

At least it would heat your house!

[diogenis]

Originally Posted by stunsworth

There's a thought. How big would an M8 be if it used valves rather than chips?

Well at least, M8 is modular in design and can perpetually upgraded. If something like this ever happened to a model of our beloved Japanese, we should simply wait for their next model (not that it don't happen that is...)

Only good thing of all this is, that at least the problem is known and they should work for fixing it.

Stun, integration is nice but it also has its cons. Miniaturization, simplicity and all, but do some QC...

[scott kirkpatrick]

Mark, thanks for finding this. I also noticed an anomaly that looks like it may underly the recent strong suggestion that one wait 3 seconds before pressing "yes, go ahead" during a firmware upgrade. I haven't made a study of this sort of thing, but I take it as fairly normal. Replacing one level of the microprocessor with the next level, or with a different microprocessor would just require living with a different list of "anomalies."

scott

[marknorton]

Originally Posted by dalippe

This could well be the explanation for the vast majority of cases requiring battery ejecting/reinsertion.

There's lots of reasons why the camera can hang up and I was highlighting that components not conforming to their published specifications is another layer of complexity which has to be handled.

Knitting all the hardware and software together is difficult; as a developer, you can get results which make you question your sanity. Diagnostic information tells you one thing, the behaviour tells you something else. Imagine trying to build a piece of furniture with a ruler containing irregularly spaced markings or using a calculator which gives the wrong answers when a number is 3 digits with an 8 in the middle and you get the idea!

One particular reported problem caught my eye:

35.

05000207 - Recovery from "Brown-Out" Condition:

DESCRIPTION:

When a "brown-out" occurs, the internal Voltage regulator cannot be reset using the hardware reset pin. A "brown-out" is defined as a

condition in which VDDext drops below the range specified in the data sheet, but does not drop all the way to 0 V, before it returns to the
proper value.
WORKAROUND:
In order to recover from a "brown-out", the processor must be powered down completely and then powered back up.
APPLIES TO REVISION(S):
0.3

What this is saying is that if there is a glitch in the power supply line for the processor, as might happen with a weak battery, the processor could get into a state where it can only be recovered by battery-out. Impossible for me to say whether this is an issue with the M8 but it supports the idea of not letting the battery go completely flat and, since it applies to earlier processors only, might mean that later cameras, if they use the 0.5 processor (in which the problem is fixed), are more reliable in this area.