index out of bounds: the len is 0 but the index is 0

[pkoevesdi]

Since it is a different error than in #12, I make a new issue.

After running this (same as in #12):

cargo generate gh:probe-rs/flash-algorithm-template  --name=stm32h730xx_is25lp128 -d target-arch=thumbv7em-none-eabihf -d ram-start-address=0x20000000 -d ram-size=0x20000 -d flash-start-address=0x90000000 -d flash-size=0x1000000 -d flash-page-size=0x100 -d flash-sector-size=0x1000 -d empty-byte-value=0xff
cd stm32h730xx_is25lp128
RUST_BACKTRACE=full cargo run

I get the follwing:

     Running `target-gen test template.yaml target/definition.yaml target/thumbv7em-none-eabihf/debug/stm32h730xx_is25lp128`
Generating the YAML file in `"target/definition.yaml"`
thread 'main' panicked at /home/gauner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/target-gen-0.24.0/src/commands/test.rs:126:51:
index out of bounds: the len is 0 but the index is 0
stack backtrace:
   0:     0x64257d7ac655 - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::h1b9dad2a88e955ff
   1:     0x64257d7d8e2b - core::fmt::write::h4b5a1270214bc4a7
   2:     0x64257d7a92df - std::io::Write::write_fmt::hd04af345a50c312d
   3:     0x64257d7ae0f1 - std::panicking::default_hook::{{closure}}::h96ab15e9936be7ed
   4:     0x64257d7addcc - std::panicking::default_hook::h3cacb9c27561ad33
   5:     0x64257d7ae751 - std::panicking::rust_panic_with_hook::hfe205f6954b2c97b
   6:     0x64257d7ae5b7 - std::panicking::begin_panic_handler::{{closure}}::h6cb44b3a50f28c44
   7:     0x64257d7acb19 - std::sys::backtrace::__rust_end_short_backtrace::hf1c1f2a92799bb0e
   8:     0x64257d7ae244 - rust_begin_unwind
   9:     0x64257d0a8e83 - core::panicking::panic_fmt::h3d8fc78294164da7
  10:     0x64257d0a9077 - core::panicking::panic_bounds_check::h9397cb495d89a72d
  11:     0x64257d150107 - target_gen::commands::test::cmd_test::h8b5cb9f44a795e90
  12:     0x64257d11b7c4 - target_gen::main::{{closure}}::h55002de8a631ca62
  13:     0x64257d11af93 - target_gen::main::he53204dfbf5a8325
  14:     0x64257d10e033 - std::sys::backtrace::__rust_begin_short_backtrace::hbaae12fec9693567
  15:     0x64257d0fc3cd - std::rt::lang_start::{{closure}}::h78a5b6e0095a9cb4
  16:     0x64257d7a04a0 - std::rt::lang_start_internal::h5e7c81cecd7f0954
  17:     0x64257d11cf75 - main
  18:     0x719450e2a1ca - __libc_start_call_main
                               at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
  19:     0x719450e2a28b - __libc_start_main_impl
                               at ./csu/../csu/libc-start.c:360:3
  20:     0x64257d0a9715 - _start
  21:                0x0 - <unknown>

In #12, I was one step further already, it reached the Test: Erasing sectorwise and writing two pages ... part, but this time, it fails already before. Judged by the source this might have something to do with the chip/familiy/names. It doesn't find an flash algorithm in the array.

[pkoevesdi]

I'll post here my findings.
First, for testing I introduced println!("{:?}",families); in line 67 of target-gen-0.24.0/src/commands/test.rs.
It gives out several families:
"Generic ARMv6-M"
"Generic ARMv7-M"
"Generic ARMv7E-M"
"Generic ARMv8-M"
"Generic RISC-V"
"algorithm-test"
Only the last, my newly created one, has a flash algorithm. target-gen test fails at the first chip on the first family of them, because there's no flash algorithm.

[pkoevesdi]

Ah, I see, it's a duplicate to this: probe-rs/probe-rs#2590.
And probably it's right there, this seems no problem in flash-algorithm-template.

[pkoevesdi]

Btw.:
I think, this is fixed by probe-rs/probe-rs@5ea7759
To try it out, You can (re)install cargo from master branch with this:
cargo install target-gen --git https://github.com/probe-rs/probe-rs --locked --force
(adapted from here)