ROM_GPIOIntClear and friend Definition

Mau,

I just posted the same question, then searched and found yours ... unanswered.

Did you ever resolve this concern?

John

 On Project property are processor type and family correctly declared?

 Which compiler brand are you using?

PART_TM4C123BE6PZ and PART_TM4C1231D5PM are used and what I intend.

I am using TI v4.9.5

If you compare the two rom.h files in StellarisWare vs. TivaWare, you will find that these two functions are not declared in the latter.

I see dozens of other ROM_* functions not declared in TivaWare's rom.h.  As an example: ROM_I2CSlaveInit.

I use TARGET_IS_BLIZZARD_RA1.  Is that the correct family still?  I see other new BLIZZARD entries.

John Osen said:

I am using TI v4.9.5

 compiler stand alone or part of CCStudio?

 If CCStudio then all setting of the project influence a lot the compiler behaviour so sometimes doesn't work. If you are using latest CCS and compiler is reported as 4.9.5 select 5.4 and upgrade the project.

John Osen said:

I use TARGET_IS_BLIZZARD_RA1.  Is that the correct family still?  I see other new BLIZZARD entries.

 I think yes, there is no clear correspondence thru part name and Target codename.

I am using 4.9.5 within CCStudio.

I truly believe it is not compiler symbol definitions.  The functions simply are not defined in the appropriate rom.c file, nor declared in rom.h.

It looks to me as if this was a victim of the StellarisWare to TivaWare rebranding. When we renamed GPIOPinIntXxx() to GPIOIntXxx(), it looks as if rom_map.h wasn't updated to contain MAP_GPIOIntXxx macros. To work around the problem, just use GPIOIntXxx() instead for now. I'll raise a bug report and hopefully get this fixed in time for the next release.

Well, I just had a chat with the person responsible for the ROM headers and it seems that this can't be changed after all. The way rom_map.h works, it includes macros for all functions which appear in ROM on any Tiva part. Since ROM_GPIOIntXxx() doesn't (yet) appear in any Tiva device and since GPIOPinIntXxx() has been removed, there are no MAP_GPIOPinIntXxx() or MAP_GPIOIntXxx() macros in rom_map.h and there won't be until we have parts in the wild that include the new functions in ROM.

The upshot of this is that you shouldn't expect to ever see ROM_GPIOIntXxx() for Blizzard-class (TM4C123) parts even though they do actually contain a version of ROM_GPIOPinIntEnable/Disable() which is identical to GPIOIntEnable/Disable(). As a consolation, though, a call to GPIOIntEnable/Disable() in flash is actually shorter, in terms of the number of instructions executed, than calling the ROM equivalent. The function implementation is only a single register read/modify/write so the overhead of the double function table lookup to find the ROM API entry point address is likely to be larger than the function code itself.

Dave Wilson said:

It looks to me as if this was a victim of the StellarisWare to TivaWare rebranding.

Collateral Damage caused by this "most necessary - yet never even slightly explained/justified rebrand" - continues in full-force!

And, "this was a victim" avoids the fact that we many - long-term, multiple device users ARE the very REAL VICTIMS - and should not be so minimized nor discarded!

At very least - person you "chatted with (i.e. responsible party)" would have saved many this, "fall-out grief" by simply listing this as an issue - in an effective manner!  And might this suggest that yet more "similar" disconnects await? 

To be found by we users - when in fact (as in the case just presented) - many are known?   

IMHO - NOT the best way to run this silicon railroad...  (even when run on 65-nm tracks...)

As ever, I was merely trying to be honest and helpful. All I can do in this case is offer apologies from the developers on the ground. This isn't ideal, I know.

BTW, as regards apportioning blame, I wrote the migration app note so the fault is mine. I was, however, unaware of this omission until today. I'm pretty sure there there will be other issues like this that are also missed in the document so I will apologize in advance for those. Whenever anything like this comes up, I'm updating the app note and having it reposted as quickly as possible. You should see this issue description appear on the web in a few days.

@Dave W. - you are - and have long been - a most substantial tech-resource for the Stellaris multitudes.  (and I've expressed same - publicly - many times)

And my writing ascribed no blame to you.  That said, "victim - w/out any definition" (your writing) is very much we users - who may have suffered (needlessly) as issue was known - yet not properly (if at all) propagated to we users.

The migration guide has been useful - but minus known, and critical updates/corrections - damage due to many past MCU delays simply cascades.

ARM MCUs are hugely complex - updates are "normal/customary."  Failure to properly/effectively propagate "internally known issues" - perhaps not so much...  (and poster's struggle w/this "known" issue "sat here" - good 45+ days...)

Rebrand group may give some small consideration to the effective propagation of "known tech issues" - which are likely to impact the user base - and are of little benefit/comfort to we users when they remain silent...

I have already made the assumption that the functions were not there for some reason, as to remove them actually required deleting obvious code.  Now that I know that it is actually faster and probably does not really take any more FLASH, than I am very comfortable with the change.

I would mark this thread as answered, if I could find an answer button on the post that answered the original question.

Dave Wilson said:

wrote the migration app note so the fault is mine. I was, however, unaware of this omission until today

 Hi Dave, I fell different point of view, you are pressed to do faster and you don't know what came from pressure so IT isn't your fault.

 About migration, I try'd wrote something about usage of and project creation on ccs forum, I am experiencing very strange troubles when just I cannot find which parameter is wrong and project didn't work. Someone say wrong processor, many unbelievable word, wrong part, the stack issue, I fell like CCS is still work in progress and not to a real stable version. I learned that to have a working environment the only way is to copy a working project, remove all code then import the new sources.

 On survived toolkit I suppose can be useful to do a port of all code from old stellaris board examples to TIVA version otherwise the new user feel too much uncomfortable too and never experiene to be "operative in 10 min or less".

 Thank for all your real help.

Dave Wilson said:

Since ROM_GPIOIntXxx() doesn't (yet) appear in any Tiva device and since GPIOPinIntXxx() has been removed, there are no MAP_GPIOPinIntXxx() or MAP_GPIOIntXxx() macros in rom_map.h and there won't be until we have parts in the wild that include the new functions in ROM.

Can someome with a Tvia part check if the ROM_GPIOTABLE[6] to ROM_GPIOTABLE[11] entries which are missing from the TivaWare 1.0 rom.h and rom_map.h include files are actually in the Tiva ROM.

Given that TM4C123 parts are merely renamed LM4F parts, you will find that the ROM on Tiva devices contains exactly the entries that the LM4F ROM did :-) This will include functions to enable GPIO pin interrupts but, because of the way our automatic header generation system works (it ties a function name to a ROM table position), those functions are not made visible in the latest ROM header files for Tiva.

Hi all,
Thanks for the answers.

Anyway, all of this was clear to me from the beginning.

As I confirmed in my original post, I used the very same processor device and code (before the renaming to TM4C) and the code works perfectly using those functions in ROM.
The problem is that, recompiling with the new library gives an error because those functions disappeared from the include files.

I am pretty sure that the installation of the new libraries on the PC has not wiped out those entries in the processor ROM ;)

So, the questions actually are:

1. Is this a recognized bug in the Tiva headers?
2. Is someone going to fix it sooner or later?
3. Or there IS a real reason for this change?
4. And if yes, what is the reason?

Thanks for your attention.
Regards.

Mau.

Is this a recognized bug in the Tiva headers?

No - this was intentional.

Is someone going to fix it sooner or later?

No - this is the way things will remain.

Or there IS a real reason for this change?

The API names GPIOPinIntXxx were retired in favor of new names GPIOIntXxx. Future parts will add new features here and the old names would no longer make sense. The way we build the ROM headers, a function name is tied to a given function jump table entry so, when the name goes away, the function disappears from the ROM header. Yes, I suppose we could hack the header generation script and add a special case for this but, given that the functions involved are so short and given that the workaround is so easy, we didn't feel that this was necessary.

And if yes, what is the reason?

See above. Again, I know this doesn't seem logical and I know it's not ideal but I'm afraid that's the way it is.

Dave Wilson said:

Is this a recognized bug in the Tiva headers?

 Hi Dave, nothing to do with question but some preventive "wishing".

 - Introduce a wizard setting up project property to Stellaris Launchpad, this can help who like me port old LM3S project to this platform first step

 - Introduce a wizard setting up project property to TIVA Launchpad, this is useful for beginners and as a secure clean second step to move to TIVA library.

 - try automate TIVA library installation and environment setup.

 - remove absolute path reference (C:\somewhere.... is a strange error and nonsense in linux)

 - processor focused first time guide to be operative in a few minutes

  -- specific clean error on wrong usage of library Like <<Deprecated see migration guide>>

 Thank a lot in advance.

Roberto,

  Thanks for the suggestions, Could you provide a bit more detail on some of these?

 - Introduce a wizard setting up project property to Stellaris Launchpad, this can help who like me port old LM3S project to this platform first step

I presume you are using CCS? If so, do you mean you would like to see "TivaWare Project" listed under "Empty Projects" when you select "New CCS Project" from the "Project" menu?

 - Introduce a wizard setting up project property to TIVA Launchpad, this is useful for beginners and as a secure clean second step to move to TIVA library.

I'm not clear on how this is different from the first one. Is it just that this is targeted for the new Tiva Launchpad rather than the Stellaris Launchpad? If so, you should be able to use a new TivaWare project for both platforms (the old launchpad still has a "Tiva" part on it - all we did was change the part number).

 - try automate TIVA library installation and environment setup.

Could you elaborate? Do you mean automate the import of the TivaWare projects into CCS rather than having the user do it themselves? Remember that we support many toolchains and, as things stand today, the TivaWare installer doesn't know anything about the tools you intend using. This could be tricky and would likely involve a big change in the installer which, today, is merely an unzip tool that is capable of showing a license agreement before extracting the files.

 - remove absolute path reference (C:\somewhere.... is a strange error and nonsense in linux)

Where do these appear? There shouldn't be any absolute paths in any project files. The only place I know that you do see absolute paths is when debugging applications linked to the prebuilt libraries. The ARM tools embed absolute paths to the original source files into the AXF output file and the debugger picks these up if you try to step into one of the library functions. The workaround for this is just to rebuild the library on your local machine.

 - processor focused first time guide to be operative in a few minutes

I just took a look at the Launchpad page on the site and sent a strongly worded message to our web development folks since it looks as if we've dropped the ball there (in my personal opinion). The page content is confusing, contains irrelevant portions and completely fails to link to the documentation for the board. In all our previous kits, we had a rule that you must be able to be up and running, developing code, in 10 minutes or less. That's still possible with LaunchPad but only if you know which software to download and install. I'm sure you'll see some improvements here soon.

  -- specific clean error on wrong usage of library Like <<Deprecated see migration guide>>

Unfortunately, I'm pretty sure this is not something we can do. It would likely require the compiler/linker to be aware of deprecated functions and show this warning. Given that TivaWare is considered a new product with no deprecated functions, it's unlikely that you will see this kind of change. You will just have to use the migration guide and realize that you've used a deprecated or changed function by the fact that the linker or compiler gives you an error. If you find anything missing from the migration guide, please make sure to let us know so that it can be corrected.