#12 ARMv7-M support

Unstable_(example)
open
nobody
None
1
2014-04-02
2013-05-28
Brutte
No

I have added a PPB support for ARMv7-M.
The DWT, TPIU, FPB, ETM and ROMT are not even started and SCS is not finished (lack of time) but I will try to update it later.

PPB view in EmbSys

PPB is the part of memory space that is not vendor specific but ARM specific. Some functionality is implementation dependent.

1 Attachments

Discussion

  • Brutte

    Brutte - 2013-05-28

    And the xml itself.

    Generic_CM3 1v13:
    Now with DWT(1+3 compare units) and FPB (6+2 compare units).

     
    Last edit: Brutte 2013-05-31
  • Raven Claw

    Raven Claw - 2013-05-28

    I never used an ARMv7, so its not really clear to me what this means ...

    this xml can be used for all ARMv7 cores, no matter what vendor.
    so to be usefull this has to be used together with the vendor specific registers ??
    If this is true this would be the 3rd use case for an inheritance/mix 2 files together feature.

    -Robert

     
  • Brutte

    Brutte - 2013-05-28

    I never used an ARMv7, so its not really clear to me what this means ...

    Well, but I do :)
    I use ARMv7-M.
    This core is gaining popularity and I thought you could also include this xml in next/future releases of EmbSys. As mentioned, it is incomplete but quite usable as the most important core peripherals are already there (with bugs I suppose).

    this xml can be used for all ARMv7 cores, no matter what vendor.

    Yes, that is right. No matter who is the manufacturer of the chip, as long as it has ARMv7-M inside then all those PPB registers apply. The file is generic, it is a super-set (some implementations can lack some features).

    so to be usefull this has to be used together with the vendor specific registers ??

    Yes. You need to combine it with vendor specific stuff like UARTs, Timers, GPIOs etc. But it can also be used independently if the only thing you are interested is the core itself.

    If this is true this would be the 3rd use case for an inheritance/mix 2 files together feature.

    You could CTRL+C/V append that with peripherals files for now if that is a problem.

    It would be great if those and other xml files could be maintained through svn in here. Could you do that and tell me how to maintain that?

    By the way, I have checked out svn of ST-Link project some time ago and modified it a bit so now my version supports ARMv6M, ARMv7M, ARMv7EM and ARMv7EM+FP core registers view but the problem is I have no idea how to upload it back to svn server because I have 0% knowlege about svn ;(

    ARMv7-M core registers

     
    • Raven Claw

      Raven Claw - 2013-05-28

      I will include it in 0.2.4.

      Embsysregview is maintained in svn here on sourceforge (https://sourceforge.net/p/embsysregview/code/HEAD/tree/)

      You can checkout the source from there...but only readonly.

      Currently I'm the only one with write access. I collect patches/new or updated files through Tickets->Patches on sourceforge and put it in svn after taking a short look at the files.

      For now it has to be CTRL+C/V.

      Hope that is ok for you that way.
      (Chris Morgan, talked to me about changing to git ...if I change from svn to git, you could checkout ...do stuff at home, check in every day at your local repo and send me patches when its ready...)

      If you want to know how svn works, i recommend http://svnbook.red-bean.com/

      about ST-Link ...i guess you only have read only access to that svn ... contact someone on that project, they will tell you how you can contribute your changes (patch/give you rw access to svn/...)

      -Robert

       
      • Brutte

        Brutte - 2013-05-29

        Currently I'm the only one with write access. I collect patches/new or updated files through Tickets->Patches

        Ok, that is fine. If I find more time I could also add MIPS4K core support one day :)

        Chris Morgan, talked to me about changing to git

        Yes, there are too many of those files and maintaining it manually is error-prone.

        about ST-Link ...i guess you only have read only access to that svn ... contact someone on that project

        I have just noticed it was git actually.. Whatever.
        I will contact someone from there. I hope my changes do not ruin their project.

         
      • Brutte

        Brutte - 2013-08-22
        For now it has to be CTRL+C/V
        

        Hi.
        I have changed this and that in the structure of /data folder so that IMHO it allows better reuse of some modules.

        The idea is based on the file inclusion in xml files.
        So instead of Ctrl+C/V we can include same modules (timers,uarts etc.) in many different xml files of different chips. That should reduce the maintenance cost greatly.

        Just extract the zip file INTO the /data folder and then select in EmbSys:
        /ARMv7-M/STM/STM32L152x.xml

        The example is an example only and is not complete. Shows the basic idea, made for STM32L15x family (this is the chip that comes with STM32L-DISCOVERY kit, it is ARMv7-M architecture from STM).

        Most of the peripherals are not implemented yet, but:
        CORE is 90% complete
        TIM/TIM3 is 99% complete

        What do you think about the idea?

        P.S. I have noticed you have mistakenly placed LPC23xx.xml in "ARMv7" folder. LPC23xx is ARMv4.
        Here is the list of all architectures of ARM:
        http://en.wikipedia.org/wiki/ARM_architecture#ARM_cores

        Each architecture has different CORE register set and those are not exchangeable.

        Edit: Oops, I have picked wrong {size="2"} attribute for some registers. This new version is ok.

         
        Last edit: Brutte 2013-08-22
        • Raven Claw

          Raven Claw - 2013-08-23

          I like the idea ...

          especially the fact that there is an includion feature in xml ...

          I'll take a look at it next week

          -Robert

           
        • Raven Claw

          Raven Claw - 2013-08-26

          Looks like there is a folder naming problem ...

          I called the first field "Architecture" and named the folders after the Family.
          your ARMv7-M architecture folder is the same as my Cortex-m3 folder ?

          so if I rename cortex-m3 to ARMv7-M and cortex-m4 to ARMv7E-M ...would people find their chip ?
          Until now I didn't know that my cortex-m3 is a ARMv7-M ...ok, I am not that into embedded things, so this is ok...

          Would most of the people know what ARMv7-M is ? or do most of them know the family name ? (if so i should rename the field do family)

          What do you think ?

          -Robert

           
          • Brutte

            Brutte - 2013-08-27

            Warning: lengthy!

            Looks like there is a folder naming problem. I called the first field "Architecture" and named the folders after the Family
            

            Is it about the fact that Cortex-M3 is the only member of ARMv7-M currently? Don't you worry - as you can see, ARM and vendors constantly add new names there. Take a look at ARMv7-A, or the mature ARMv4 - one architecture applies to several "marketing names"/families and I bet same happens with ARMv7-M sooner or later.

            Anyway, this is a naming problem with extensions/modifications because ARMv7E-M has very much the same core peripherals as ARMv7-M but for some reason ARM decided to give them different architecture names: Cortex-M3 and Cortex-M4. What for??

            So, some cores could lack some features, for example not every core of ARMv7-M architecture is 100% identical. Some have MPU inside, some have more priorities, more breakpoints, some come with "E" extension (DSP, like Cortex-M4) and some additionally come with "F" extension (like Cortex-M4F) but it is basically +- same stuff and similar core. The same thing applies to for example AVR8, where there are 16-register chips and those that come with 32-register set, etc. Then there are PIC8, where some have reduced core, but some even have priority IRQs, etc.

            Continuing, I would not use the "marketing names" that would later obfuscate the clarity of EmbSys. If the name does not bring any information - I would use the most generic name.

            Now, the real question is: How to structure EmbSys in a convenient way.
            Or rather: "Do the users need to know the architecture to use EmbSys?"

            IMHO: No.

            User should not need to know the name of the architecture (like ARMv7-M for LPC1769), or family_name (like Stellaris for LM4F120 etc.) but the the vendor of the chip and name (symbol) of the chip, only.

            On the other hand we want to share the *.xml files as often as possible in between the vendors and families without Ctrl+C/V so some trade-off is a must in here.

            That is why IMHO we should not use the structure that you proposed initially:
            [data->architecture->vendor->chipXYZ.xml]
            because of the "architecture" folder.

            I suggest to slightly modify that structure and make two distinct folders: one "invisible" with structure optimized for maintainability (code reuse at priority) and the second "visible" with structure optimized for user's convenience. This way there is no need for modifying any GUI in EmbSys.

            1. data/_Architecture/SubCore/coreXYZ.xml
            2. data/Vendor/Family/chipXYZ.xml

            Lets assume that all folders starting with underscore "_" and below are the "invisible" ones so only the SECOND folder structure:
            [data/Vendor/Chip_family_name/chipXYZ.xml]
            would be "visible" from EmbSys GUI.

            Now, each chipXYZ.xml will have to include the specific ../../_Architecture/SubCore/coreXYZ.xml file inclusion.
            As the structure of EmbSys is fixed, this "two steps up" path must be fixed for all chips' xml-s (not a problem I think).
            The gain: That is the most important, there will be only one coreXYZ.xml in all the embsys! No matter if it is Atmel, Nuvoton or NXP, if it is ARM, MIPS or 8051. And, the user would not need to know the architecture as only the [data/Vendor/Chip_family_name/chipXYZ.xml] would be GUI "visible". If the bug is discovered or new feature added - we need to change single file only.
            Wouldn't it be grand?

            My propositions for Architecture folders' structure:
            AVR8/
            AVR32/
            ARMv7/ (this contains folders for all cores that fall into ARMv7 category, including ARMv7-M subfolder where all the extensions are located (we can later discuss if the specific *.xml names here should be Cortex-M3.xml or ARMv7-M.xml) and ARMv7-A subfolder, ARMv7-R subfolder, etc. As ARMv7E-M(Cortex-M4) is only the extension of ARMv7-M, so IMHO it should NOT have its own subfolder because it will duplicate most of ARMv7-M folder content.
            ARMv6/ ( with subfolder ARMv6-M derivatives in here, including Cortex-M0, Cortex-M0+ and Cortex-M1)
            ARMv4/ (this contains folders for all derivatives/extensions of ARMv4, icluding ARM7TDMI, ARM9TDMI etc)
            PIC8/(here go all 8-bitters)
            PIC16/(16-bitters cores in here)
            MIPS4K/
            8051/
            STM8/
            etc.

            As the data/_Architecture/SubCore/coreXYZ.xml folder is NOT visible from GUI, it may/must not hold the same names as marketing names/symbols of the chips because vendors use "razzle-dazzle" technology on their products' names (to increase the sells??). For example PIC16F1455 is not 16-bitter but 8-bitter. Same as PIC18F. The PIC24 is 16-bitter, similar to dsPIC33, ATMega48 is not much different than any other ATTiny, AVR32 has nothing to do with AVR8, etc. Here the structure and names should resemble only PHYSICAL similarities. Similar stuff should be in same folder, no matter how sophisticated marketing name it was given. If the names collide ("PIC16" folder in this context means PIC24, dsPIC33 and alike, not PIC16F1455) - let be it, for the sake of maintainability, as it is not visible from GUI.

            Now, as for the second "visible" folder:
            [data/Vendor/Chip_family_name/chipXYZ.xml]

            This one should be named for the convenience of the user, even at the cost of bloated folder/subfolder count.

            I suggest this style (with the general rule "The longest name matches first", lower "x" means "any number"):

            Atmel/SAM3N/
            Atmel/SAM3S/
            Atmel/SAM3X/
            Atmel/ATMegaxx4/ATMega164.xml
            Atmel/ATMegaxx4/ATMega324.xml
            Atmel/ATMega/ATMega8.xml
            Atmel/ATMega/ATMega128.xml
            Atmel/ATTiny/ATTiny13.xml
            Atmel/ATXMega_A/
            Atmel/ATXMega_B/
            STM/STM32F10x/
            STM/STM32F2xx/
            STM/STM32L1xx/
            STM/STM8L/
            STM/STM8S/
            Microchip/PIC32MX/
            Microchip/PIC14/
            Microchip/PIC16/
            Microchip/PIC24/
            NXP/LPC17xx/LPC1769.xml
            NXP/LPC17xx/LPC1759.xml
            NXP/LPC13xx/LPC1313.xml
            NXP/LPC8xx/
            ...

            In the above example ATMega8.xml will include same core as ATMega128.xml, but ATTiny13.xml has a slightly different core.

            With LPC1769.xml and LPC1313.xml those both are Cortex-M3 but have different cores' "extensions" (LPC1313 does not have MPU which is part of the core).

            And now the last, perhaps even more important aspect of the structure:

            Most of the chips share many common peripherals.

            For example most STM32 stuff have all the same guts inside. So we can make it so that for example for STM32 we could add only one TIM3.xml file that would cover all STM32 chips!

            But the discussion about the Peripherals structure must wait for later, because now the importance is our agreement on the clarity of the structure so I will propose my "peripherals sharing structure" idea later.

            What do you think about my "core sharing" explained above?
            Lets now not go into details about how to technically make "visible"/ "not visible" folders or what are the specific folder's names.

            I am interested about your general impressions. What do you think?

             
            Last edit: Brutte 2013-08-27
            • Raven Claw

              Raven Claw - 2013-10-12

              This took me a while...actually a few attempts

              I fully agree with your Architecture Folder proposal.
              Adding architecture core parts using import

              [data/Vendor/Chip_family_name/chipXYZ.xml]

              Moving Vendor to the top makes sense. It’s probably the first thing you know about your chip.
              Second you get is the chip number. Its more practical to see the beginning of the chip number as the second folder if you are searching for your chip. (Other than currently browsing through all "architectures" to find it).

              Is the xx at the end really necessary ? for energy micro the length of the chip name vary with the IO's so this seems unpractical. The Chip_family_name would then be...(what do you think about adding the Family name to the grouping)
              data/Energy Micro/EMF32ZG_(Cortex-M0)
              data/Energy Micro/EMF32G_(Cortex-M3)
              data/Energy Micro/EMF32GG_(Cortex-M3)
              data/Energy Micro/EMF32LG_(Cortex-M3)
              data/Energy Micro/EMF32TG_(Cortex-M3)
              data/Energy Micro/EMF32WG_(Cortex-M4) ...would be displayed as "EMF32WG (Cortex-M4)"

              "ATMegaxx4"

              And is there really a chip that needs grouping by the last digit ?

              for example for STM32 we could add only one TIM3.xml file that would cover all STM32 chips

              Sharing non Architecture common parts seems to make things just too complex. Where would you store this TIM3.xml, who is responsible for it if X other XML files use it. We get to that later.

              Btw, have you tested what happens when the core XML file is not there? (crash?, just not included in the loaded file ?)

              I would like to get some more feedback on this change and schedule this structure changes for >=0.2.5. For 0.2.5 I also plan to merge the svd structure into the other part and modify the combo box like this to add a small icon do the right so you can see if its regview xml or svd.

              btw: 0.2.4 changes will be: only one dtd in the data root (referencing it with ../../) and moving the data folder in a separate plugin I can push data updates out faster. Beta is ready on the following update site: http://embsysregview.sourceforge.net/update-beta

               
              • Brutte

                Brutte - 2013-10-12
                I fully agree with your Architecture Folder proposal.
                

                Ok, that is great! The structure has to be transparent.

                Is the xx at the end really necessary ?
                

                You mean in the family folder name? The 'x' is a filter to group several chips into family. The 'x' is a convention, also used by ARM in CMSIS, for example the cmsis header files are named with "lpc17xx.h", "stm32f10x.h", "stm32l1xx.h" etc. I think that this is a nice way of grouping several xml's in one folder under self-explanatory/intuitive name.

                for energy micro the length of the chip name vary with the IO's so this seems unpractical.
                

                I think you can take a look at cmsis files of EMF32 and use same naming convention.

                Mind that I do not insist on 'xx' notation!
                Just use the one that is unique and does not confuse. Possibly the one that is used by the vendor.
                Example: Imagine that Microchip's PIC18 microcontrollers with USB are divided into several groups, Among them one is called "USB J" (like PIC18F87J90) and the other one is "USB non-J" (like PIC18F4550) so if we were to design a names for those folders then the 'x' notation does not fit into the official naming convention of Microchip - forget about 'x' then and use their "non-J" in the folder's name although it does not even match the uCs symbols.

                And is there really a chip that needs grouping by the last digit ?
                

                That is the Atmel's naming convention. The ATMega164, ATMega324 and ATMega644 differ (mostly) in memory sizes. Same as ATMega169/329/649, ATmega48/88/168/328 etc. The last digit defines the family (in 90% of chips).

                what do you think about adding the Family name
                

                I suggest that you should use the vendor's notation. If EnergyMicro uses such notation (EMF32+two capital letters+underline , without 'x') then use it. I think that adding "(Cortex-M3)" in the folder's name is not needed unless there are two folders with:
                data/Energy Micro/EMF32WG_(Cortex-M3)
                data/Energy Micro/EMF32WG_(Cortex-M4)
                otherwise this obfuscates the clarity (IMHO).

                Sharing non Architecture common parts seems to make things just too complex. Where would you store this TIM3.xml
                

                Good point. I would apply same rule as with "_architecture" folder. The folder of data/STMicroelectronics has to contain visible folders (STM32F10x, STM32L1xx etc) but also some invisible folders _STM32xTIMERS with all the generic timers inside. Then a family-specific peripheral has its xml in the same folder but including a generic part would require the inclusion of an xml from ./../ above. Or ./../../ higher when the xml is shared between several vendors (like the core in our case).

                Btw, have you tested what happens when the core XML file is not there?
                

                You mean during the declaration of entity when no such file exists? That crashes the parser. However if you use the entity that is not declared (like "&dummy;" without declaring "dummy" ) then the xml parser ignores that. More xml details in my post from yesterday.

                Beta is ready on the following update site:
                

                The link does not work.

                EDIT: I was expecting a *.zip and didn't realize this is an Eclipse update site! Ok, everything works fine. You have split data and plugin code - that should also ease the maintenance, good idea.

                 
                Last edit: Brutte 2013-10-28
            • Brutte

              Brutte - 2014-09-28

              Is it about the fact that Cortex-M3 is the only member of ARMv7-M currently? Don't you worry - as you can see, ARM and vendors constantly add new names there.

              New member of ARMv7-M family:
              ARM Cortex M7

              I am still upgrading the xml's. Are there any plans to switch to arm's svd file format?

               
  • Brutte

    Brutte - 2013-05-29
    • Description has changed:

    Diff:

    --- old
    +++ new
    @@ -1,5 +1,5 @@
     I have added a PPB support for ARMv7-M.
    -The DWT, TPIU, FPB, ETM and ROMT are not even started and SCB is not finished (lack of time) but I will try to update it later.
    +The DWT, TPIU, FPB, ETM and ROMT are not even started and SCS is not finished (lack of time) but I will try to update it later.
    
     [[img src=ARMv7-M.jpg alt="PPB view in EmbSys"]]
    
     
  • Brutte

    Brutte - 2013-10-08

    Here is a "GPIOA.xml" for STM32L1xx family.
    Mind GPIOs differ in between families so these do not match with STM32F1xx or STM32F4xx.

    Could someone take a look and check if everything is ok?
    Then I can create a template "GPIO_generic.xml" and from that template all other GPIOx files are going to be created.

    I wish I knew xml well enough so that all GPIOx.xml files could be generated automatically and not by find/replace from template..

    Update:

    I have made some research recently and it seems that the parsing of entities of xml, specifically inclusion of files (this is called "external entity"), is always made at the reference point and not at entity declaration. That dooms the idea of reuseability because all the redefinitions of entities are ignored (that is the design of xml parser).

    Here is what I have tried so far:
    I have substituted all "GPIOA" occurences in that "GPIOA.xml" with "&GPIOx;" expression and renamed file to "GPIOx.xml"

    When the inclusion of the "GPIOx.xml" is preceded with

    <!ENTITY GPIOx "GPIOA">
    <!ENTITY GPIOA SYSTEM "./GPIO/GPIOx.xml">
    

    Then at reference point of GPIOA

    &GPIOA;
    

    all the occurences of "&GPIOx; " are substituted by "GPIOA" and that works great.
    But unfortunately this:

    <!ENTITY GPIOx "GPIOA">
    <!ENTITY GPIOA SYSTEM "./GPIO/GPIOx.xml">
    <!ENTITY GPIOx "GPIOB">
    <!ENTITY GPIOB SYSTEM "./GPIO/GPIOx.xml">
    

    and with such reference point

    &GPIOA;
    &GPIOB;
    

    gives twice the GPIOA description because entity GPIOx cannot be redefined in xml and only first occurrence is considered :(

    Any workarounds to parse entities at declaration point and not at reference point??

     
    Last edit: Brutte 2013-10-11
    • Brutte

      Brutte - 2013-10-16

      Here is an improved version, more maintenance-friendly. It does not have the folder structure of Vendor/family/xml yet. I only wanted to propose a more efficient inclusion of xmls than before.

      Unzip into /data folder and pick STM32L15x.xml

      There open USB peripheral (other peripherals are either unfinished or "old style").

      Here USB xmls are separate and structured in a convenient way.

      The inclusion is made in two steps now:
      -First is the internal entity (parsed) from "USB/index.xml" which pulls in external entities.
      -Then external entities from index.xml (not parsed) pull in specific registers and addresses.

      This structure is much easier for debugging as you can comment out/remove/shift distinct registers or parts of code. And it is easier for ctrl+C/V :)

      Unfortunately I am still unable to pull in same xml several times (for GPIOA, GPIOB,... style) for full re-usability but at least all similar registers are located in one xml and are easily created from template.
      Open for example "EPnR.xml" to see what I mean by template. EP0R, EP1R... EP7R are created by ctrl+C/V and substituting "@n" string with 0,1,2...7 and that can be easily made within one minute.

      What do you think about internal entities?

       
  • Brutte

    Brutte - 2014-04-02

    Here is a proposed IMHO clear structure of EmbSys together with unfinished ATMega16 and STM32L152 examples.

    Zip contains a "data" folder that should substitute the current "data" if you want to test my idea (do not overwrite but rename original data folder and copy this one to original location).

    When using GUI imagine the names that start from "_" (underline) are invisible to the end user. Then the structure visible to the user is: Vendor/FamilyxxxFilter/Chip.
    I know, names do not match the 2.4.1 GUI: Architecture/Vendor/Chip but otherwise everything fits and is much easier as the end user doe not need to know the architecture but only the symbol of the chip.

    The idea of the structure is the maximal reusability of the code.
    To skip the "entity problem" I have used the makefiles to automate copying of some code. It is not perfect but I could not invent anything smarter as I do not know xml that well.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks