LED notification
Michael
michael at 2020support.com
Fri Oct 17 16:46:10 CEST 2008
On 16/10/08 16:52:10, Andy Green wrote:
> Somebody in the thread at some point said:
> | (The first message I sent does not seem to have arrived)
> | On 12/10/08 18:00:55, Andy Green wrote:
> |> Yes always-on MPU can deliver consistent power behaviours we can't
> do
> |> in
> |> our current way of relying on PMU. You would basically make the
> PMU
> |> a
> |> slave of the MPU. Stuff like debricking scheme for a programmable
> |> and
> |> so brickable MPU that controls the PMU... needs careful thought.
> |>
> |> -Andy
> | That shouldn't be a problem, because microcontrollers support in
> | circuit serial programming, so just make sure we can get to those
> pins
> | and have a doc that specifies the programming protocol for the
> brave.
>
> The issue is that if we allow user-updateable MPU, it can always be
> bricked. So for example we put out a new package with some MPU
> update
> that is broken, suddenly many devices could be bricked before we pull
> it. We definitely need some credible sequence of actions for the
> end-user that can unbrick the devices. Just telling him where some
> pins
> are doesn't really cut it.
>
> If the MPU is master of the CPU, then when it is bricked a lot of
> assets
> we might otherwise call on are unavailable. So it needs thinking
> through being aware of specific capabilities of the MPU.
Should have mentioned that I have flashed microcontrollers for various
projects that I am doing, so this was just meant for people who are
used to this sort of thing rather than end users. I think you would
probably want to leave MCU updates to the distributors or people who
have done this sort of thing before and I suppose you would need a nano
boot loader if you wanted to flash the MCU from user space (if
microcontrollers that small will allow you to rewrite the flash from
code).
>
> -Andy
>
Michael.
More information about the community
mailing list