Hey,

I'm trying to flash an external nor flash via MCU. The NOR flash is the MT28EW128ABA1LPC and the MCU the STM32H753XI. The board I am using is the STM32H753I-EVAL board, so if I'm wrong providing any information, you can definitely get the correct info there
The NOR flash should be CFI compatible.

I was trying to follow the wiki.segger.com/CFI_Flash. But have trouble following the details. In the end, I thought I went into the right direction, but JFlash (or Ozone) are immediately crashing when trying to write to the Flash Region where the NOR Flash is mapped within the MCU memory space.


Update: This is no longer true, see post below.



I'm on linux (virtual box VM) and I am using V7.86h

JFlash is invoked with the following parameters: JFlashExe -openprj example2.jflash -open {{binary}} -auto -jflashlog jflash.log -jlinklog jlink.log -startapp

What I think, is that JFlash crashes before the JLinkScript is executed. I can't find the appropriate CPU_WriteMem invocations in the jlink.log, which I have written in the jlink script file.

I'm not sure, however, if I'm doing everything correctly here. No guarantees, that the JLinkScript configuration for the FMC (STM flexible memory controller) is completly correct. It might be the cause of the issue, but I think this is unlikely.

So I have digged further into the issue, eliminated the Virtual Box Linux Machine issues and using the most up to date JLink version on Linux (not virtualized) SEGGER J-Flash V7.88c, also there might be some mistakes in the previous J-Link Script so I've attached my newest revision to this reply.

1. To verify, that the FMC configuration of the STM is working, I've created aminimal firmware executable, which configures the FMC peripherals ofthe STM32H753XI (see jlink.zip/src/main.rs. It is able to read from the NOR flash as can be seen from the log (see jlink.zip/.embed.log/ executin [url='https://github.com/probe-rs/probe-rs']cargo embed --release[/url]
   
2. I've converted the configurion to the JLinkScript via the jlink.zip/convert-rust-to-jlinkscript.sh script leveraging cargo asm. The result is embedded in the J-Link Script file
   
3. I've flashed a simple firmware (led toggle) to verify that the script is working via JFlashExe -openprj example2.jflash -open jlink/target/thumbv7em-none-eabihf/release/jlink.elf -auto -jflashlog jflash.log -jlinklog jlink.log -startapp
   
4. I could verify in the log output that the JLinkScript is activated, though I could not really confirm yet, that the microcontroller was really configured correctly
   
5. After that I tried to flash an executable, which has data in a section for the external flash: JFlashExe -openprj example2.jflash -open jlink/target/thumbv7em-none-eabihf/release/examples/led.lef -auto -jflashlog jflash.log -jlinklog jlink.log -startapp
   

Now this failes with

I could not verify via a logic analyzer, that J-Link even tries to communicate via the MCU with the NOR flash, which I could verify with the jlink.elf program (which does this while running the firmware.

I am also a little confused about the wiki.segger.com/CFI_Flash entry, which talks about either using J-Link Script or using the the J-FLash Gui Option (Project settings -> Flash -> Adding new Bank), but I have no option but to set a new Bank for the external flash, otherwise J-Flash will complain not knowing how to flash the data to the region.

There is also no documentation, with which I can at least verify what to expect, once J-Flash tries to flash data to the external tool. I was not yet able to decipher the information from the jlink.log but maybe I am missing seomthing. For what I know, the flash should be CFI compatible, but it is not listed in the gui able to select manually, neither is it listed in the Flash.csv file found in the SEGGER install directories.

EDIT:

I've noticed in the jlink.log that JFlash is using the 8bit addreses to access the CFI Flash registers, even though 16bit mode should be used (and is used in the jlink.elf example firmware). For example to read the CFI ID JLINK_WriteU16(0x600000AA, 0x00000098) is called aka 0xAA offset, eventhough it should be 0x55 in 16bit mode. Changing the mode form 16 -> 8 bit via JLINK_ExecCommand("SetCFIFlash 0x60000000-0x60FFFFFF, 1, 8"); does not seem to change the behavior.