Can't Flash STM32F750N8Hx

[haydenridd]

Describe the bug
Despite having it listed as a supported chip, probe-rs fails to write flash for chip STM32F750N8Hx complaining that no available flash loader algorithm is available.

To Reproduce
Steps to reproduce the behavior:

1. Target thumbv7em-none-eabihf
2. Use chip STM32F750N8Hx for probe-rs
3. Attempt to flash a binary using a JLink

Expected behavior
probe-rs should be able to flash the chip, given it is listed as supported!

Stacktrace
Logs generated when attempting to flash:

WARN probe_rs::config::target > Using custom sequence for ARMv7 STM32F750N8Hx
     Erasing sectors ⠁ [00:00:00] [###############################################################]      0 B/     0 B @      0 B/s (eta 0s )       Error failed to flash /home/hayden/Documents/rust_experiment/target/thumbv7em-none-eabi/debug/rust_experiment
             
             Caused by:
                 0: Error while flashing
                 1: Trying to write flash, but no suitable (default) flash loader algorithm is linked to the given target: STM32F750N8Hx .

Desktop (please complete the following information):

Operating System: Fedora Linux 37 (Workstation Edition)
     CPE OS Name: cpe:/o:fedoraproject:fedora:37
          Kernel: Linux 6.5.12-100.fc37.x86_64
    Architecture: x86-64```

[bugadani]

Can you please try updating your probe-rs to 0.23 and retry? It should print a bit more detailed error message in case it fails, and that would be helpful.

[haydenridd]

Amazing! Looks like you already found + fixed it. Still need those more detailed logs?

[bugadani]

We found something that was incorrect and I'm confident is the cause, but I would appreciate if you could verify that your issue was indeed fixed.

[haydenridd]

Alright, installed probe-rs 0.23.0 and unfortunately still getting the same failure, albeit a slightly more detailed message:

    Finished dev [unoptimized + debuginfo] target(s) in 0.00s
      Config default
      Target /home/hayden/Documents/rust_experiment/target/thumbv7em-none-eabihf/debug/rust_experiment
       Error The flashing procedure failed for '/home/hayden/Documents/rust_experiment/target/thumbv7em-none-eabihf/debug/rust_experiment'.
             
             Caused by:
                 Trying to write to flash region 0x8000000..0x8010000, but no suitable (default) flash loader algorithm is linked to the given target: STM32F750N8Hx.
                 ```

[bugadani]

Thanks, that verifies the theory for sure :) You'll need to install probe-rs from github to get the fix though, 0.23 was released a month or so ago. I believe you can do something like cargo install probe-rs --git https://github.com/probe-rs/probe-rs.git

[haydenridd]

Awesome! Thanks so much yall :)

[bugadani]

Apologies, the correct command is cargo install probe-rs --git https://github.com/probe-rs/probe-rs.git --features cli

[haydenridd]

Okay updated and we made it past the loader! However... Looks like something different now:

WARN probe_rs::probe::arm_debug_interface: DAP FAULT                                                                                        WARN probe_rs::probe::arm_debug_interface: Writing DAP register failed. Ctrl/Stat register value is: Ctrl {
    .0: 4160753539,
    csyspwrupack: true,
    csyspwrupreq: true,
    cdbgpwrupack: true,
    cdbgpwrupreq: true,
    cdbgrstack: true,
    c_dbg_rst_req: false,
    errmode: false,
    trn_cnt: 0,
    mask_lane: 15,
    w_data_err: true,
    read_ok: false,
    sticky_err: false,
    stick_cmp: false,
    trn_mode: 0,
    sticky_orun: true,
    orun_detect: true,
}                                                                                                                                            WARN probe_rs::session: Could not clear all hardware breakpoints: An ARM specific error occurred.

Caused by:
    0: Error using access port
    1: Failed to write register CSW at address 0x00000000
    2: An error occurred in the communication with an access port or debug port.
    3: Target device responded with a FAULT response to the request.                                                                         WARN probe_rs::probe::arm_debug_interface: DAP FAULT                                                                                        WARN probe_rs::probe::arm_debug_interface: Writing DAP register failed. Ctrl/Stat register value is: Ctrl {
    .0: 4160753539,
    csyspwrupack: true,
    csyspwrupreq: true,
    cdbgpwrupack: true,
    cdbgpwrupreq: true,
    cdbgrstack: true,
    c_dbg_rst_req: false,
    errmode: false,
    trn_cnt: 0,
    mask_lane: 15,
    w_data_err: true,
    read_ok: false,
    sticky_err: false,
    stick_cmp: false,
    trn_mode: 0,
    sticky_orun: true,
    orun_detect: true,
}                                                                                                                                            WARN probe_rs::session: Failed to deconfigure device during shutdown: An ARM specific error occurred.

Caused by:
    0: Error using access port
    1: Failed to write register CSW at address 0x00000000
    2: An error occurred in the communication with an access port or debug port.
    3: Target device responded with a FAULT response to the request.                                                                               Error The flashing procedure failed for '/home/hayden/Documents/rust_experiment/target/thumbv7em-none-eabihf/debug/rust_experiment'.
             
             Caused by:
                 0: Something during the interaction with the core went wrong
                 1: An ARM specific error occurred.
                 2: Error using access port
                 3: Failed to write register DRW at address 0x0000000c
                 4: An error occurred in the communication with an access port or debug port.
                 5: Target device responded with a FAULT response to the request.

And just to confirm this is a functional JLink that can flash binaries using the "regular" methods, here's a log of JLinkExe flashing the same .elf successfully:

SEGGER J-Link Commander V7.84f (Compiled Feb  7 2023 16:51:58)
DLL version V7.84f, compiled Feb  7 2023 16:51:27

Connecting to J-Link via USB...O.K.
Firmware: J-Link V11 compiled Jan 30 2023 11:22:20
Hardware version: V11.00
J-Link uptime (since boot): 0d 00h 05m 35s
S/N: 51022635
License(s): GDB
USB speed mode: High speed (480 MBit/s)
VTref=3.324V


Type "connect" to establish a target connection, '?' for help
Selecting SWD as current target interface.
Selecting 4000 kHz as target interface speed
Target connection not established yet but required for command.
Device "STM32F750N8" selected.


Connecting to target via SWD
InitTarget() start
SWD selected. Executing JTAG -> SWD switching sequence.
DAP initialized successfully.
InitTarget() end
Found SW-DP with ID 0x5BA02477
DPIDR: 0x5BA02477
CoreSight SoC-400 or earlier
Scanning AP map to find all available APs
AP[1]: Stopped AP scan as end of AP map has been reached
AP[0]: AHB-AP (IDR: 0x74770001)
Iterating through AP map to find AHB-AP to use
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0xE00FD000
CPUID register: 0x410FC271. Implementer code: 0x41 (ARM)
Found Cortex-M7 r0p1, Little endian.
FPUnit: 8 code (BP) slots and 0 literal slots
CoreSight components:
ROMTbl[0] @ E00FD000
[0][0]: E00FE000 CID B105100D PID 000BB4C8 ROM Table
ROMTbl[1] @ E00FE000
[1][0]: E00FF000 CID B105100D PID 000BB4C7 ROM Table
ROMTbl[2] @ E00FF000
[2][0]: E000E000 CID B105E00D PID 000BB00C SCS-M7
[2][1]: E0001000 CID B105E00D PID 000BB002 DWT
[2][2]: E0002000 CID B105E00D PID 000BB00E FPB-M7
[2][3]: E0000000 CID B105E00D PID 000BB001 ITM
[1][1]: E0041000 CID B105900D PID 000BB975 ETM-M7
[0][1]: E0040000 CID B105900D PID 000BB9A9 TPIU-M7
Cache: Separate I- and D-cache.
I-Cache L1: 4 KB, 64 Sets, 32 Bytes/Line, 2-Way
D-Cache L1: 4 KB, 32 Sets, 32 Bytes/Line, 4-Way
Memory zones:
  Zone: Default Description: Default access mode
Cortex-M7 identified.
PC = 20000000, CycleCnt = FD565897
R0 = 00000000, R1 = 00000000, R2 = 200007B8, R3 = 00000000
R4 = 00000000, R5 = 00000000, R6 = 00000000, R7 = 00000000
R8 = 00000000, R9 = 20000194, R10= 00000000, R11= 00000000
R12= 00000201
SP(R13)= 200003B8, MSP= 200003B8, PSP= 00000000, R14(LR) = 080003FC
XPSR = 61000000: APSR = nZCvq, EPSR = 01000000, IPSR = 000 (NoException)
CFBP = 00000000, CONTROL = 00, FAULTMASK = 00, BASEPRI = 00, PRIMASK = 00

FPS0 = 00000000, FPS1 = 00000000, FPS2 = 00000000, FPS3 = 00000000
FPS4 = 00000000, FPS5 = 00000000, FPS6 = 00000000, FPS7 = 00000000
FPS8 = 00000000, FPS9 = 00000000, FPS10= 00000000, FPS11= 00000000
FPS12= 00000000, FPS13= 00000000, FPS14= 00000000, FPS15= FFFFFFFF
FPS16= 00000000, FPS17= 00000000, FPS18= 00000000, FPS19= 00000000
FPS20= 00000000, FPS21= 00000000, FPS22= 00000000, FPS23= 00000000
FPS24= 00000000, FPS25= 00000000, FPS26= 00000000, FPS27= 00000000
FPS28= 00000000, FPS29= 00000000, FPS30= 00000000, FPS31= FFFFFFFF
FPSCR= 00000000
Reset delay: 0 ms
Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via AIRCR.SYSRESETREQ.
'loadfile': Performing implicit reset & halt of MCU.
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via AIRCR.SYSRESETREQ.
Downloading file [target/thumbv7em-none-eabihf/debug/rust_experiment.elf]...
Comparing flash   [100%] Done.
Erasing flash     [100%] Done.
Programming flash [100%] Done.
J-Link: Flash download: Bank 0 @ 0x08000000: 1 range affected (32768 bytes)
J-Link: Flash download: Total: 0.505s (Prepare: 0.035s, Compare: 0.009s, Erase: 0.373s, Program & Verify: 0.069s, Restore: 0.017s)
J-Link: Flash download: Program & Verify speed: 463 KB/s
O.K.
Reset delay: 0 ms
Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via AIRCR.SYSRESETREQ.
OnDisconnectTarget() start
OnDisconnectTarget() end

[bugadani]

Unfortunately I don't have one of these devices so I won't be able to debug this.

[haydenridd]

No worries! Let me know how I can help! Newbie to Rust for sure, but intimately knowledgeable about this chip. If you point me in the right direction for a source file I can start twiddling with for what's actually writing stuff to chip (via JLink) I can give it a look

[bugadani]

I haven't been following the STM32 scene in a few years, I don't really know where to start. What I can see is that the errors provided by probe-rs aren't helpful at all. But it's not clear to me whether programming went through correctly (you kind of suggested that, but I'm not sure if I interpreted the comment corectly), and where the process gets stuck. I personally wouldn't want to waste your time by suggesting red herrings to change, so maybe someone more knowledgeable can chime in.