atsams-rs / atsamx7x-rust Goto Github PK

Link to the log:
https://github.com/atsams-rs/atsamx7x-rust/actions/runs/8616340444/job/23613747007#step:5:150

See CHANGELOG.md, c.f. v0.3.0 entry.

Copied from internal issue tracker:

USART setup is not done properly if the first mode to be entered is the "normal" mode.
When first entering the USART mode, the requested mode is compared against the reset mode, which is the normal USART mode. Therefore, in enter_mode, the check

    if self.mode() == H::MODE {
        // Already in the requested mode
        return;
    }

returns early and leaves my USART uninitialized unless I've switched to some other mode before.
My suggestion would simply be to remove this check, unless there's some really good reason why we wouldn't want to let the user soft-reset the peripheral by switching to the same mode.

We can flash 0x0 if the General-Purpse Non-Volatile Memory (GPNVM) bit 1 is set: this maps the internal flash to 0x0 instead of the ROM. These bits are set via the Enhanced Embedded Flash Controller (EEFC). An API to set/get these bits may be warranted.

Originally posted by @tmplt in #6 (comment)

The PMC is a fundamental component of this MCU family as it controls all system and user peripheral clocks. A solid HAL will require a PMC API which should bookkeep the clock configuration state in order to configure other peripherals.

The clock distribution is not too crazy (§31.3 from the family data sheet):

On a reset the MCU will boot from 0x0 with a VTOR of 0. A deployed product with OTA will likely have to set GPNVM bit 1 externally, otherwise the system will reset into the SAM-BA boot loader.

We should add documentation on how these bits can be configured via openocd.

Originally posted by @tmplt in #6 (comment)

embedded-hal has reached 1.0, There are some changes in traits since 0.2 and we should ideally update atsamx7x-hal accordingly.

Running the below RTIC application causes the MCU to jump into 0x0080000e8, the internal ROM which contains the SAM Boot Assistant (SAM-BA), instead of the defined interrupt handler app::uart0.

#![no_std]
#![no_main]

use panic_semihosting as _;

#[rtic::app(device = atsamx7x_hal::target_device)]
mod app {
    use atsamx7x_hal::target_device::Interrupt;

    #[shared]
    struct Shared {}

    #[local]
    struct Local {}

    #[init]
    fn init(_ctx: init::Context) -> (Shared, Local, init::Monotonics) {
        cortex_m::peripheral::NVIC::pend(Interrupt::USART0);
        (Shared {}, Local {}, init::Monotonics())
    }

    #[idle]
    fn idle(_: idle::Context) -> ! {
        loop {
            cortex_m::asm::nop();
        }
    }

    #[task(binds = USART0)]
    fn usart0(_: usart0::Context) {
        cortex_m::asm::bkpt();
    }
}

It appears that we need to poke at the vector table. I have yet to verify where the table points to, but I theorize that it points to ROM.

Digging in changes to svd2rust and how other PACs did things I figured we need critical-section feature in HAL that would enable critical-section dependency in PACs. I'm adding this to PACs at the moment, the next step is to fix things here.

To do this nicely we need breaking change is how rt feature is handled, to simplify things and avoid viscous cycle of bizarre feature names.

Many of the crates in this megaproject has seen a lot of changes since last publication on crates.io. I just assume this has slipped the mind of the maintainers. Latest version (0.1.0) was published in March. It'd be nice to have the 0.3 versions of the HAL and board crates be published, if they are ready ofc. All the peripheral access APIs have a version of 0.25.0 in their Cargo.toml files but the latest version published is 0.21.0 also back in March.

Looking forward to getting acquainted with this. Keep it up <3

Raised as result of discussion in #38.

Consider cargo-hack to support feature permutations in CI.

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

Reported on CI and on my computer after rustc upgrade:

error: ambiguous glob re-exports
  --> hal/src/serial/mod.rs:23:9
   |
23 | pub use uart::*;
   |         ^^^^^^^ the name `Tx` in the type namespace is first re-exported here
...
26 | pub use usart::*;
   |         -------- but the name `Tx` in the type namespace is also re-exported here
   |
   = note: `-D ambiguous-glob-reexports` implied by `-D warnings`

error: ambiguous glob re-exports
  --> hal/src/serial/mod.rs:23:9
   |
23 | pub use uart::*;
   |         ^^^^^^^ the name `Rx` in the type namespace is first re-exported here
...
26 | pub use usart::*;
   |         -------- but the name `Rx` in the type namespace is also re-exported here

error: ambiguous glob re-exports
  --> hal/src/serial/mod.rs:23:9
   |
23 | pub use uart::*;
   |         ^^^^^^^ the name `Uart` in the type namespace is first re-exported here
...
26 | pub use usart::*;
   |         -------- but the name `Uart` in the type namespace is also re-exported here

error: ambiguous glob re-exports
  --> hal/src/serial/mod.rs:23:9
   |
23 | pub use uart::*;
   |         ^^^^^^^ the name `UartError` in the type namespace is first re-exported here
...
26 | pub use usart::*;
   |         -------- but the name `UartError` in the type namespace is also re-exported here

error: ambiguous glob re-exports
  --> hal/src/serial/mod.rs:23:9
   |
23 | pub use uart::*;
   |         ^^^^^^^ the name `Event` in the type namespace is first re-exported here
...
34 | pub use spi::*;
   |         ------ but the name `Event` in the type namespace is also re-exported here

error: ambiguous glob re-exports
  --> hal/src/serial/mod.rs:26:9
   |
26 | pub use usart::*;
   |         ^^^^^^^^ the name `Client` in the type namespace is first re-exported here
...
34 | pub use spi::*;
   |         ------ but the name `Client` in the type namespace is also re-exported here

error: ambiguous glob re-exports
  --> hal/src/serial/mod.rs:26:9
   |
26 | pub use usart::*;
   |         ^^^^^^^^ the name `Spi` in the type namespace is first re-exported here
...
34 | pub use spi::*;
   |         ------ but the name `Spi` in the type namespace is also re-exported here

error: ambiguous glob re-exports
  --> hal/src/serial/mod.rs:26:9
   |
26 | pub use usart::*;
   |         ^^^^^^^^ the name `SpiError` in the type namespace is first re-exported here
...
34 | pub use spi::*;
   |         ------ but the name `SpiError` in the type namespace is also re-exported here

error: could not compile `atsamx7x-hal` (lib) due to 8 previous errors
Error: Process completed with exit code 101.

The CS goes high between each byte when sending longer packages.

I'm currently working with an spi device which requires that CS stays low for the entire transaction (CSAAT?) and I don't believe this behaviour is uncommon.
46.6.8.5 Details how this behaviour could be supported.

After comparing PACs it was concluded that rev. B of all SVDs (from which crates with the b-suffix are generated) include a more exhaustive memory-mapped API in comparison to rev. A. Most notable are perhaps the usage of USART::us_{mr,csr,cr}_{usart,spi}_mode in rev. B and USART::us_{mr,csr,cr} in rev. A. Of note in A is that some peripherals function register fields have different meaning depending on a master switch; i.e., when using USART in SPI mode auxilliary fields have different effects.

The idea of always using B SVDs/PACs sprung up but was altimately dropped after a brief conversation with Microchip: A/B have hardware changes for the Ethernet and CAN peripherals.

It is logical to support both revisions due to chip shortages.

So in summary, and with combination with §2 (below; see also §1 on page 14), we should add internal feature flags for permutations of the following predicates:

• Product series (different peripheral setups, certain characteristics):
  • V71
  • V70
  • E70
  • S70
• Pin count (fewer pins = less peripherals; only a concern for a PIO module)
  • J (64 pins)
  • N (100 pins)
  • Q (144 pins)
• Flash memory density (for convenience, e.g. live firmware updates)
  • 21 (2048K)
  • 20 (1024K)
  • 19 (512K)
• Device variant (revision)
  • A
  • B

Further, in order to speed up development, I propose that PRs must not implement an API for both rev. A and B.

Caused by #25

The check for missing feature in hal/build.rs is an impediment to operations of the rust-analyzer. I don't recall observing this problem when the check was in the code.

[ERROR rust_analyzer::lsp_utils] rust-analyzer failed to load workspace: Failed to read Cargo metadata from Cargo.toml file /home/manveru/Projects/atsamx7x-rust/Cargo.toml, Some(Version { major: 1, minor: 63, patch: 0 }): Failed to run `"cargo" "metadata" "--format-version" "1" "--manifest-path" "/home/manveru/Projects/atsamx7x-rust/Cargo.toml" "--filter-platform" "thumbv7em-none-eabihf"`: `cargo metadata` exited with an error: error: failed to load manifest for workspace member `/home/manveru/Projects/atsamx7x-rust/pac/template`

Caused by:
  failed to read `/home/manveru/Projects/atsamx7x-rust/pac/template/Cargo.toml`

Caused by:
  No such file or directory (os error 2)

[ERROR rust_analyzer::lsp_utils] failed to run build scripts

error: failed to run custom build command for `atsamx7x-hal v0.3.0 (/home/manveru/Projects/atsamx7x-rust/hal)`

Caused by:
  process didn't exit successfully: `/home/manveru/Projects/atsamx7x-rust/target/debug/build/atsamx7x-hal-c2579600962003a0/build-script-build` (exit status: 1)
  --- stderr
  Error: "The HAL is built for a specific target device selected using a feature, but no such a feature was selected."

Getting an error when trying to build the atsame70_xpro example. The other atsamv71_xult one builds fine.

error: linking with `rust-lld` failed: exit status: 1
  |
  = note: "rust-lld" "-flavor" "gnu" "/tmp/rustcvue7Jj/symbols.o" "/home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/examples/blinky_delay-873d777b61c44224.atsamx7x_hal-d5a980c4e9a39481.101fkh0e4q7472nd.rcgu.o.rcgu.o" "--as-needed" "-L" "/home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/deps" "-L" "/home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/debug/deps" "-L" "/home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/build/atsame70q21b-99c3868bec83c264/out" "-L" "/home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/build/cortex-m-bb856671e465605e/out" "-L" "/home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/build/cortex-m-rt-6a7ae1b79b44e4b7/out" "-L" "/home/cquick/.rustup/toolchains/1.63.0-x86_64-unknown-linux-gnu/lib/rustlib/thumbv7em-none-eabihf/lib" "-Bstatic" "/tmp/rustcvue7Jj/libcortex_m_rt-a8a12616f111b1f5.rlib" "--start-group" "/tmp/rustcvue7Jj/libcortex_m-aaa8d6483869b2d6.rlib" "--end-group" "/home/cquick/.rustup/toolchains/1.63.0-x86_64-unknown-linux-gnu/lib/rustlib/thumbv7em-none-eabihf/lib/libcompiler_builtins-814a2ee6da8588fb.rlib" "-Bdynamic" "--eh-frame-hdr" "-znoexecstack" "-L" "/home/cquick/.rustup/toolchains/1.63.0-x86_64-unknown-linux-gnu/lib/rustlib/thumbv7em-none-eabihf/lib" "-o" "/home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/examples/blinky_delay-873d777b61c44224" "--gc-sections" "-Tlink.x"
  = note: rust-lld: error: undefined symbol: _SEGGER_RTT
          >>> referenced by lib.rs:175 (/home/cquick/.cargo/registry/src/github.com-1ecc6299db9ec823/rtt-target-0.3.1/src/lib.rs:175)
          >>>               /home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/examples/blinky_delay-873d777b61c44224.atsamx7x_hal-d5a980c4e9a39481.101fkh0e4q7472nd.rcgu.o.rcgu.o:(rtt_target::UpChannel::conjure::hb1d03a52c6959c14)
          >>> referenced by lib.rs:175 (/home/cquick/.cargo/registry/src/github.com-1ecc6299db9ec823/rtt-target-0.3.1/src/lib.rs:175)
          >>>               /home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/examples/blinky_delay-873d777b61c44224.atsamx7x_hal-d5a980c4e9a39481.101fkh0e4q7472nd.rcgu.o.rcgu.o:(rtt_target::UpChannel::conjure::hb1d03a52c6959c14)
          >>> referenced by lib.rs:181 (/home/cquick/.cargo/registry/src/github.com-1ecc6299db9ec823/rtt-target-0.3.1/src/lib.rs:181)
          >>>               /home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/examples/blinky_delay-873d777b61c44224.atsamx7x_hal-d5a980c4e9a39481.101fkh0e4q7472nd.rcgu.o.rcgu.o:(rtt_target::UpChannel::conjure::hb1d03a52c6959c14)
          >>> referenced 5 more times


error: could not compile `atsame70_xpro` due to previous error
warning: build failed, waiting for other jobs to finish...
error: linking with `rust-lld` failed: exit status: 1
  |
  = note: "rust-lld" "-flavor" "gnu" "/tmp/rustcjHhWm2/symbols.o" "/home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/examples/blinky_irq-59e0ab1a23c855ac.atsamx7x_hal-d5a980c4e9a39481.101fkh0e4q7472nd.rcgu.o.rcgu.o" "--as-needed" "-L" "/home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/deps" "-L" "/home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/debug/deps" "-L" "/home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/build/atsame70q21b-99c3868bec83c264/out" "-L" "/home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/build/cortex-m-bb856671e465605e/out" "-L" "/home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/build/cortex-m-rt-6a7ae1b79b44e4b7/out" "-L" "/home/cquick/.rustup/toolchains/1.63.0-x86_64-unknown-linux-gnu/lib/rustlib/thumbv7em-none-eabihf/lib" "-Bstatic" "/tmp/rustcjHhWm2/libcortex_m_rt-a8a12616f111b1f5.rlib" "--start-group" "/tmp/rustcjHhWm2/libcortex_m-aaa8d6483869b2d6.rlib" "--end-group" "/home/cquick/.rustup/toolchains/1.63.0-x86_64-unknown-linux-gnu/lib/rustlib/thumbv7em-none-eabihf/lib/libcompiler_builtins-814a2ee6da8588fb.rlib" "-Bdynamic" "--eh-frame-hdr" "-znoexecstack" "-L" "/home/cquick/.rustup/toolchains/1.63.0-x86_64-unknown-linux-gnu/lib/rustlib/thumbv7em-none-eabihf/lib" "-o" "/home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/examples/blinky_irq-59e0ab1a23c855ac" "--gc-sections" "-Tlink.x"
  = note: rust-lld: error: undefined symbol: _SEGGER_RTT
          >>> referenced by lib.rs:175 (/home/cquick/.cargo/registry/src/github.com-1ecc6299db9ec823/rtt-target-0.3.1/src/lib.rs:175)
          >>>               /home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/examples/blinky_irq-59e0ab1a23c855ac.atsamx7x_hal-d5a980c4e9a39481.101fkh0e4q7472nd.rcgu.o.rcgu.o:(rtt_target::UpChannel::conjure::hb1d03a52c6959c14)
          >>> referenced by lib.rs:175 (/home/cquick/.cargo/registry/src/github.com-1ecc6299db9ec823/rtt-target-0.3.1/src/lib.rs:175)
          >>>               /home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/examples/blinky_irq-59e0ab1a23c855ac.atsamx7x_hal-d5a980c4e9a39481.101fkh0e4q7472nd.rcgu.o.rcgu.o:(rtt_target::UpChannel::conjure::hb1d03a52c6959c14)
          >>> referenced by lib.rs:181 (/home/cquick/.cargo/registry/src/github.com-1ecc6299db9ec823/rtt-target-0.3.1/src/lib.rs:181)
          >>>               /home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/examples/blinky_irq-59e0ab1a23c855ac.atsamx7x_hal-d5a980c4e9a39481.101fkh0e4q7472nd.rcgu.o.rcgu.o:(rtt_target::UpChannel::conjure::hb1d03a52c6959c14)
          >>> referenced 5 more times


error: could not compile `atsame70_xpro` due to previous error

Default host: x86_64-unknown-linux-gnu
rustup home:  /home/cquick/.rustup

installed toolchains
--------------------

stable-x86_64-unknown-linux-gnu (default)
1.63.0-x86_64-unknown-linux-gnu
1.69.0-x86_64-unknown-linux-gnu

installed targets for active toolchain
--------------------------------------

thumbv7em-none-eabihf
x86_64-unknown-linux-gnu

active toolchain
----------------

1.63.0-x86_64-unknown-linux-gnu (overridden by '/home/cquick/atsamx7x-rust/rust-toolchain.toml')
rustc 1.63.0 (4b91a6ea7 2022-08-08)

The CI is broken since the last push.
The CI for #38 fails in a few places (where it decides to run).
First cause of failure is that the CI think every subfolder of ./pacs/ is a pac, it clears the two first characters at normally, and builds with the selected pac as a feature.
Now there is a templates folder resulting in an attempt to run cargo build --features unproven,mplates.
Second Cause of failure mostly speaks for itself:

`cargo metadata` exited with an error: error: current package believes it's in a workspace when it's not:
current:   /home/runner/work/atsamx7x-rust/atsamx7x-rust/boards/atsame70_xpro/Cargo.toml
workspace: /home/runner/work/atsamx7x-rust/atsamx7x-rust/Cargo.toml

this may be fixable by adding `boards/atsame70_xpro` to the `workspace.members` array of the manifest located at: /home/runner/work/atsamx7x-rust/atsamx7x-rust/Cargo.toml
Alternatively, to keep it out of the workspace, add the package to the `workspace.exclude` array, or add an empty `[workspace]` table to the package's manifest.
cargo-fmt 

and results from the changes made to Cargo.toml in the root folder.

Copied from internal issue tracker:

The current usb-device implementation is a reverse-engineering feat that was compared to the ATSAMx5x family implementation, along with an RTT (and Wireshark) trace of a CDC-serial example (the branch of which I have forgotten at the moment where I put it), and some ideas taken from the tinyusb implementation of the x7x.

At the time, the latter was not traceable due to tinyusb/#1520, but with it closed, we can now gather additional data and improve our own implementation. tinyusb also contains some abstracted class implementations in case available usb-device implementations are found to be lacking.

So, what we should do now is RTT/Wireshark trace the current implementation in this HAL and compare it with that of the tinyusb example. In this trace, we should send some known payload to the device which is simply echoed back (usb_serial_echo example). These should be attached in this issue and relevant MRs should be created, closing this issue when traces match.

Copied from the internal issue tracker. By @martinmortsell:

The current implementation of the USART peripheral only supports at subset of the available interrupt sources.

pub enum Event {
    RxReady,
    TxReady,
    Overrun,
    TxEmpty,
}

The HAL should support more (all?) Event sources.
In particular, I was going to trigger an interrupt on NSSE in SPI mode.

Currently there are no docs on docs.rs for the crate: https://docs.rs/crate/atsamx7x-hal/0.4.1

It seems like the build failed due to missing some feature flags

Hey, I've been working on ATSAME70 support specifically in a repo as part of some contracting work (OVL => OneVariable UG Labs).

Since I've been focused on just this one chip, and a relatively limited set of features, it's probably not ready to merge 1:1, but just in case someone is interested, the repo is here, and I've published the crate under the name ovl-atsamx7x-hal for now, until this work gets upstreamed.

So far, I have the following components implemented:

• EFC - basically just the ability to set wait states
• GMAC - some corners rounded, really only tested to work with the KSZ8061 PHY, but capable of "doing ethernet" and has a smoltcp implementation capable of maintaining a TCP connection. Only supports one set of pins ATM
• PIOx - generally all 5 ports are supported, and some pin functionality is working (mostly setting ABCD peripheral modes, and output pins)
• PMC - Pretty rudimentary support, but enough to set some prescalers. I mostly use it to reach a single clock config (300MHz CPU clock, 150MHz MCK)
• RTT - A fixed 8192kHz frequency, usable for rtic-monotonic::Monotonic and groundhog::RollingTimer trait implementations
• Serial - I haven't really touched the upstream code here, I'm not using serial
• SPI - Basic "transfer" API support for the SPI0 peripheral. Only supports one set of pins ATM
• WDT - Basically just enough to shut it off

Feel free to take any of this work if you want/need it before I get a chance to upstream! I've kept the 0BSD license, so you can do what you'd like.

Edit (2022-04-22): Added RTT impl

I'm using the Usart peripheral in SPI Mode and it seems like the SCK is running at exactly 8 times the frequency I set it to.
E.g.

let spi_host_handle = handles.spi_host.configure(
    &usart_spi,
    &hclk,
    SpiConfig {
        bitrate: (2_000_000).bps(),
        mode: MODE_1,
    },                                                                                                                                                      │
).unwrap();                                 

yields a bitrate of 8MHz. I haven't explored this behaviour fully, but it seems to me that the cause is:

        const MIN_OVERSAMPLE: u32 = 8;
        let oversample_factor = MIN_OVERSAMPLE * if oversample { 2 } else { 1 };

in /usart/mod.rs
Compare 46.6.1.1 which is the current behaviour to 46.6.1.3 which is the desired behaviour in SPI Mode.

The system IO pins, e.g. PB04 need to be handled by the MATRIX peripheral as well as the PIO peripheral.
This was feature gated behind the configurable-system-pins feature, as using these pins for other things could potentially brick your device.

However, attempting to configure said pins without the feature fails silently, where it should fail to compile or at the very least panic during runtime.

Mmmh quite an interesting choice to run ADC test/example code on the AFE0_AD6 channel...as this pin is not (easily) exposed on the SAM V71 Xultra (blue) PCB dev. kit: what am I missing here ? 🤔

Well, I just tested it on the Xult/EXT-1 PIN#4 (PA19/AFEC0_AD8), working fine: shall I commit the change ?

This issue originates from cmsis-svd/cmsis-svd#153.

After a chat with Microchip it was pointed out that http://packs.download.atmel.com/ is outdated. The up-to-date pack repository is https://packs.download.microchip.com/, where much more recent SVD files for the SAM{E,V,S}7X chips can be found: the latest version for the SAME70 is 4.8.125 (from 2022), versus 2.4.166 (from 2019) mirrored in this repo.

An SVD issue regarding USART-SPI clock sources has also been filed recently; a bug-fix release is expected soon.

Work items:

• PR new SVDs to cmsis-svd
• Update PAC crates code
• Update all references about sources of SVDs used to generate PACs
• Adjust HAL to new PACs changes
• Publish PAC crates

Dear SAM Team,

I am afraid the UART examples are not working out of the box on the SAM V71 Xultra (blue) Board anymore (? I can't confirm it ever did, first time I try it).
Maybe I am doing something wrong, or oversight of a minimum (undocumented) wiring here ?

Sounds like a Clock issue as we can easily track this error msg down to uart.rs:358 (might want to try and play with both MCK and PCK values).

I have the (exact) same situation for both the examples/uart_loopback_test.rs and the examples/uart_interrupts, while both examples/usart_loopback.rs (using a small wiring PB00-PB01 on J505) and examples/usb_serial_echo.rs (using second 9target) USB port) are working just fine.

Any hint/correction/suggestion is welcome here ! :)

Cheers,
Ben

Derived from #11 to address the issue of chips with hardware revision A that are probably no longer sold.

Copied from the internal issue tracker:

The u32 extension of the Monotonic implementation in tc/generate.rs is subject to clock drift when the internal 16-bit counter overflows. We can probably compensate the RC register to nullify the drift.

Dear All,

Small question on the PWM you (seem to have) implemented on SAM V71/E70:
https://github.com/atsams-rs/atsamx7x-rust/commits/development/hal/src/pwm.rs

Is it correct understanding we can't drive individually both H/L signals of a PWM channel on this device ?

Now I see that in this example, at least, you can have a single-sided (LOW only) pwm :
https://github.com/atsams-rs/atsamx7x-rust/blob/development/boards/atsamv71_xult/examples/pwm_tc_freq_meas.rs

For the context, on the Microchip MCLV-2 (with SAM E70 PIM module), in order to control a BLDC motor, I am driving a 6 MOSFET H-bridge where 6 PWM signals are used. The MPLAB example (C code) work obvisouly, so, somehow, there is a trick, but I am not sure if the limitation here is the Rust HAL/PAC or....something else ?

Hope you can find couple of minute just to give me hints here ! :)
Of course this can be discussed else where (element.io ?)

Thank you,

Cheers,
Ben

   Compiling atsamv71q19b v0.25.0 (/home/manveru/Projects/atsamx7x-rust/pac/atsamv71q19b)
warning: lint `const_err` has been removed: converted into hard error, see issue #71800 <https://github.com/rust-lang/rust/issues/71800> for more information
 --> pac/atsams70n19b/src/lib.rs:3:9
  |
3 | #![deny(const_err)]
  |         ^^^^^^^^^
  |
  = note: `#[warn(renamed_and_removed_lints)]` on by default

So, it's materialization of rust-lang/rust#71800.

We need CI to actually test with MRV and latest.

As the title says.

The compiler version seems to be set in pac/templates/Cargo.toml.template effectively causing the entire project to be stuck with a compiler version that is just over a year old at this point.

Tracks: miker1423/atsamv71q21#2

The problem

The repository linked above contributes to atsamv71q21 crate and the owner of that repository seem to be the owner of the crate. I kindly asked to transfer the ownership, so we could further maintain all PAC crates together.

Label the codebase and publish crates.

• Update documentation
• Rebuild
• Tag
• Publish PAC crates
• Publish HAL crate
• Push
• Mark release

As suggested by @tmplt in #21, this is about harnessing power of build.rs to manage PAC crates.

When setting the clock frequency for the twi peripheral the actual Clock Frequency ends up being half of your input value.

This is because the formula does not take into account that the period is twice the time given in 43.8.5, as that is only for the high or low time of the pulse.

The objective for quite a long time is to remove PAC maintenance burden from this repo toward atsamx7x-pac that would in future fully automatically release following releases of svd2rust.

So far, the code on that repo regenerates PACs that when used do svd2rust heavy lifting on the user side, so we are able to keep very lightweight repository with copy of SVD files for reference.