F4 uart derivation interrupt fixes, add uart field definitions for f413/f423

[tim-seoss]

This PR corrects a regression caused by #713 and cleans up similar problems across other f4 parts, as well as correcting some incorrect interrupt definitions.

[tim-seoss]

n.b. This CI failure seems to be due to a difference in the output of the Python and Rust versions of svdtools (the Python version was first in my path, so was taking precedence).

[adamgreig]

They have different binary names (svd for Python, svdtools for Rust), the SVDTOOLS environment variable tells Make which one to use but defaults to Rust now. Are you able to reproduce the error locally using plain make or SVDTOOLS=svdtools make?

[tim-seoss]

Hi, some time ago I'd previously switched to the Python version (using a symlink, because I didn't spot the env variable) whilst I was debugging another problem. The problem is reproducible here when using the Rust version.

Is it expected that both the Python and Rust versions should behave identically?

[adamgreig]

Ah, that explains it! For correct input they should both generate the same output, but the Rust version is stricter about validity checking (or rather: has new validity checks that Python didn't have, so the rules about what's valid are stricter).

[tim-seoss]

I've hacked the input file, so that it both the Python and Rust versions run without complaint, but still produce different output...

The minimal hacked down version of stm32f413.yaml which reproduces this is:

_svd: ../svd/stm32f413.svd

# The UART peripherals are erroneously derived from a fully-featured USART
# (with extra features, and register fields which UARTs lack).
_delete:
  UART4:
  UART5:

_copy:
  UART4:
    from: ../svd/stm32f405.svd:UART4
  UART5:
    from: ../svd/stm32f405.svd:UART5

The Python version is outputting this (which is what I expect):

    <peripheral derivedFrom="UART4">
      <name>UART5</name>
      <baseAddress>0x40005000</baseAddress>
      <interrupt>
        <name>UART5</name>
        <description>UART5 global interrupt</description>
        <value>53</value>
      </interrupt>
    </peripheral>

Whilst the Rust version is giving:

<peripheral>
      <name>UART5</name>
      <baseAddress>0x40005000</baseAddress>
      <interrupt>
        <name>USART4</name>
        <description>UART 4 global interrupt</description>
        <value>52</value>
      </interrupt>
    </peripheral>

The derivedFrom is missing entirely - the one I want is the correct one in the unpatched stm32f405.svd, but there's also an incorrect one in stm32f413.svd, yet the output has neither.

The interrupt is wrong - it's kept the one from stm32f413.svd (despite the _delete), instead of using the correct one from stm32f405.svd.

Does this reproducer look OK to open a bug against svdtools, or am I doing something wrong ?

[tim-seoss]

BTW, would you prefer that I tackle the svdtools issue, or instead workaround it using a different (less concise) fix instead so that the regression can be addressed sooner?

[burrbull]

I think the issue is due to concurrent rules where different sequence of operations cause different result.

[tim-seoss]

This revised stm32f413.yaml (with the _delete removed) appears to produce the same results (svd and svdtools output still differ in the same way):

_svd: ../svd/stm32f413.svd

# The UART peripherals are erroneously derived from a fully-featured USART
# (with extra features, and register fields which UARTs lack).
_copy:
  UART4:
    from: ../svd/stm32f405.svd:UART4
  UART5:
    from: ../svd/stm32f405.svd:UART5

... so I think this is a bug rather than undefined behaviour. I'll try and take a look later this week.

[burrbull]

there must be array of strings, not a dict of dicts

[burrbull]

@newAM
Should close. Fixed by #762

[newAM]

Sounds good!