Skip to main content
johannes2
johannes2
Associate II
August 15, 2012
Question

STM32 IO Maps in machine readable format (e.g. XML)?

  • August 15, 2012
  • 4 replies
  • 1198 views
Posted on August 15, 2012 at 17:15

Hi,

I've asked this question via email to STM in May, but didn't get any response, so I'll try again here: Is there a machine-readable IO map description for the STM32 family available anywhere? By this I mean some type of parsable information that includes the units (e.g. GPIO, Ethernet, USB, etc.), the registers and their respective enums and bitlocations. TI and NXP both distribute those in XML format, but I'm happy to use anything really (going to have write code for conversion in any case). Does STM have some equivalent? Doing this by hand from the datasheets is far too error-prone, but I'd really like to use the STM32F4 series in the upcoming tasks.

Best regards,

Johannes
    This topic has been closed for replies.

    4 replies

    frankmeyer9
    frankmeyer9
    Associate III
    August 15, 2012
    Posted on August 15, 2012 at 18:59

    The toolchain provider usually have something like this, to setup a project according the selected controller type.

    Eclipse based IDEs use XML afaik, of Crossworks I'm definitely sure.

    But it might be buried somewhere in the folder tree, and have a layout to suit their needs, not yours.

    johannes2
    johannes2Author
    Associate II
    August 16, 2012
    Posted on August 16, 2012 at 13:24

    But surely the toolchain vendors don't type all the information off the datasheet, or do they? And I would think that all the datasheet data and header files from ST are also generated by some authorative machine-readable document. This is what I'm after. I've actually downloaded Crossworks, but couldn't find any matching XML. Probably in one of the additional packs (which is some encrypted blob if I see it correctly).

    frankmeyer9
    frankmeyer9
    Associate III
    August 16, 2012
    Posted on August 16, 2012 at 13:59

    But surely the toolchain vendors don't type all the information off the datasheet, or do they?

     

    I'm not sure how they do it. It is probably more helpful to contact ST directly, or via a sales representative. Albeit this forum is found under ''my.st.com'', you will rarely find comments from ST people here. I am not.

    I've actually downloaded Crossworks, but couldn't find any matching XML. Probably in one of the additional packs (which is some encrypted blob if I see it correctly).

     

    It is in the CPU support packages.

    The file format is described in the toolchain manual.

    However, this was just a statement that there actually is something you looking for. If it's made by ST or someone else is beyond my knowledge.

    Tesla DeLorean
    Tesla DeLorean
    Guru
    August 16, 2012
    Posted on August 16, 2012 at 17:18

    Keil has machine readable, binary, SFR files. As I recall Rowley had some very nice files as part of their board/chip support packages. And I remember having to correct and port some of those as I worked with some Stellaris chips that were ahead of the IDE support.

    I suspect that most use mechanisms the parse the include files supplied by the vendor, or have one of their myriad staff type in or digest and format into an internally consistent manner. So yes, I'd assume the compiler team do have someone who does this. In Open Source you rely on someone, perhaps yourself, to do this donkey work. I know I've done it myself for several architectures and platforms when I want to absorb them into the tools I build.

    Keil has often used an in source definition method which allows you to configure startup register settings. If these are present a ''Configuration Wizard'' Tab/View appears along side the source.

    Rowley provides it's board and chip support files as ZLIB archives, the tool chain unpacks these when installed.

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    Terms & ConditionsAccessibility statement