SAM RH707 Support

[blietaer]

Hey Noah,

Nice work and great tool.

As discussed earlier, I am working on the SAM RH707 support: using this repo, I manage to generate the target/definition.yaml, but still have a couple of questions:

a.) My target architecture (i.e. thumbv7em-none-eabihf) provided during the template generation as -d target-arch=thumbv7em-none-eabihf seems to properly make its way within .cargo/config.toml:

while in the template.yaml (and thus in the resulting target/definition.yaml), I see the type line is mentioning armv6m:

Is this OK/expected ? :)
I can see it referred as architecture during the cargo run too:

b.) So, although the .yml file generation is done, I can understand I am missing the whole implementation of the flash algorithm here: could you please elaborate on the process/guidelines to follow ?
Also what is the difference with your other (CMSIS) repo ?
Where should the implementation work be initiated first ?
The resulting file will (still) be a .yml file : is this the real single valuable input required in order to have probe-rs tool supporting properly a new chipset ?
All the magic being somehow compiled/translated in the long string of instruction within the .yml file ?

Many thanks for your feedback, time and support ! :)
Hope I can soon stop bugging you and quickly be autonomous and finally productive 🙈

Cheers,
Ben

[Yatekii]

Hey Ben!

Sorry for the late response!

a) That is a mistake in the template generation :/ It should ofc. be a different arch for the core :)
b)

• You basically need to implement the erase & write functions for the flash of your chip.
• What do you mean with the differences to the CMSIS?
• What do you mean with initiated first?
• Yes, usually it's only the YAML that's required :) Some chips require a custom debug sequence (which you can implement in the probe-rs repo in the arm architecture module)
• Yes, the magic string is a base64 encoded ARM/RISC-V binary :)

No worries, hit me with all the questions :)

[blietaer]

Sorry for the late response!
Response is always good, never late :)

a) That is a mistake in the template generation :/ It should ofc. be a different arch for the core :) b)
OK, something to be fixed in the Rust code itself ?

* You basically need to implement the erase & write functions for the flash of your chip.

This being actually writing Rust code in the src/main.rs thus ?

* What do you mean with the differences to the CMSIS?

Sorry: I mean the difference between this very repo flash-algorithm-template and the other one so-called flash-algorithm ?

* What do you mean with initiated first?

Well, it is actually a bit confusing for me to grasp the entire probe-rs mecanism: if it relies only on the generated .yml, where/how would the code in src/main.rs be actually used (e.g. does it impact the .yml? 🤔 )

* Yes, usually it's only the YAML that's required :) Some chips require a custom debug sequence (which you can implement in the probe-rs repo in the arm architecture module)

See this is the confusion, I am afraid :/
Maybe I need to step back a little bit: I also tried starting from a stupid .elf (MPLAB generated) with target-gen took (but "Failed to find 'FlashDevice' symbol in ELF file": maybe I am msising compilation flags in order to set it...), or also using a CMSIS data package: although it did not complain, the resulting .yml is not much useful.

* Yes, the magic string is a base64 encoded ARM/RISC-V binary :)

Ah, right !

No worries, hit me with all the questions :)
Ah, good to know this is the right place and not bugging everyone here, much appreciated ! 🙏