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

RP2350 Atomic Register Access #423

Open
adfernandes opened this issue Oct 17, 2024 · 3 comments
Open

RP2350 Atomic Register Access #423

adfernandes opened this issue Oct 17, 2024 · 3 comments

Comments

@adfernandes
Copy link

In the 2024-10-16 build of the RP2350 Datasheet, under Section 2.1.3 Atomic Register Access there is a description of which peripherals support Atomic Register Access.

Specifically, that section states:

The following registers do not support atomic register access:
• SIO (Section 3.1), though some individual registers (e.g. GPIO) have set, clear, and XOR aliases
• Any register accessed through the self-hosted CoreSight window, including Arm Mem-APs and the RISC-V Debug
Module
• Standard Arm control registers on the Cortex-M33 private peripheral bus (PPB), except for Raspberry Pi-specific
registers on the EPPB
• OTP programming registers accessed through the SBPI bridge

This description is, to me, somewhat imprecise and I am having a hard time understanding it.

If my understanding is correct, the only peripherals/registers that support atomic register access via MCU core are:

  • all read/write registers in the 0x40000000 APB Peripherals block
  • all read/write registers in the 0x50000000 AHB Peripherals block
  • ARM access to the read/write registers in the core-private 0xe0080000 EPPB block

(I am targeting multi-core applications, not debug access!)

Is my understanding correct?

Thank you for producing such an amazing document, by the way, and serious hat-tip to everyone who worked on that document... it's one of the best MCU datasheets I've ever read!

@nathan-contino
Copy link
Collaborator

@Wren6991 is the expert on this, I believe. Let's see what he has to say.

I'll keep my 👀 on this conversation because it sounds like we might be able to adjust the language in this section to clarify some ambiguity.

Thanks for the kind words! Our engineers put a lot of effort into this datasheet, all to help users like you wrap your heads around our hardware without melting your brains and/or bashing your heads against the wall. Barring some ambiguity, we mostly accomplish that :-)

@Wren6991
Copy link

If my understanding is correct, the only peripherals/registers that support atomic register access via MCU core are:

all read/write registers in the 0x40000000 APB Peripherals block
all read/write registers in the 0x50000000 AHB Peripherals block
ARM access to the read/write registers in the core-private 0xe0080000 EPPB block

This is almost correct, except that the self-hosted access to the APs is in the 0x4 APB space, but does not support atomic modifies.

image

I'm also confused by the emphasis on "via MCU core" -- all that matters is the address (and its accessibility). It doesn't matter whether the access originates from a processor, the debugger, or the DMA.

@adfernandes
Copy link
Author

Thank you, @nathan-contino and @Wren6991!

@Wren6991 you completely answered my question and even managed to figure out my somewhat mangled wording.

I'm also confused by the emphasis on "via MCU core"

Ah yes, the way that you put it - that atomic access is a property of the peripheral, not the accessor - makes way more sense than what I was trying to say!

I was trying to express the fact that the EPPB block will generate a bus fault if accessed from the RISC-V cores, so "don't do that".

My awkward wording comes from the fact that I'm extending the rp235x-pac crate to add an AtomicallyModifiable trait, so I was trying to say "don't add that trait to the EPPB block" for the risc-v functions... but I just realized that the API probably doesn't generate accessors for that block on risc-v!

(I just checked, and oopsie yes it does ... time to file a bug report!


Anyhoo, I can bit-bang registers and peripherals all day long, but I've grown fat and lazy letting Segger or pyOCD set up CoreSight for me, so all that stuff is hazier for me than it should be, and I forgot all about the self-hosted debug stuff, mainly because I haven't seen that on any of the other Cortex-M chips I've worked with.

But of course, the section in the datasheet is a fantastic resource, so again - thank you!


Lastly, here is my pseudo-code for the above discussion, please give it a look-see and feel free to add it to the next datasheet spin, if you think it's correct/useful!

bool has_atomic_register_access(const uint32_t register_address) {

    /// assume that `register_address` is a valid, 32-bit aligned peripheral register address

    if (is_not_read_write(register_address)) return false; // the register must have `read-write` access

    if (is_ahb_peripheral(register_address)) return true; // is in the `0x50000000 AHB Peripherals` address block

    if (is_apb_peripheral(register_address)) { // is in the `0x40000000 APB Peripherals` address block block

        if (is_self_hosted_debug(register_address)) {
            // exclude all `CORESIGHT_*` APB registers noted in section "2.2.4. APB Registers"
            // of the datasheet, which are addresses `0x40140000` to `0x4014afff`, inclusive
            return false;
        }

    }

    if (is_extended_private_peripheral(register_address)) {
        // exclude all EPPB peripherals noted in section "3.7.5.1. Cortex-M33 EPPB Registers"
        // of the datasheet, which are addresses `0xe0080000` to ` 0xe008000b`, inclusive
        return false;
    }

    return false;

}

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

3 participants