OpenFlashLoader w/ 128Mbit external SPI flash ; more than 512 sectors?

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • OpenFlashLoader w/ 128Mbit external SPI flash ; more than 512 sectors?

      I am attempting to implement the OpenFlashLoader for a 128MBit SPI serial NOR flash.

      This is a common architecture that I use in my design, so being able to read a full image and then program a full image via JFlash would be *great*. I presently have to "ferry" data into the flash chip ~512Kbyte at a time via the main micro flash and the serial flash image converted into C arrays. :S

      And since many of the 8-pin serial NOR flash chips have a common set of basic read/write commands, this should cover a large range of parts.

      However, in FlashOS.h in the OpenFlashLoader template package, I see that the maximum number of sectors is set to 512.
      These flashes use a 4K sector size, so for anything above a 2Mbit flash, we would exceed the maximum number of sectors, or only the first 2Mbit would be addressable.

      Is this a hard limit? Is there any workaround?
    • Hello,

      Thank you for your inquiry.
      Which SPI Flash are you looking to add specifically?
      Currently the 512 sectors is a hardcap. However sector size does not necessarily mean sector size of Flash vendors.
      Every Flash vendor calls something different "sector size".
      In our case it is the maximum number of different sector sizes available.
      So if your device has 4k ,16k and 64k sectors the number of sectors would be 3. If you have only 4k sectors it is 1.

      For your flash loader to work all you need to do is to specify the Flash specific values are explained in the Wiki article.
      We have numerous Flashes in our support list that are larger than 128 MBit which also work without any issues.

      Best regards,
      Nino
      Please read the forum rules before posting: Forum Rules

      Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support contact us per e-mail.
      The following contact form can be used for this: Contact Us

    • New

      I am adding support for GD25Q128CSIG and MX25L12835F chips. A fair number of other parts should fall under the same command set, too, which appears to be common for these 8-pin serial flash parts.

      So, it looks like I misunderstood what that structure was really defining?
      Per your description, it sounds like it is describing the types of geometry in the flash, rather than an enumeration of each sector present.

      The chips do have a uniform geometry of 4KB "sectors" (minimum erase quanta), but then also 32KB and 64KB "blocks", with unique erase commands for each size.
      These are all overlapping, so then it seems I will have to choose if I want to set it up as a uniform 4K/32K/64K device.

      > For your flash loader to work all you need to do is to specify the Flash specific values

      Well, I need to specify the flash values AND implement the read/write/erase/blank-check functions, right? That's the part that takes some effort & debugging. Note that I am using these in single-lane SPI mode with a Cortex M micro, not memory-mapped QSPI mode.
      If that part was already done for me, that would be great ...
    • New

      Hello,

      The MX chip is already on our supported SPI chips page: segger.com/products/debug-prob…es/supported-spi-flashes/
      The GD chip might work out-of-the box as the smaller and larger derivates are also supported.
      How are you programming the Flash. Directly or indirectly? wiki.segger.com/Programming_External_SPI_Flashes
      If directly just make sure your target device you have connected to your external Flash is on our support list listed as "External QSPI Flash": segger.com/downloads/supported-devices.php


      Which target device are you using?


      apullin wrote:

      If that part was already done for me, that would be great ...
      No problem. We offer this as a service. In that case NREs would apply. Would that be of interest for you?

      Best regards,

      Nino
      Please read the forum rules before posting: Forum Rules

      Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support contact us per e-mail.
      The following contact form can be used for this: Contact Us

    • New

      Our target device is an STM32F412.

      For the setup I am looking at, I don't believe J-Flash SPI will apply: we only have an SWD connection to the micro available, and for a variety of reasons, adding another station/jig that would do J-Link->SPI port directly to our current design & process isn't an option.

      But I would like to zero in on a good solution here, since this will likely become the standard for how I do manufacturing in the future!

      My understanding was that to use J-Flash in a JLink->micro->sflash setup, it requires the flash to be memory mapped by the micro.
      In my case, on the M4, I believe that would require using the Q-SPI peripheral, which I am presently not using.
      (the QSPI periph pinout *may* overlap with the standard SPI pinout I already have; tbd)

      Just plain SPI to the flash chip, and a low-level firmware driver. It appears that this is not a setup that is supported by any existing Segger solutions, other than an OpenFlashLoader implementation.

      So:
      The target setup that I am looking at would take that low-level simple SPI driver, implement the read/write/erase for the chip in the OpenFlashLoader template, in FlashPrg.c and the corresponding geometry in FlashDev.h .

      The hope is that I would eventually have a single J-Flash project that would:
      1) Load the OFL ramcode
      2) Use that to write through the 16MB (or just the non-empty part) image to the SPI flash.
      3) Load the F4 micro's main flash

      > NREs

      Maybe. If I get totally dead-ended on this, I'll request a quote.