search

arduino / ArduinoCore-renesas

MIT License
110 stars 76 forks source link

"Unable to parse SVD file" error when starting debugger #276

Closed per1234 closed 5 months ago

per1234 commented 8 months ago

Describe the problem

An alarming looking error notification appears when the Arduino IDE 2.x integrated sketch debugger is started with an UNO R4 Minima / WiFi target:

image

🐛 The notification might lead the user to believe the debugger is in a non-functional state, even though it is functional.

🐛 The notification might serve as a "red herring", derailing the user's troubleshooting efforts when the debugger is in a non-functional state for a completely unrelated reason.

To reproduce

  1. Connect the board to your computer as appropriate (directly via USB cable if using UNO R4 WiFi, via external debug probe if using UNO R4 Minima).
  2. Select the board from the Arduino IDE menus.
  3. Select Tools > Programmer > ARM CMSIS-DAP compatible from the Arduino IDE menus.
  4. Select Sketch > Verify/Compile from the Arduino IDE menus.
  5. Wait for the compilation to finish successfully.
  6. Click the "Start Debugging" button on the Arduino IDE toolbar.

🐛 An error notification appears:

Unable to parse SVD file C:\Users\per\AppData\Local\Arduino15\packages\arduino\hardware\renesas_uno\1.1.0/svd/R7FA4M1AB.svd: Error: SVD error: Invalid 'derivedFrom' "P100PFS" for register "P30%sPFS"

Expected behavior

Debugger starts without any errors.

"Arduino UNO R4 Boards" version

1.1.0

Operating system

Operating system version

Additional context

I am using Arduino IDE 2.3.2

I did not check whether it also occurs for Portenta C33 because I don't own that board.

Workaround

Simply close the error notification and carry on using the debugger as usual.

embedded-kiddie commented 7 months ago

In R7FA4M1AB.svd, the register definition P100PFS, P100PFS_HA, P100PFS_BY are missing. Its svd file may be old so that it should be updated by the latest version of RA_DFP.

LightningStalker commented 6 months ago

The error still occurs after replacing R7FA4M1AB.svd with the latest version.

embedded-kiddie commented 6 months ago

@LightningStalker Thank you for your info.

I made a patched version. I added the definition of P100PFS, P100PFS_HA, P100PFS_BY to the original R7FA4M1AB.svd. Try this one: https:/ /gist.github.com/embedded-kiddie/48b388515ce280cc496fe6ef5ddb625f (deleted this gist)

It seems to be working fine. But I don't know how to ask ARM or Keil to update it. :shrug:

I explained how I made a patched version in here.

LightningStalker commented 6 months ago

@embedded-kiddie said:

@LightningStalker Thank you for your info.

I made a patched version. I added the definition of P100PFS, P100PFS_HA, P100PFS_BY to the original R7FA4M1AB.svd. Try this one: https://gist.github.com/embedded-kiddie/48b388515ce280cc496fe6ef5ddb625f

It seems to be working fine. But I don't know how to ask ARM or Keil to update it. 🤷

Thank you it appears to be working. I can't test the register definitions though I have no code that uses them.

facchinm commented 6 months ago

@umbynos can you give it a try and eventually submit a PR to integrate the patched version in the core?

embedded-kiddie commented 6 months ago

Hi @facchinm , @umbynos ,

While checking the details again before PR #293 is merged, I found a discrepancy between the RA4M1 user manual and the SVD file that is my mistake.

The RA4M1 User’s Manual can be downloaded from here

User’s Manual (Page 361 of 1454) says:

DSCR1-DSCR-en

note3-en

But In the file I created, b11 & b10 are defined as:

SVD file (diff in #293)

    <field>
      <name>DSCR</name>
      <description>Drive Strength Control Register</description>
      <lsb>10</lsb>
      <msb>11</msb>
      <access>read-write</access>
      <enumeratedValues>
        <enumeratedValue>
          <name>00</name>
          <description>Normal drive output</description>
          <value>#00</value>
        </enumeratedValue>
        <enumeratedValue>
          <name>01</name>
          <description>Middle drive output</description>
          <value>#01</value>
        </enumeratedValue>
        <enumeratedValue>
          <name>10</name>
          <description>Setting prohibited</description>
          <value>#10</value>
        </enumeratedValue>
        <enumeratedValue>
          <name>11</name>
          <description>High-drive output</description>
          <value>#11</value>
        </enumeratedValue>
      </enumeratedValues>
    </field>

It should be (from the definition of P000PFS):

  <field>
    <name>DSCR</name>
    <description>Port Drive Capability</description>
    <lsb>10</lsb>
    <msb>10</msb>
    <access>read-write</access>
    <enumeratedValues>
      <enumeratedValue>
        <name>0</name>
        <description>Low drive</description>
        <value>#0</value>
      </enumeratedValue>
      <enumeratedValue>
        <name>1</name>
        <description>Middle drive.</description>
        <value>#1</value>
      </enumeratedValue>
    </enumeratedValues>
  </field>

I'm now dedicating to check out the rest of the patched parts. So please wait to merge the PR #293 until I'm done.

And I'm currently contacting Renesas regarding the discrepancies mentioned in the User’s Manual. They are now in vacation until 6th May. (We Japanese say it as "Golden Week" :blush:) Please be patient for a while.

Sorry for bothering you :bow:

embedded-kiddie commented 5 months ago

Hi, I got the answers regarding the discrepancies from Renesas support person (who is not Japanese).

Now I understand the reason why I made a mistake - it was caused by a mistranslation in Japanese user's manual. (Note 3. P408 **only** has DSCR1 bit is translated into Japanese as P408 has **only** DSCR1 bit.)

Anyway, I've created a revised version, but haven't uploaded it yet. I believe that the definition of P100PFS, P100PFS_HA, P100PFS_BY is OK.

But it still has some issues.

issue 1: Duplicated P100PFS, P100PFS_HA, P100PFS_BY

This issue is caused by the following code:

<register derivedFrom="P000PFS">
  <dim>8</dim>
  <dimIncrement>0x4</dimIncrement>
  <dimIndex>0-7</dimIndex>
  <name>P10%sPFS</name>
  <description>P10%s Pin Function Control Register</description>
  <addressOffset>0x040</addressOffset>
  <size>32</size>
  <access>read-write</access>
  <resetValue>0x00000000</resetValue>
  <resetMask>0xFFFFFFFD</resetMask>
</register>

This directive makes from P100PFS to P107PFS.

issue 2: Incorrect inheritance

I send the following picture to Renesas support to ask I'm right: P101PFS The answer was:

Yes, only bit 11 is reserved for P101PFS. Showing bit [13:11] as Reserved is not correct.

This issue is caused by the following code:

<register derivedFrom="P000PFS">

Some registers inherit P000PFS. According to the user manual, they are incorrect.

To sum up, adding the definition of P100PFS, P100PFS_HA, P100PFS_BY is not enough. So I propose some options:

Option 1: Release the minimum revised version of board manager

At least the error will be resolved and the source code will be debuggable. I think many people around the world who have UNO R4 Minima/WiFi will be happy. Few people may want to observe peripheral registers, right?

Option 2: Someone in this community ask ARM or Kiel to fix the issues

I can't do this because ARM provides support only for company person. I retired last year. They say:

Please be aware that Arm Support is limited to companies with a Support Agreement with Arm. If you are using a personal email address, or are not affiliated with an existing company or university account, Arm will be unable to provide support.

Could anyone do it please?

Alternative option:

I have already asked Renesas to reach out to ARM or Keil, but have not received a response on this matter. I will continue to make requests to Renesas after the Japanese support member's vacation ends.

Option 3: The community will do it

I think it's tough work to check and revise those issues. At least, I'm not an expert of ARM core. Basically, I think it's not our job but ARM or Keil...

I prefer to do option 2 while doing option 1. What do you think?

embedded-kiddie commented 5 months ago

Hi, I've created a repository specifically for the R7FA4M1AB.svd file for mainly Option 1 and also Option 3.

The version v0.0.1 can fix the issue 1 and issue 2 in the previous thread.

So could you validate it? And if it's OK, then could you (@umbynos ?) reflect to the PR #293 ?

Or should I fork ArduinoCore-renesas and make another PR? I'm not familiar with this type of open source collaboration. So please let me know what should I do. Thx.

P.S. The end of line is CR,LF for windows.

facchinm commented 5 months ago

Hi @embedded-kiddie , creating a PR by forking ArduinoCore-renesas is usually the best way to ensure the proper attribution; we can help you if you are not familiar with the flow (just tick the box Allow modifications from maintainers when creating the PR).

embedded-kiddie commented 5 months ago

@facchinm , Thanks for the guidance. I created a new PR.

@umbynos , Could you please withdraw your #293 ? I don't know what it should be. Thank you for your cooperation!