SYSCTL_PERIPH_COMP1 for TM4C123GH6PM MIA in TivaWare v2.x

Well - that's not good!  Following is cut/paste from aged, StellarisWare 9453:  (used w/our LX4F & TM4C)

#define SYSCTL_PERIPH_COMP0     0x10100100  // Analog comparator 0
#define SYSCTL_PERIPH_COMP1     0x10100200  // Analog comparator 1
#define SYSCTL_PERIPH_COMP2     0x10100400  // Analog comparator 2

Thus - old accommodated your desire (and beyond)...

Those defines reside w/in sysctl.h.  One hopes this offense is mere, "AWOL" - "MIA" subjects offender to harsher punishments...

Hi,

@cb1, the o/p complained about Tiva 2.1.xxxx - and indeed is something weird - here it is what I can find out in file driverlib/sysctl.h:

#define SYSCTL_PERIPH_COMP0 0xf0003c00 // Analog Comparator Module 0

Petrei

Edit: In Tiva v2.0 still defined as:

#define SYSCTL_PERIPH_COMP1 0xf0003c01 // Analog comparator 1
#define SYSCTL_PERIPH_COMP2 0xf0003c02 // Analog comparator 2

Maybe is an omission...

Petrei said:

Edit: In Tiva v2.0 still defined as:

#define SYSCTL_PERIPH_COMP1 0xf0003c01 // Analog comparator 1
#define SYSCTL_PERIPH_COMP2 0xf0003c02 // Analog comparator 2

Oh yes, you are right. I must have missed that one while changing between the TivaWare versions. So it is 2.1 that is missing the defines. (I changed my original question to make that clear).

Does anyone know what is the official way to report such a possible bug? And will TI act in a timely manner on bug reports? ;-)

@Petrei,

Indeed I noted poster's version & type complaint.

You/I can do nothing in that regard.  Thus - I checked & reported that define he seeks was/is "alive/well" w/in our past copy of StellarisWare.  (9453) 

Our group continues to "just" use StellarisWare as it has long been proven robust - and has avoided many/most (all?) of the hiccups in the newer library releases...

Please tell me if I've addressed your concern...

What mystifies is the (fairly drastic) change of address between past StellarisWare & newer 2.1.  I can report that our analog comparator - both on LX4F and on TM4C - behaves correctly using the address as provided w/in past StellarisWare...  As the parts (LX4F - TM4C) are claimed to be, "identical" I can only suspect that "either" address will work - or that only a "segment" of the address is employed for the address decode...

cb1- said:

Please tell me if I've addressed your concern...

Yes, I understand my options are

• Define the macro on my own for TivaWare 2.1
• Go back to TivaWare 2.0 or TivaWare 1.1
• Go back to even older StellarisWare. And you are right, there are a lot of problems in TivaWare. (And don't get me started on PinMux ...)
• Try COMP0 instead
• Go back to just using registers, and no driver library at all

cb1- said:

What mystifies is the (fairly drastic) change of address between past StellarisWare & newer 2.1.  I can report that our analog comparator - both on LX4F and on TM4C - behaves correctly using the address as provided w/in past StellarisWare...  As the parts (LX4F - TM4C) are claimed to be, "identical" I can only suspect that "either" address will work - or that only a "segment" of the address is employed for the address decode...

It worries me, too. The problem would be ROM_SysCtlPeripheralEnable(), wouldn't it? The library version SysCtlPeripheralEnable() might be implemented differently between TivaWare and StellarisWare, but the ROM version? It either must be able to handle both address versions, or the MCUs aren't identical.

I guess I just have to try.

Tmas said:

It worries me, too.

Vendor will (likely) withdraw my monthly stipend (T-shirts/mugs) - but I believe you're smart to enable such worry.  StellarisWare had long proven effective, stable...robust!  Rebrand exercise appears to have severely challenged - and several enhancements were attempted - not all succeeding...

You out-think me w/your observation re: ROM vs. Flash code.  In our App - we used Flash for the analog comparator - but not by any agreed plan - (as best as I can tell.)  Experimentation should fairly quickly/easily demonstrate, "how or if" one or both work. 

Possibly of interest/value to you - we employ that on-chip analog comparator to monitor the current drawn by a 3 phase BLDC motor.  Should that current exceed an adjustable preset - the comparator's output "trips" the PWM Fault input - immediately killing all 3 phase, PWM drive signals.  (we employ a DAC for current trip-point - and direct connect comparator out to PWM Fault In.) 

This works extremely well - enabling, "Cycle by cycle" PWM current limiting - which far surpasses the, "One and done" method employed  by the past, BLDC-RDK.  (that past method killed the MCU operation - requiring a system reset!)  Our method enables many (most) faults to "self-clear!"   Now - when the current "trips" - the PWM ceases - and thus all nuisance trips are essentially, "No harm - no foul!"  And - once SW initializes - this process is SW-Free!

Our group sells to several large firms - they will not allow our migration from the "known good" (past) driver library to the present one - which evidences a number of, "growing pains."  (and appears you've discovered a newly launched one - which is particularly unsettling...)

Hello Tmas,

There are 3 Analog Comparators in TM4C which are at the same base address and can be configured using different registers and in some case different bits of the same register. To enable the clock to the peripheral there is only one define of SYSCTL_PERIPH_COMP0.

That is why in TIVAware 2.1.0 the other two defines have been removed as they are not needed.

Regards

Amit

Amit Ashara said:

That is why in TIVAware 2.1.0 the other two defines have been removed as they are not needed.

Thus begs the (obvious) user/specifier question - "Were those 2 other defines ever (past) needed?" 

Recall that multiple defines for such were long present.  And - as we've been told that LX4F are the same as TM4C - something seems (pardon) "Not quite right!"

Helo cb1,

When using the older RCGCx scheme it may have been used. However in the new RCGCACMP scheme it was not required and it was SW correction that needed to be done.

Regards

Amit

Hi,

@cb1,

I have no doubt your micros work OK - I just warned that if the new 2.1 version will be used, you may be in trouble. Looking the code I can see the followings:

a) for the missing definitions - they must be replaced with the single "SYSCTL_PERIPH_COMP0", despite the module number;

b) although you need only one comparator module, all existing will be enabled (I wonder if a non-existing one will produce side-effects…);

Regards,

Petrei

Hi,

Digging more into user manuals, seems to have a change in how the modules/comparators are managed:

while in Stellaris you have control (on/off) on each comparator in a comparator module, in this new version there is only one comparator module, with all comparators enabled by a single command, so the software is counting for module, not the comparator number.

Petrei

@Petrei,

We earlier noted some "set-up strangeness" w/Comp_0 - but it has continued to perform to spec some 2K+ boards into our contract.

Your caution is very valuable - and most appreciated, Petrei.  Thank you.  In our case - we cannot migrate to the new library as (client & we believe) there are too many unknowns and the older StellarisWare had long passed, "Test of time & usage."  Your highlight of the (potential) for side-effects - brought about by this change - is super.  We noted some past "incompleteness" in the function listings for analog comparators. 

I would state that the, "simultaneous enabling of multiple peripherals" is not especially comforting.  (especially so when such fact is not well highlighted!) Our past LX4F and TM4C - both under StellarisWare - do not see their comparator buddy, "become group enabled" - unless we (rather deliberately) order up that behavior...  One hopes that there exist other means to prevent unwanted effects caused by this new, "3 for price of 1" (unsought/unwanted) complication...