Loading ...
Sorry, an error occurred while loading the content.
 

Re: Flash code protection

Expand Messages
  • kendwyer
    Are you talking about security function? The ML674K/5K Series devices allows for write protect of sectors. However the Flash does not have a security feature.
    Message 1 of 6 , Dec 13, 2004
      Are you talking about security function?
      The ML674K/5K Series devices allows for write protect of sectors.
      However the Flash does not have a security feature.

      --- In OKI-ARM-mcus@yahoogroups.com, "ggindele" <ggindele@y...> wrote:
      >
      >
      > Couple month ago is seemed OKI does not have code protection fol the
      > flash content. Did it change recently? I just read some new silicon
      > version vent into production and the errata's removed. Is there any
      > change in the code protection area?
    • ggindele
      Yes, it s the flash code read security that seems to be missing. Is there any other way the intellectual property can be protected?
      Message 2 of 6 , Dec 21, 2004
        Yes, it's the flash code read security that seems to be missing. Is
        there any other way the intellectual property can be protected?

        --- In OKI-ARM-mcus@yahoogroups.com, "kendwyer" <kendwyer@y...> wrote:
        >
        > Are you talking about security function?
        > The ML674K/5K Series devices allows for write protect of sectors.
        > However the Flash does not have a security feature.
        >
        > --- In OKI-ARM-mcus@yahoogroups.com, "ggindele" <ggindele@y...> wrote:
        > >
        > >
        > > Couple month ago is seemed OKI does not have code protection fol the
        > > flash content. Did it change recently? I just read some new silicon
        > > version vent into production and the errata's removed. Is there any
        > > change in the code protection area?
      • lpc2100_fan
        Hi, in 8-bit applications the flash protection has been a big issue for a long time. IN 32-bit application that usually have much larger code it was not
        Message 3 of 6 , Dec 23, 2004
          Hi,

          in 8-bit applications the flash protection has been a big issue for a
          long time. IN 32-bit application that usually have much larger code it
          was not considered such a big deal by chip designers, hence OKI and
          some more did not implement Flash protection against read. With
          programs getting a lot smaller and reverse engineering more feasible,
          read protection is very important. Atmels new SAM7xx have read
          protection and as far as I know the ST7R have it as well. Philips
          started out with the LPC2104/5/6 without read protection but switched
          fast to provide read protection for all other devices. All ARM read
          protection sthat I know are realized by disabling any debugging. In a
          single chip application, debug and build in programming is the way to
          get into the micro. If you use an external bus for code execution all
          bets are off, it is almost impossible to protect from reading.

          So, most competitors of OKI made the step to include read protection,
          let's hope Oki realizes how important that is and implements it soon
          as well.

          Cheers, Bob

          --- In OKI-ARM-mcus@yahoogroups.com, "ggindele" <ggindele@y...> wrote:
          >
          > Yes, it's the flash code read security that seems to be missing. Is
          > there any other way the intellectual property can be protected?
          >
          > --- In OKI-ARM-mcus@yahoogroups.com, "kendwyer" <kendwyer@y...> wrote:
          > >
          > > Are you talking about security function?
          > > The ML674K/5K Series devices allows for write protect of sectors.
          > > However the Flash does not have a security feature.
          > >
          > > --- In OKI-ARM-mcus@yahoogroups.com, "ggindele" <ggindele@y...> wrote:
          > > >
          > > >
          > > > Couple month ago is seemed OKI does not have code protection fol the
          > > > flash content. Did it change recently? I just read some new silicon
          > > > version vent into production and the errata's removed. Is there any
          > > > change in the code protection area?
        • raivo60
          interesting, how you imagine to protect memory content in von Neumann arcitecture computer with open data& aadress bus? I m sure, LPC22xx devices with
          Message 4 of 6 , Dec 30, 2004
            interesting, how you imagine to protect memory content in von Neumann
            arcitecture computer with open data& aadress bus?
            I'm sure, LPC22xx devices with external bus are not protected from
            reading FlashROM too.
            Maybe I'm wrong, but only secure controllers with external bus are
            Dallas DS5000 chips.
          • lpc2100_fan
            Hi, protecting an open bus is pretty much impossible IF CODE IS EXECUTED from there. However, if only data fetches access the bus or the whole device is used
            Message 5 of 6 , Jan 8, 2005
              Hi,

              protecting an open bus is pretty much impossible IF CODE IS EXECUTED
              from there. However, if only data fetches access the bus or the whole
              device is used as single chip with lots of digital I/O, it is
              definitely possible.
              Your statement that the external bus can not be protected is correct
              as soon as ONE (or more) instructions are fetched from external bus.

              Cheers, Bob

              --- In OKI-ARM-mcus@yahoogroups.com, "raivo60" <raivo60@y...> wrote:
              >
              > interesting, how you imagine to protect memory content in von Neumann
              > arcitecture computer with open data& aadress bus?
              > I'm sure, LPC22xx devices with external bus are not protected from
              > reading FlashROM too.
              > Maybe I'm wrong, but only secure controllers with external bus are
              > Dallas DS5000 chips.
            Your message has been successfully submitted and would be delivered to recipients shortly.