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