Closed per1234 closed 5 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.
The error still occurs after replacing R7FA4M1AB.svd with the latest version.
@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.
@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/48b388515ce280cc496fe6ef5ddb625fIt 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.
@umbynos can you give it a try and eventually submit a PR to integrate the patched version in the core?
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:
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:
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.
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
.
I send the following picture to Renesas support to ask I'm right: 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:
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?
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?
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.
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?
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.
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).
@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!
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:
🐛 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
🐛 An error notification appears:
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.