Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

error message and question for example flash algorithm #12

Open
pkoevesdi opened this issue May 19, 2024 · 3 comments
Open

error message and question for example flash algorithm #12

pkoevesdi opened this issue May 19, 2024 · 3 comments

Comments

@pkoevesdi
Copy link

After running this:

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:

warning: unused import: `core::mem::MaybeUninit`
 --> src/main.rs:4:5
  |
4 | use core::mem::MaybeUninit;
  |     ^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

warning: `stm32h730xx_is25lp128` (bin "stm32h730xx_is25lp128") generated 1 warning (run `cargo fix --bin "stm32h730xx_is25lp128"` to apply 1 suggestion)
    Finished dev [optimized + debuginfo] target(s) in 0.01s
     Running `target-gen test template.yaml target/definition.yaml target/thumbv7em-none-eabihf/debug/stm32h730xx_is25lp128`
Generating the YAML file in `"target/definition.yaml"`
Test: Erasing sectorwise and writing two pages ...
thread 'main' panicked at /home/gauner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/probe-rs-0.23.0/src/flashing/flash_algorithm.rs:106:9:
assertion failed: props.sectors[0].address == 0
stack backtrace:
   0:     0x63e00c621d56 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h9c4bd387f9f3f544
   1:     0x63e00c651850 - core::fmt::write::h938c332fdab924eb
   2:     0x63e00c61e6bf - std::io::Write::write_fmt::h4a694b02e44e6363
   3:     0x63e00c621b34 - std::sys_common::backtrace::print::ha888e6736b0bc71f
   4:     0x63e00c6239e7 - std::panicking::default_hook::{{closure}}::he19a7f79f7beab5e
   5:     0x63e00c623749 - std::panicking::default_hook::h67efe04e9a5d446e
   6:     0x63e00c623e78 - std::panicking::rust_panic_with_hook::h49021cdbc4b22349
   7:     0x63e00c623d19 - std::panicking::begin_panic_handler::{{closure}}::hfbf601f3d8c62d13
   8:     0x63e00c622256 - std::sys_common::backtrace::__rust_end_short_backtrace::h98dd020b6e913806
   9:     0x63e00c623aa4 - rust_begin_unwind
  10:     0x63e00bdb9325 - core::panicking::panic_fmt::h0d3f1893e38be419
  11:     0x63e00bdb93e3 - core::panicking::panic::h59297120e85ea178
  12:     0x63e00c2a34ed - probe_rs::flashing::erase::erase_sectors::h25e9d94862ec1f2c
  13:     0x63e00be4f2fc - target_gen::commands::test::run_flash_erase::h239bbbdbd379a478
  14:     0x63e00be4d1ab - target_gen::commands::test::cmd_test::h12e8728bf1674815
  15:     0x63e00be24eef - target_gen::main::hc4e403a551333516
  16:     0x63e00be1df63 - std::sys_common::backtrace::__rust_begin_short_backtrace::ha43dda570a622439
  17:     0x63e00be194ed - std::rt::lang_start::{{closure}}::h507645e7f6a9c6cd
  18:     0x63e00c616ef1 - std::rt::lang_start_internal::hc3f700406209db2c
  19:     0x63e00be2e275 - main
  20:     0x7303b0828150 - __libc_start_call_main
                               at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
  21:     0x7303b0828209 - __libc_start_main_impl
                               at ./csu/../csu/libc-start.c:360:3
  22:     0x63e00bdb9b75 - _start
  23:                0x0 - <unknown>

I'd expect to have a working "empty" test. Am I wrong or is there something wrong?
Are there any example rust source code for a flash algorithm for some common SPI NOR flash memory? I see only binaries, for instance in https://github.com/probe-rs/probe-rs/blob/master/probe-rs/targets/STM32H7_Series.yaml.

@pkoevesdi
Copy link
Author

It delivers at least some more expected error, when changing the parameters this way:

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=0x0 -d flash-size=0x1000000 -d flash-page-size=0x100 -d flash-sector-size=0x1000 -d empty-byte-value=0xff
cd stm32h730xx_is25lp128
cargo run

(changed flash-start-address to 0x0). No I get pass that failed assertion, and have the feeling that I get an error from my core algorithm:

warning: unused import: `core::mem::MaybeUninit`
 --> src/main.rs:4:5
  |
4 | use core::mem::MaybeUninit;
  |     ^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

warning: `stm32h730xx_is25lp128` (bin "stm32h730xx_is25lp128") generated 1 warning (run `cargo fix --bin "stm32h730xx_is25lp128"` to apply 1 suggestion)
    Finished dev [optimized + debuginfo] target(s) in 1.42s
     Running `target-gen test template.yaml target/definition.yaml target/thumbv7em-none-eabihf/debug/stm32h730xx_is25lp128`
Generating the YAML file in `"target/definition.yaml"`
Test: Erasing sectorwise and writing two pages ...
Message: Init
Message: Erase sector addr:0
Message: Erase sector addr:4096
thread 'main' panicked at /home/gauner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/target-gen-0.23.0/src/commands/test.rs:147:5:
Not all sectors were erased
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Question is: Why is flash-start-address asserted to be 0 (in https://github.com/probe-rs/probe-rs/blob/master/probe-rs/src/flashing/flash_algorithm.rs#L106)? Or, alternatively, why do I get asked by the assistant in the first place, if it is asserted to be 0?

@9names
Copy link

9names commented Nov 5, 2024

Please copy a permalink if you're going to refer to code (so it's clear what you're talking about when someone notices months later).

I assume it's this line:
https://github.com/probe-rs/probe-rs/blob/1f3cc9a7934109cb1c0501588ad54c3b3a3a6f4c/probe-rs/src/flashing/flash_algorithm.rs#L119

Going to paste it here so it's easier to refer to:

assert!(props.sectors[0].address == 0);

Why is flash-start-address asserted to be 0

It's not flash-start-address that's asserted to be 0, it's that the first sector start address is 0.

You can have multiple groups of sectors (because some flash has sectors of different sizes).
At least 1 of them should start at address zero, so that it starts at flash-start-address.

Example of a flash chip with multiple sector sizes:

...
sectors: [{
    size: 4096,
    address: 0x0,
},{
    size: 32768,
    address: 0x10000,
}]
...

@pkoevesdi
Copy link
Author

pkoevesdi commented Nov 5, 2024

Thank You very much for looking at it. Yes, it was that line (for future reference the "old" permalink: https://github.com/probe-rs/probe-rs/blob/54748e51d8dff83d80251f44ed95e6def5f60d93/probe-rs/src/flashing/flash_algorithm.rs#L106).

Thank You, this sheds some light, obviously I misunderstood the source.

Still I'd be interested in some working example rust source code for a flash algorithm for some common SPI NOR flash memory. Any idea where to find those? I was not lucky with a general internet search.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants