Contradictory SVD contents regarding CHAN_ABORT #1801

New issue

Closed

opened 2024-08-11 07:42:06 -05:00 by jannic · 5 comments

jannic commented

2024-08-11 07:42:06 -05:00

(Migrated from github.com)

With version 2.0.0, the access specification of CHAN_ABORT was changed to write-only in RP2040.svd:

            <register>
                <name>CHAN_ABORT</name>
                <addressOffset>0x00000444</addressOffset>
                <description>Abort an in-progress transfer sequence on one or more channels</description>
                <resetValue>0x00000000</resetValue>
                <fields>
                    <field>
                        <name>CHAN_ABORT</name>
                        <description>Each bit corresponds to a channel. Writing a 1 aborts whatever transfer sequence is in progress on that channel. The bit will remain high until any in-flight transfers have been flushed through the address and data FIFOs.

                            After writing, this register must be polled until it returns all-zero. Until this point, it is unsafe to restart the channel.</description>
                        <bitRange>[15:0]</bitRange>
                        <access>write-only</access>
                    </field>
                </fields>
            </register>

I guess this was done because of RP2040-E13 and one should poll BUSY instead of CHAN_ABORT.

However, the description still says "After writing, this register must be polled until it returns all-zero." This can't be done on a write-only register.

With version 2.0.0, the `access` specification of `CHAN_ABORT` was changed to `write-only` in `RP2040.svd`: ``` <register> <name>CHAN_ABORT</name> <addressOffset>0x00000444</addressOffset> <description>Abort an in-progress transfer sequence on one or more channels</description> <resetValue>0x00000000</resetValue> <fields> <field> <name>CHAN_ABORT</name> <description>Each bit corresponds to a channel. Writing a 1 aborts whatever transfer sequence is in progress on that channel. The bit will remain high until any in-flight transfers have been flushed through the address and data FIFOs. After writing, this register must be polled until it returns all-zero. Until this point, it is unsafe to restart the channel.</description> <bitRange>[15:0]</bitRange> <access>write-only</access> </field> </fields> </register> ``` I guess this was done because of RP2040-E13 and one should poll `BUSY` instead of `CHAN_ABORT`. However, the `description` still says "After writing, this register must be polled until it returns all-zero." This can't be done on a write-only register.

lurch commented

2024-08-12 04:12:23 -05:00

(Migrated from github.com)

ping @matiasilva

kilograham commented

2024-11-18 17:36:01 -06:00

(Migrated from github.com)

ping @matiasilva @Wren6991

Wren6991 commented

2024-11-21 06:02:33 -06:00

(Migrated from github.com)

@matiasilva I checked the upstream sources and this field (one-field register) is correctly marked as sc. Is something going wrong in the new header export?

Seems possible it's getting incorrectly mapped as write-only in the SVD conversion, and we just haven't noticed because sc is usually in a register with other types which are readable.

@matiasilva I checked the upstream sources and this field (one-field register) is correctly marked as `sc`. Is something going wrong in the new header export? Seems possible it's getting incorrectly mapped as write-only in the SVD conversion, and we just haven't noticed because `sc` is usually in a register with other types which are readable.

matiasilva commented

2025-02-12 09:50:31 -06:00

(Migrated from github.com)

2.1.1 should have this fixed. The access type is reverted to read-write for any write/set clear fields but at the same time I've also added <modifiedWriteValues>oneToClear</modifiedWriteValues> to help tooling see that writing 1 does have special effects.

2.1.1 should have this fixed. The access type is reverted to `read-write` for any write/set clear fields but at the same time I've also added ` <modifiedWriteValues>oneToClear</modifiedWriteValues>` to help tooling see that writing 1 does have special effects.

kilograham commented

2025-02-18 13:02:33 -06:00

(Migrated from github.com)