-
Notifications
You must be signed in to change notification settings - Fork 2
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
Comments
@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 :-) |
This is almost correct, except that the self-hosted access to the APs is in the 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. |
Thank you, @nathan-contino and @Wren6991! @Wren6991 you completely answered my question and even managed to figure out my somewhat mangled wording.
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 (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 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;
} |
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:
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:
0x40000000 APB Peripherals
block0x50000000 AHB Peripherals
block0xe0080000 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!
The text was updated successfully, but these errors were encountered: