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.

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?

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 ...

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.

@SEGGER - Nino , I have some further questions about this.

Does the OpenFlashLoader template generate RAMCodes that are supposed to work with JFlash, to be specified with the "Use custom RAMCode" option?
Looking at the documentation and some of the details, it seems like maybe it is not?

For example, the template is provided with instructions to generate an ELF, but then the "Use custom RAMCode" only allows for hex, srec, bin, etc.
And I don't see any way that the DLL could call into a binary or hex file, since it wouldn't know the function locations.

The FAQ section there makes reference to a Comapre() function, although there is no function stub for that in the OpenFlashLoader template ...

@SEGGER - Erik ah, thanks.

I am inching closer to this working ... but unfortunately, the "Release" build does not work in Segger Studio.
I am not that familiar with the Segger IDE, so maybe I am missing something obvious.

When I build the Release build, I get the error:
Output/Release/Exe/flash_loader.elf section `.text.libc.__int64_udivmod' will not fit in region `UNPLACED_SECTIONS'

Looking at the generated linker script, it is reporting that the length of the UNPLACED_SECTIONS is zero:
UNPLACED_SECTIONS (wx) : ORIGIN = 0x100000000, LENGTH = 0

Looking at Placement_release.xml, there are only sections for PrgCode, PrgData, DevDscr.
I will definitely need code and functions from libc to be linked in ...

The Debug build works fine and passes the example write/read test when running/debugging from the IDE.
When I try to run JLinkExe using the debug build elf, I get the error:
****** Error: Algo error: Cannot not find "PrgData" section.
which is not unexpected, if there is some kind of section remapping or redirection going on between the debug and release build.

@SEGGER - Nino , @SEGGER - Erik I am still stuck on this linking step.

Zip file is attached.

Notably, if I modify the plain template with only the change to use uint64_t or, as just an example, a sqrtf() in one of the OFL functions (like EraseSector), then I will get the same link error when building in the Release config, but not the Debug config.

Whoops ... that was because I added in the original template project (out-of-source) so I could do side by side comparisons.

New version is attached with that project removed, so now it should work.

I am not certain what is causing code that can't ultimately be linked to be pulled in. It looks like udivmod for a uint64_t type is what cannot find a home?
Can uint64_t types and/or modulos not be used, since they don't map directly to instructions and have to pull in a math function from libc?
That is a fairly daunting requirement...

I have an inkling that this will just take an edit to the generated linker script, or maybe there is a way to do it via Segger specific linker XML, by having PrgCode retain all the .text, .text.*, .rodata, .rodata.*, and other sections, and having PrgData keep .data, .bss.

I can apparently work around some of the link errors by re-including thumb_crt0.s in the the build, and modifying the generated linker script to include necessary sections; modified flash_loader.ld also attached.

However, I am still stuck with the remaining error/warning:
warning: section `PrgData' type changed to PROGBITS
and the ELF file is not generated.

Eh I am getting closer with we lap we do here. No need to go to contract just yet.

So, using that option, plus a few more, I can get the project to build.
This is what my Placement_release.xml contains:
Obviously, this is not quite right because it is pulling in the entire CRT, setup, stack and heap regions, etc.
I will revise and try to take out all the CRT and use just the bare minimum of setup. But we will need clocks to be set up and running for this to work ... the same would be true of a QSPI setup, so I assume there must be a way to make this work even if it requires the setup of an on-chip peripheral.

But it does now build and report 160K RAM usage, which would work with our 256K RAM target.

And I have amended the JLinkDevices.xml file with:

Unfortunately, when I try to connect with JLinkExe in Linux, I get the error:
No valid device has been selected.

Or from Windows, using JFlash, I can see `SPIFlashLoader` in the device selection box, but when trying to connect, I get:
ERROR: Failed to set device.

Hrm, OK. I did misunderstand the approach, and I thought I needed to define a new representative device, rather than just add a new FlashBank to the existing part.

Oddly, the JLinkDevices.xml file did not already have an entry in it for the STM32F412VE.
But I upgraded to the JLink package 6.34b, which does now have an entry there for STM32F412VE, including a loader for a memory mapped QSPI.

I added the line for the flash bank info into that <Device> entry:
<FlashBankInfo Name="128MbSPIFlash" BaseAddr="0x00000000" MaxSize="0x1000000" Loader="Devices/ST/STM32F4/ST_STM32F412V_serial_NOR_external.elf" LoaderType="FLASH_ALGO_TYPE_OPEN"/>

However, I still get the "No valid device has been selected" error in OSX.
Making the same change to the XML in Windows, opening the STM32F412VE device in JFlash project does report "Internal Bank 2" (1 is the existing QSPI definition), but with no size listed, and the "Failed to set device" error when connecting.

It seems a little unclear how I should be implementing the OFL project given the issues you've helped me with above.
The HAL is needed because there is a lot of chip specific setup to set the internal oscillator and PPL, set up the system clocks, then the GPIO and SPI peripheral, and then actually actuate the peripheral.
My last attempt is that I am trying to bring over the bare minimum required footprint of code from the HAL into the OFL template project.