SAM RH707 Support

[blietaer]

Dear Michał and atsams-rs Team,

Many thanks for crediting me in the latest newsletter, despite my humble contribution ! 😅

As I am about to dig a bit more this SAM platform for both the SAM V71 & E70 (respectively Xult & MCLV2 boards) but also the SAM RH707 (on its evaluation kit board), I would like to understand from you guys if there is any room/need/willingness for converging efforts:

1.) I'll have to derive the SAM RH707 PAC from its .svd, and then hopefully its HAL: it is understood that specific PACs should now be hosted outside of this very atsams-rs repo: is this OK I simply hold it on my personal GitHub then ?
(And anything already done for SAM RH707 ? Is the HAL easily inspired from existing ones, once I have it PAC generated ?)

2.) I believe this whole atsamx7x-rust is based on the RTIC v1.x (or did I goof from branches? ) and I am mostly experimenting on RTIC v2.0.1 nowadays: is this valuable/appreciated if I push somehow/somewhere here my ported examples on RTIC v2.x ?

3.) Latest RTIC version seems to require a dedicated rtic-monotonics implementation for this whole SAM 7xx family MCU, if we want to have a timer-based one (today only the 'Systick' one is working fine (maybe it is enough for most of us...?): is this also already ongoing effort somewhere by someone ?

Sorry if this is the wrong place to ask these points: please rick-roll me to the appropriate Matrix channel (is the RTIC channel on Element the right place to discuss this as most of you guys pop-up over there ?)

Thank you,

Have a good one 🎅 !

Cheers,
Ben

[martinmortsell]

Hi Ben!
My understanding from quickly skimming the SAM RH707 datasheet is that it is largely compatible with the other MCUs supported in this HAL, so in my opinion supporting the RH707 here as well would make sense.

1. I think that once you have the PAC generation working properly it should be merged into the pac repo. Once the PAC is generated it should (in theory anyway) be usable with this HAL by adding additional feature flags for the new MCU.

2. Moving from RTIC1 to RTIC2 for the examples would make sense, if for no other reason than it being good practise to keep dependencies up to date. I don't think it will make a practical difference as the examples we have are simple enough that we do not really use any RTIC features.

3. There's not ongoing effort that I'm aware of but it would be a good thing to get done.

[michalfita]

Hi @blietaer,

Adding PAC is trivial, as we have the process automated. PAC would require SVDs for all variants of the new MCU.

What needs modification, however, is the ATPACKs Harvester to enable extracting SVDs from official Microchip's sources.

My worry is - and I don't have time experiment with - that IPs for peripherals in this new series may differ from those on SAME, SAMS and SAMV, as this is Microchip's design not original Atmel's, despite still being Cortex-M7. @martinmortsell is convinced it's mostly compatible, question is what's the percentage of that mostly and how much complication to feature flags any differences may introduce.

None of us has kits with that chip to run any checks or tests.

If you're willing to try, please start with making sure ATPACKs Harvester can download and extract right SVDs.

[blietaer]

Wow, great, many thanks for this quick and positive feedback to both of you.

Yes, I share the same worry: so ...let's dig and try, I have the board on my desk, a blinky test would be a nice first (although not deeply testing all PAC corner cases, of courses).

I was not aware of the ATPACKs Harvester: so this is the way to go ?
(I was heading to a vanilla svd2rust...)
Also, in your PAC repo, I see a python script: is this the entry door for the repo to pass a new MCU ?

And finally, so is this OK to keep this thread alive here as an 'issue' ? or do you want to move in another channel ?

[martinmortsell]

After Michał's comment I looked a bit more carefully at the datasheet, and I'd say the MCUs seem to be somewhat compatible, rather than mostly compatible. The peripherals that are shared might need some work, but it should be doable to integrate support into this hal.

And as he pointed out, we do not have access to development boards, so we cannot actually test the code.

[blietaer]

OK, understood, thanks !

I am happy to try and build my first PAC (and then adapt HAL if/as needed), testing it on my HW, ...but I'll have some (many) n00b questions... :/

Is that OK ?
Do I get you are the PAC/HAL guru here ? :)

[blietaer]

OK, so just installing the harverster the-cargo-way is failing on me... I am most probably missing something (should be done from a decent cargo folder ?)
Also, this tool seem to fetch (and parse?) the .svd directly from Microchip.
I got the .svd here on my local drive, from the usual Device Family Package (DFP), typically from their MPLAB Harmony repos: is this the intend of this tool to avoid this burden and have it automated in order to keep it up to date ?

[michalfita]

Do I get you are the PAC/HAL guru here ? :)

@tmplt & @martinmortsell wrote most of the HAL code so far, however, mostly as part of their full time job (Grepit AB work for Volvo). I started this years ago when SAMV70 was my main working platform, but never went past basics. And I redone the way we deal with PACs (finished recently; need proper release).

Now about the process:

Note
The DevOps for this is not finished

1. The atpacks-svd-harvester (check your typos) is a tool the atsamx7x-pac is using to download SVDs before commit for release.

2. The atsamx7x-pac uses svd2rust as library, so we generate crate structure for each variant from the update.py tool and publish. You have to run this manually on your clone if you wish to work on it. The directory is in the .gitignore to prevent accidental commit of thousands of files.

3. When the crate for particular MCU variant is downloaded, it has to be built for sources of PAC to appear, as they're generated in build.rs of the crate.

For your own experiments, you can play traditional way with local use of svd2rust over SVD files you have, just mind the version we're using as quite often they break API of generated PACs, so if you use too new, you'll start fixing broken code we're not ready for. We're currently to aim release based on 0.29.0.

Please don't publish any crates if you wish the support to be part of this organisation.

[michalfita]

I got the .svd here on my local drive, from the usual Device Family Package (DFP), typically from their MPLAB Harmony repos: is this the intend of this tool to avoid this burden and have it automated in order to keep it up to date ?

Yes.

This tools extracts SVDs from DFPs without need to download MPLAB Harmony every time - I'm not interested in vendor's IDEs especially when I work from command line on Linux.

[michalfita]

Margin note: To be complete, we should consider not only SAMRH707, but SAMRH71 and SAMV71-RT as well.

[blietaer]

Ah ! Sorry for the typo (careful: this was blindly cut'n'paste from your README...).
OK, will follow these nice guidelines first...

Yes, let's get rid of anything MPLAB related 🙈

[blietaer]

OK both PAC and Harvester seem to work properly with SAM RH7xx: I suggested changes to PR for both repo's...let me know how am I doing ?
Now I have a dedicated PAC for this MCU family, I believe it is about to play 'Where's Waldo?' comparing/diffing existing HAL+PAC for V71 and deduce SAM RH7xx from its own PAC... correct ?
On it.

[martinmortsell]

The datasheet will likely be very helpful here.

Setting up clocks and pins correctly will lay the foundation for most of the other peripherals.

The peripherals should be feature gated in src/lib.rs such that you only compile peripherals available on the RH707 when that feature is selected.

[tmplt]

From a cursory look at the datasheet the clock hierachy looks similar, at least. I'd start there for an eventual HAL adaption: peripheral clocks must explicitly be enabled before use on the X7Xs. After that comes the PIO, as Martin recommends.

I'd refrain from trying the X7X examples on your board until the implementation has been verified with the RH datasheets, just in case they put your hardware in an unknown state.

[tmplt]

Addendum: find the RH-equivalent of the ERASE pin. It may come in handy.

[blietaer]

Addendum: find the RH-equivalent of the ERASE pin. It may come in handy.

Good point, and more generally, as I unpack and plug the SAM RH707 Evaluation Kit Board, I already struggle with the debugger access under Linux (MPLAB IDE must work just fine, I guess, but I hope I won't have to try that one)... 🙄
I have to ways so far:

• an external debugger header (J5) compatible with my ATMEL ICE (white) probe;
• the internal/on-board (so called PKoB?!) debugger (actually making use of a ...SAM E70 chip 😅 ) over (micro) USB;

So far, none of these will speak my usual EDBG or OpenOCD scripts... I need to hack around and find out the decent configuration/tool.

(If you guys have ideas/hints, I am happy to hear it ! :P )

[tmplt]

An E70 is a bit overkill for a CMSIS-DAP debugger, so I presume it does a lot more work (ITM/ETM/etc; a buffer for the IDE). I'd go with direct access via J5.

But for curiosity's sake, does dmesg say anything interesting about the E70 debugger? Any jumpers that modify its behavior?

As for OpenOCD, does it ship with RH-compat configs?

[blietaer]

Agree the E70 must be overloaded with more...
Well dmest -Tw while plugging onboard debugger:

Mmmh no I am afraid the OpenOCD scripts/boards/target/interface won't match anything out-of-the-box for this board/chip...so I'll create the openocd.cfg (almost) from scratch :/

The OpenOCD with usual atsamv calls, shows:

[tmplt]

MPLAB PKoB 4

Indeed, it's an IDE-specific debugger.

I can't help with openocd, but an alternative approach would be probe-rs. It lacks RH-support, but it may be easier to implement and/or get support.

[michalfita]

@blietaer So, atpacks-svd-harvester v0.9.10 is released, with your support extended by V71-RT, checked; + some security updates.

And atsamx7x-pac v0.29.0-alpha2 is being released as I type this. You have now solid foundation to work on cracking support in the HAL.

Note
New crates doesn't have b suffix as that's how SVDs are named.

[blietaer]

Ah, sweet: many thanks 🙏
(I need to check how you work around the dash in enums for V71-RT in harvester for my own curiosity/education)

OK, so I have now the board RH707 on my desk, I am trying and checking the probes... :/

[michalfita]

I haven't work around, I used strum's feature.

[blietaer]

Mmmh not sure to see the line #46 of pacs.pu (glob.iglob()) updated on any branch of the atsamx7x-pac repo in order to support RH707 .svd string parsing: am I missing something ? 🤔

[michalfita]

I missed that. It's in your PR, but commented code needs to be removed before merge.

[blietaer]

I believe it is only this line all_svd_files = glob.iglob("ATSAM[E,S,V,RH]*[0,1,7][0,1,7]*.svd", root_dir=args.svddir)

[michalfita]

@blietaer I reviewed that line again couple of days ago and took a bit different approach. The fix is committed, but not released yet as I'm trying to automate releases, but release-plz doesn't work for me on CI, so I need different solution.

[blietaer]

Oh thank you and sorry for the useless hustle then.

[michalfita]

Don't. You pointed out at something I missed - that's important.