How Segger J-FLASH configures its external loaders?

[Pavel A.]

A customer has a board with STM32F746 and QSPI flash.

The board looks as derived from STM32746G-DISCO, though I'm not 100% sure.

Their program has data in the QSPI flash, and they flash the app using J-LINK and Segger J-Flash.

Now, I cannot figure out how J-Flash deals with QSPI without "external loaders"?

And programming the QSPI part of the data does not work for me.

The internal flash part programs OK. Erase of the QSPI also looks OK. So I assume that J-LINK itself, cables, power are OK.

The customer says they never had any issue with flashing. Just drop a file to it and it does its ma*ic.

Below is the only config dialog I could find related to the QSPI.

What else is missing?

 

The flash indeed is mapped at 90000000. The size is 16 MB though it should not try to touch addresses not contained in the program file, right?

From the log window:

- Start of determining flash info (Bank 2 @ 0x90000000)
 - End of determining flash info
 - Flash bank info:
 - 512 * 64 KB @ 0x90000000
 - Start of preparing flash programming
 - End of preparing flash programming
 - Start of determining dirty areas in flash cache
 - End of determining dirty areas
 - CPU speed could not be measured.
 - Start of flash programming
 - Programming range 0x90000000 - 0x9000FFFF (  1 Sector, 64 KB)
 - Programming range 0x90010000 - 0x9001FFFF (  1 Sector, 64 KB)
 - Programming range 0x90020000 - 0x9002FFFF (  1 Sector, 64 KB)
 - ERROR: Programming failed @ address 0x90000000 (block verification error)
 - End of flash programming
 - ERROR: Program failed

[Tesla DeLorean]

It shouldn't technically be that hard to make a Universal Programmer for most flash parts. They all self-identify, and the specific algorithms could be scripted. I think IAR tries to do this, with scripts and such. Seem to recall Segger having something similar but it's been a while since using their tools extensively.

The complexity on the STM32 side is attributing the pins used, as this can be all over the map, but obviously the AF choices are relatively finite. You'd need options for DUAL and SINGLE BANK, ONE or TWO

Perhaps the Board/BSP type bring up is done via the "MCU Init" scripting, where you'd peek/poke the RCC, QSPI, GPIO, etc to bring up the MCU and its memory bus interfaces. This is how Keil manages debugging, there's a debugger script that walks-in the configuration and bring-up.

[Pavel A.]

Their J-flash project does not have any init steps or script...

 

They almost convinced me that the J-Link is so great and is well worth its price ((

[Tesla DeLorean]

>>Their J-flash project does not have any init steps or script...

It perhaps should..

https://wiki.segger.com/J-Link_script_files

Aren't these things inside the .jflash files? The main scripting for the connection can be selected in the MCU tab, as I recall

I remember there being quite some sequences involved in the AT91 parts I've used, and a number of those had stacked die construction where they connected an AT25 type die onto of the MCU

And I built an entire loader for an ARM926 SoC I worked on.