Closed japaric closed 1 year ago
Do the SVD files generated from dslite ones make use of this alternateGroup feature?
No. There are a few (very few) overlaps in the dslite files, specifically...
for TM4C123x:
WARNING ecr overlaps with another register at offset 4. Ignoring.
for TM4C129x:
WARNING ecr overlaps with another register at offset 4. Ignoring.
WARNING gpcfg overlaps with another register at offset 16. Ignoring.
WARNING sdramcfg overlaps with another register at offset 16. Ignoring.
WARNING hb8cfg overlaps with another register at offset 16. Ignoring.
WARNING hb16cfg2 overlaps with another register at offset 20. Ignoring.
WARNING hb16cfg3 overlaps with another register at offset 776. Ignoring.
WARNING hb8cfg4 overlaps with another register at offset 780. Ignoring.
WARNING hb16time overlaps with another register at offset 784. Ignoring.
WARNING hb16time2 overlaps with another register at offset 788. Ignoring.
WARNING hb8time3 overlaps with another register at offset 792. Ignoring.
WARNING hb16time4 overlaps with another register at offset 796. Ignoring.
Analysis:
It would be an one-line change to add <alternateGroup>
generation to dslite2svd but I have not bothered because of the relative obscurity of all these registers and lack of svd2rust support. On the part of svd2rust...
_
.It also seems fine to skip the special code generation behavior (but not unsafe qualifier placement) for case 1 and just go with case 2 code structure for everything.
Also how do those SVD files deal with these registers with different read / write modes?
In general SVD files generated by dslite2svd specify the register as read-write and individual fields as read-only, read-write, write-only or what else you have. This is through no effort on part of dslite2svd because DSLite files already contain register-level as well as field-level access modes already.
@posborne Where do the TM4C files originate from? The official position of Texas Instruments, stated multiple times by their representatives on TI E2E (e.g. this thread dragging from 2014 to 2017), is that there are no available SVD files for TM4C series. The ones in your repository seem completely worthless to me as they do not specify register or field access modes. I suggest removing them from your repository.
Those files were added by @thejpster with this commit: https://github.com/posborne/cmsis-svd/commit/4eb54d1955af6dcad3cb053c444f258c3979ccff which references another thread on the TI forums for the source: https://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/p/261081/966053
By default we add alternateGroup
to register name. This can be disabled by ignore_groups
The TM4C1230C3PM.svd file defines the MCS register in the I2C0 peripheral like this:
This makes svd2rust generate two sets of
MCS
registers which makes the generated code not compilable. For some reason this doesn't the "overlapping" code that emits a warning about the overlap and only produces code for the first set of bitfields. Perhaps that's because the two overlapping registers have the same name?According to the SVD specification having these two registers with the same name is valid because one of the has a
<alternateGroup>
element. This what the specification says about<alternateGroup>
:What actually this SVD file meant to convey is that when writing to the MCS register only the fields HS, ACK, STOP, START, RUN can be used, but when reading the MCS regsiter then it contains the fields CLKTO, BUSBSY, IDLE, ARBLST, DATACK, ADRACK, ERROR, BUSY. Of course the SVD file doesn't do this right because it says nothing about read vs write mode; also the bit ranges are wrong ([6:6] = 0-bit field).
I think these TM4C fiels may be busted. @whitequark you have worked with these micros using dslite2svd. Do the SVD files generated from dslite ones make use of this alternateGroup feature? Also how do those SVD files deal with these registers with different read / write modes?