lpc-rs / lpc-pac Goto Github PK

Original issue: lpc-rs/lpc82x-pac#8

I'm not sure if this is something that should be addressed in the SVD file, but it is a problem for us in so far that the code generated from it compiles only with warnings. We address this in this patch.

As I said, I'm not sure if this needs to be fixed upstream, but as I have to contact NXP about other issues anyway, I'm going to bring it up. The names are weird after all, and it's definitely not intentional, as those names seem to be generated from the human-readable description.

I've reported the issue to NXP: https://community.nxp.com/thread/465465

https://docs.rs/lpc11uxx/0.3.0/lpc11uxx/iocon/pio0_1/struct._MODEW.html#method.inactive

Should we rename inactive to floating?

I noticed two directories with binaries commited:

• lpc54608/bin/
• lpc54608/bin/

Is that intentional?

If so, when would one want to include binaries or not in a new device?

Original issue: lpc-rs/lpc82x-pac#22

I've reported this issue to NXP: https://community.nxp.com/thread/465465

Original issue: lpc-rs/lpc82x-pac#7

According the the user manual, the registers are 8 bits wide, with all but 1 bit reserved. The SVD file specifies them as 1 bit wide, which is wrong. We address this issue with this patch, but ideally this should be fixed upstream.

I plan to contact NXP about this, but haven't gotten to it yet.

I've reported the issue to NXP: https://community.nxp.com/thread/465465

Hey, I'm wondering whether the LPC5500 series is on your radar? I'm currently exploring options for a Cortex-M33 chip. Also in a more roundabout manner, can you share some experiences/war stories on using LPC from Rust? Things like SVD quality, proprietary tooling, vendor support (one can dream), etc.

There are two approaches to managing SVD files:

• We can commit the original SVD file to the PAC directory and apply patches when generating the bindings
  • Variant: Only download the SVD on demand (risk: it could be offline)
• We can patch the SVD file directly in the repository and commit the fixes

The latter is basically the same as the former, but instead of using diff and patch to apply the patches, we use git. The applied patches can then be listed using git log. The only prerequisite for this is that the vanilla SVD file is committed before the patches are applied.

What are your opinons, @hannobraun and @rnestler? I tend towards the second approach, simply patching the SVD file directly and committing the result. It leads to less work when generating the bindings, since patches have already been applied.

Thanks for creating this repository, @rnestler! Since you didn't leave any work for me, I figured I'd get in on some bikeshedding :)

I'd prefer it if this repository was just called lpc-pac, for two reasons:

• I think the current name with the two dashes looks a bit noisy. lpc-pac would be easier to parse.
• There's already an -rs in the organization name, so having it again in the repository name is redundant.

I don't feel that strongly though, so if any of you disagree, feel free to close this issue.

cc @david-sawatzke

https://doc.rust-lang.org/edition-guide/rust-2018/cargo-and-crates-io/cargo-workspaces-for-multi-package-projects.html

Original issue: lpc-rs/lpc82x-pac#19

According to the user manual, section 18.6.1, there should be a bit called SEL_EXTCLK in the WKT's CTRL register. In the SVD file, that bit is marked as reserved.

I plan to contact NXP about this, but haven't gotten to it yet.

I've reported this issue to NXP: https://community.nxp.com/thread/465465

I'm starting to build the PACs for the (rest) LPC546XX family, but there is still an issue with needing to enable the SRAM banks. I opened an issue over at cortex-m-rt in this regard (#303 but i think that par is missing from the LPC54606-pac crate.

Have you figured out a way to include it?

after discussing it in #75 , we might be able to include the lpc81x pac in here.

there is a lot of differences between the patched 0.2 SVD (0.3? xml says 0.2), and the v1 SVD that is currently in this repository.

As I don't have a board with that MCU, it would be hard to test, and to see what would need to be fixed for a new version of the lpc81x-hal crate as well. @apparentlymart seems to be the owner of the HAL.

I don't think this would be an issue since both the PAC and the HAL have not been updated for a long time (3 and 2 years respectively). current new LPC pacs are on version 0.2.1, so they would not break current version of the hal, which relies on lpc-81x v0.1.0.

if @lucab is fine with moving the lpc81x pac here, that can be done by just publishing the current release (v0.2.1) that is generated by the current files for LPC81x.

• publish lpc81x-hal crate

For register PDRUNCFG, bit SYSOSC_PD, WDTOSC_PD, SYSPLL_PD and ACMP is wrong in svd. It should be be POWERED and POWERED_DOWN, but in svd it's DISABLED and ENABLED, totally flipped.

It's still available as lpc82x currently.

All of the following problems have been fixed. None of them have been reported to NXP so far.

• 7220929: Fix reset mask of INTVAL in MRT0
• 53b6b46: Remove duplicate interrupts
• 23d4432: Fix reset value of SYSMEMREMAP in SYSCON
• e90d462: Fix reset mask of TIMER in MRT0
• 811c801: Fix reset mask of TRM in ADC
• b7bfd8e: Fix reset value/mask of INTSTAT in USART0
• e8cffc0: ACTIVE0 and BUSY0 are read-only
• ba4b99f: Remove non-existing registers
• f5a024e: Fix value name/description of CTRL in WKT
• a0782e3: Fix access field of STAT fields in USART

Original issue: lpc-rs/lpc82x-pac#6

The SVD file contains duplicate names that prevent the generated code from being compiled. We address this in this patch, but ideally this should be fixed upstream.

I plan to contact NXP about this, but haven't gotten to it yet.

I've reported the issue to NXP: https://community.nxp.com/thread/465465

The USART FCR and IIR registers both live at the same address - one is write-only, the other is read-only. The LPC11UXX crate currently only defines one of those - the iir register - and makes it read-only. The SVD does define both, so I guess this might be an svd2rust issue?

According to the user manual, they following fields in SPI.STAT can be read and can be cleared by writing 1:

• RXOV
• TXUR
• SSA
• SSD

In the SVD file, all of them are marked as write-only.

All of the following problems have been fixed. None of them have been reported to NXP so far.

• 56eb539: Fix CPU revision
• ef1aeb7: Remove PINASSIGN_DATA registers
• 9431e7a: Remove non-existing enumerated value
• ce042eb: Fix values in SCT_INMUX
• 4ae6af0: Remove FMSTAT, FMSTATCLR
• a846d79: Fix description and bit mask of STARTERP1
• 827319b: Fix reset value of PDAWAKECFG
• e104f06: Remove wrong <access> in STAT (USART)

Original issue: lpc-rs/lpc82x-pac#12

According to the user manual, PRESETCTRL should contain the following bits, that are not available in the SVD file:

• ADC_RST_N
• DMA_RST_N

I plan to contact NXP about this, but haven't gotten to it yet.

I've reported this issue to NXP: https://community.nxp.com/thread/465465

Original issue: lpc-rs/lpc82x-pac#16

The MRT timer has a resolution of 31 bits, but the following registers only specify a width of of 24 bits:

1. INTVAL (IVALUE field)
2. TIMER (VALUE field)

This needs to be fixed by patching the SVD file, as it causes incorrect behavior. The timer value is truncated when reading to or writing from these fields. To remind me to add that patch, I'm not adding the "upstream" tag until that has been done.

A workaround for this is to bypass the field API by reading/writing the bits directly using the bits method on the register (not the ones in the field API).

I've reported this issue to NXP: https://community.nxp.com/thread/465465

I've also noticed this: https://crates.io/crates/lpc176x-5x

New and seemingly actively maintained. I think we should remove it from the repository and/or invite the author to join lpc-rs.

I've moved lpc82x-pac into this organization, but I've not integrated it into this repository yet. @rnestler, you mentioned that you moved the other PAC crates here with all their history. Could you do the same for lpc82x-pac?

If it's too much of a hassle, don't bother. I can either figure out how to do it myself, or just copy lpc82x-pac here without the history. Please let me know what you think.

I can do this myself later, but I'd actually like to invite @david-sawatzke to the lpc-rs organization, so he can do it himself :-)

@david-sawatzke Would you like to join the organization?

@lpc-rs/all Any objections?