TM4C1294KCPDT: Re-enable Edge count forced disabled interrupt.

Another interesting discovery free running edge count value (TnV) subtracted from upper bounds (TnILR) producing counts up to the point of vector entry gives (0x0) within the same interrupt context.

Yet the same directives asserted from another interrupt context other than Edge Counts CnMIM hander gives very accurate results until higher frequency priority group interrupts start to assert. It would seem the datasheet is not being entirely factual or perhaps NVIC group INT priorities have issues no one has ever tested for or against running applications. FYI: Edge counts = 211 each CnMIM vector call being very slow to assert NVIC interrupt. So the TnV value should be higher than 211 edges on entry to CnMIM interrupt context, not 0x0.

/* In down-count mode, the current count of the input
 * events can be obtained by subtracting the GPTMTBR
 * or GPTMTBV from the value made up of the GPTMTBPR(prescale)
 * and GPTMTBILR register combination. */

/* Get GPTMTBV free running count value. */
   ui32TBVEdgeCount = HWREG(TIMER0_BASE + TIMER_O_TBV);
/* Get GPTMTBILR start count load value, upper bounds of time out event */
   ui32TBILREdgeCount = HWREG(TIMER0_BASE + TIMER_O_TBILR);
/* Determine accumulated edges counted between INT and ISR entry. */
   ui32EdgeCount =  ui32TBILREdgeCount - ui32TBVEdgeCount;

Hi BP101,

 

BP101 said:

Down edge count mode by design clears GPTMCTL_TBEN bit on timeout, seemingly that design action also Re-Sets CBECINT cleared bit inside CBMIM at the same time.

  I'm not clear with what you are trying to do. This is a edge-count mode. If there is no edges, then the counter doesn't even count. Why will it timeout? The datasheet says:

"After the match value is reached in down-count mode, the counter is then reloaded using the value
in GPTMTnILR and GPTMTnPR registers, and stopped because the GPTM automatically clears
the TnEN bit in the GPTMCTL register."

Therefore, the only time the the TnEN is cleared is when a match happens, not when the timeout happens. I can only image you set the match count equal to the 0 or something very small. 

 

Hi Charles,

Charles Tsai said:

Therefore, the only time the the TnEN is cleared is when a match happens, not when the timeout happens

The point of edge count mode is to count edges of an CCP input signal. So I don't understand why you would think it does not count or timeout even under some odd conditions.

It would seem I should have said match count, not time out. Though it really does not matter, NVIC still ignores CBMIM being set or clear after match count (0x1) invokes a capture event interrupt. Good point of this test (below capture) proves the edge counts remain the same even when NVIC accelerates higher frequency priority along with the capture events in the lower priority group. The down side is the TBILV values decrease with NVIC accelerated handling of the 1st and 2nd context interrupt even with use of GPMT 500ms Oneshot timer. There is no way to guarantee any load count value produces the same Oneshot period into interrupt vectors at all times, so timeouts too are affected. NVIC is causing a fire sale at the expense of GPTM timer interrupt events.  

Proof also TBILR -TBV does produce (0x0) edges counted in the same interrupt context of the configured capture event. Edge time mode also does not produce stable edge times, values are all over the place from the same input signal used to count very same 211 edges. Edge time TnR and TnV are very unstable in the same interrupt context of the captured events, thus remains un-useable to determine edge times from the very same CCP positive edge input signal. Basically all that changes between count/time mode (down count) is TnCMR bit setting, ILR load value and the capture event and matching interrupt clear methods.

Charles Tsai said:

After the match value is reached in down-count mode, the counter is then reloaded using the value
in GPTMTnILR and GPTMTnPR registers, and stopped because the GPTM automatically clears
the TnEN bit in the GPTMCTL register."

Not entirely correct as written since TnILD bit defaults clear on POR the timer will reload TnILR (load count) on next clock cycle. If TnILD bit is set the TnILR will reload on next timeout event. AKA Immediate load update when TnILD bit is clear. Wonder if TnILD bit makes any difference to count = (TnV - TnILR) during CCP capture interrupt event context?

BP101 said:

It would seem I should have said match count, not time out.

Thanks for the clarification. There is a huge difference between match count and time out. If the input is steady state then the counter does not move at all. The whole purpose of the edge-count is to count edges, not to count time from one edge to another in which case the timeout can easily happen. 

Again the point is the datasheet skips over some detail, a timer still times out no mater what mode has been configured. So when a signal is applied to CCP input timeouts will/do occur as down/up counts increments match the set value. If TnILD bit is ignored in edge count/time modes the datasheet must explicitly make such point clear, yet it does not.

The match/capture events masked by CnMIM/TnMIM bits enabling rapidly notify NVIC as timer finishes a previous count cycle. The TnILD bit setting determines when the re-load occurs in any mode. Coincidently a POR sets TnILD bit 0x0 (default) the timer then re-loads (updates) TnILR "immediate" but only after the next clock cycle. So the timer timeout always occurs on event match or event capture interrupts and only sets TnMCINT or CnMCINT bits respectively in either mode.

The purpose for TnILD bit (set) often to stop timer load updates causing electrical disturbance on CCP I/O that may also cause faults, watchdog resets from (Jamming) re-load count values in the middle of counting. Thus PWM CCP output mode is much more forgiving TnILD bit is set especially when producing high frequency PWM. TM3A 500ms Oneshot delay into 2nd context is being jammed even when TnILD bit has been set.

>> I can only image you set the match count equal to the 0 or something very small.

That raises an interesting point if the match count occurs to close to timeout cycle during event matches "even with TnILD bit set (next timeout re-load)" may cause undocumented interrupt issues. Such as CnMCINT re-pends previous preemptions in NVIC before CnMIM has been disabled/re-enabled inside 1st to 2nd interrupt handlers. That would explain why NVIC ignored the enable/disable of CnMIM flags....

BP101 said:

Again the point is the datasheet skips over some detail, a timer still times out no mater what mode has been configured. So when a signal is applied to CCP input timeouts will/do occur as down/up counts increments match the set value. If TnILD bit is ignored in edge count/time modes the datasheet must explicitly make such point clear, yet it does not.

Again, if you meant timeout as a match event then that is fine per your interpretation of what time out is. To me timeout is different from a match event, especially in edge-count mode. If you have a flat line CCP input then the counter will never decrement as there is no detected edge. This is far from timeout as in edge-time mode where the counter keep counting down as soon as an edge is detected. If the next edge never comes then the timer timeouts as it counts to zero without seeing an edge. Below excerpt from datasheet.

After the match value is reached in down-count mode, the counter is then reloaded using the value
in GPTMTnILR and GPTMTnPR registers, and stopped because the GPTM automatically clears
the TnEN bit in the GPTMCTL register. Once the event count has been reached, all further events
are ignored until TnEN is re-enabled by software. In up-count mode, the timer is reloaded with 0x0
and continues counting.

BP101 said:

Coincidently a POR sets TnILD bit 0x0 (default) the timer then re-loads (updates) TnILR "immediate" but only after the next clock cycle. So the timer timeout always occurs on event match or event capture interrupts and only sets TnMCINT or CnMCINT bits respectively in either mode.

I don't understand what are you trying to do. If you want to use edge-count mode then wouldn't you first setup your load count in TnILD to a non-zero value (as in a down count mode) before you enable the timer? Why would you start the TnILD to zero in a down-count mode and then enable the timer?

Please follow as described in the datasheet for edge-count mode. The TnEN is first disabled in step 1 before any configuration is completed. Step 5 to configure the load count and match registers berfore the TnEN is enabled again in step 7.

13.4.3 Input Edge-Count Mode
A timer is configured to Input Edge-Count mode by the following sequence:
1. Ensure the timer is disabled (the TnEN bit is cleared) before making any changes.

2. Write the GPTM Configuration (GPTMCFG) register with a value of 0x0000.0004.

3. In the GPTM Timer Mode (GPTMTnMR) register, write the TnCMR field to 0x0 and the TnMR
field to 0x3.

4. Configure the type of event(s) that the timer captures by writing the TnEVENT field of the GPTM
Control (GPTMCTL) register.

5. Program registers according to count direction:
■ In down-count mode, the GPTMTnMATCHR and GPTMTnPMR registers are configured so
that the difference between the value in the GPTMTnILR and GPTMTnPR registers and the
GPTMTnMATCHR and GPTMTnPMR registers equals the number of edge events that must
be counted.
■ In up-count mode, the timer counts from 0x0 to the value in the GPTMTnMATCHR and
GPTMTnPMR registers. Note that when executing an up-count, the value of the GPTMTnPR
and GPTMTnILR must be greater than the value of GPTMTnPMR and GPTMTnMATCHR.

6. If interrupts are required, set the CnMIM bit in the GPTM Interrupt Mask (GPTMIMR) register.

7. Set the TnEN bit in the GPTMCTL register to enable the timer and begin waiting for edge events.

8. Poll the CnMRIS bit in the GPTMRIS register or wait for the interrupt to be generated (if enabled).
In both cases, the status flags are cleared by writing a 1 to the CnMCINT bit of the GPTM
Interrupt Clear (GPTMICR) register.

When counting down in Input Edge-Count Mode, the timer stops after the programmed number of
edge events has been detected. To re-enable the timer, ensure that the TnEN bit is cleared and
repeat steps 4 through 8.

Charles Tsai said:

I don't understand what are you trying to do.

Hi Charles,

The point of mentioning TnILD being the POR default (0x0) GPTM count behavior does not change no mater what other modes it has been configured. Again the datasheet leaves out important timer re-load details, for instance why TnILD bit would ever be ignored as you seem to believe. 

The timer was being disabled in the edge count interrupt handler cycle/s and enabled in another GPTM delay interrupt context. Yet edge count speed increased as PWM0 drives the DC inverter, but the match count interrupt had always the same value (TnBR). Issue made difficult to understand how same number edges simply speeding up produced varied match counts timing outside the counters interrupt context. CCP input source was not varying above 55Hz but PWM0 higher frequency (12.5KHz) somehow triggers edge counts in the disabled timer. That made it seem as if the re-load TnILR relative to TnILD bit setting was causing electrical issue on CCP input. Not there is a warning in PWM mode section, to this very point of electrical noise on CCP.

Odder yet edge counts still occur even removing input signal CCP and grounding GPIO input pin. And thus makes no sense how CCP edge event counts still occur during disabled timer periods of interrupt events.  

BP101 said:

Odder yet edge counts still occur even removing input signal CCP and grounding GPIO input pin. And thus makes no sense how CCP edge event counts still occur during disabled timer periods of interrupt events.  

Your described behavior is impossible for me to comprehend. With the CCP input tied to ground you are getting a edge count? Can you repeat in the LaunchPad? I really don't know why your system behaves so much different than the LaunchPad. Unfortunately, I have no suggestion to offer. 

Hi Charles,

Charles Tsai said:

With the CCP input tied to ground you are getting a edge count?

Same results occur CCP1 PL5 is being internally triggered when ever two other GPTM Oneshot start counting, 400us and 40us periods. The only logical explanation GPIOPinConfigure() and (pin_mux.h) some how cross links CCPn ports in GPIOPCTL register or digital mux. Otherwise no "excessive" triggered miscount edges occur until other two counters each Oneshot triggered interrupts start to assert. That's why it makes it seem like an interrupt NVIC priority issue, at first look. I find it suspicious the other two timers can have CCPn assignments via GPIOPCTL register, e.g. on the surface architecture of each aperture.

Below notice GPIOPinConfigure() makes the ui32Base = 0x0 for our CCPn decodes. Does it make sense right shift (>>) all pin_mux.h CCPn decodes 16 places for passed ui32PinConfig? Why not simply make ui32Base 0x0 for all decodes? Also as reported by others in forum, SYSCTL_GPIOHBCTL must exist TM4C1294 to select AHB array decodes internal pointers top of gpio.c ports A-J/K-T. The datasheet shows GPIO's with AHB suffix, yet gpio.c omitted ports K-T did not maintain AHB consistency datasheet PinMux Tool and or GPIOPinConfigure() apertures. Seemingly << 16 makes GPTM0B/CCP1: 0xA1403 = 0x00C00000, what is the point of >> 16 shifting 0xA? Perhaps an actual ui32base would be prudent in the later NOT operation that follows below?

I reported to forum 2015 ports K-T omitted AHB top of gpio.c table pointers, may have been added in later versions of Tivaware. That still does not allow GPIOPinConfigure() to select either APB or AHB busses as first elaborated in block diagram, Figure 1-1. Obviously APB still exists next to AHB aperture and BOTH busses connect into GPIO/GPTM peripherals, respectively. 

 

Charles Tsai said:

Your described behavior is impossible for me to comprehend

Yet why does ui32Base = 0x0 for GPTM0B CCP1 (pin_mux.h) 0xA1403 ? How is this a base address for APB or AHB decodes?

void
GPIOPinConfigure(uint32_t ui32PinConfig)
{
    uint32_t ui32Base, ui32Shift;

    //
    // Check the argument.
    //
    ASSERT(((ui32PinConfig >> 16) & 0xff) < 18);
    ASSERT(((ui32PinConfig >> 8) & 0xe3) == 0);

    //
    // Extract the base address index from the input value.
    // 0x0 for all AHB Pin Mux encodings.
    //
    ui32Base = (ui32PinConfig >> 16) & 0xff; //CCP1 = 0xA1403 >> 16 = 0xA, & 0xff = 0xA

    //
    // Write the requested pin muxing value for this GPIO pin.
    //
    HWREG(ui32Base + GPIO_O_PCTL) = ((HWREG(ui32Base + GPIO_O_PCTL) &
                                      ~(0xf << ui32Shift)) |
                                     ((ui32PinConfig & 0xf) << ui32Shift));

Charles Tsai said:

Can you repeat in the LaunchPad

The launch pad was first to exhibit the issue and fooled me that it was partially corrected but it was not. Bad assumption coding on my part and only masked the speeding edge counts issue by reducing precision  >70% in the Oneshot interrupt delay periods. That obviously is not a practical solution when it seems there could also be an analog port AIN16 being plagued by the same GPIOPTCL issue also effecting the frequency of fixed CCPn edge counts.  

The issue seems to come from selecting table entries for ui32Base on the APB aperture, not AHB.  Configuring ports A-J may not set the GPIOPCTRL (REG22) bit field correctly and the digital Mux may cross into the analog realm or visa versa.  

Assumes TM4C1294 does not have GPIO_O_HBCTL register and (else) defaults. Thus selecting APB bus aperture address for any configured ports A-J, do not get a required GPIOPCTRL entry in the GPIO mux. So happens we configure several below port K, yet seem to exist on APB aperture via GPIOPinConfigure() unless patch is made below. Since index 0-20 (ui32Base= 0xA/10) and APB port K has same address as AHB port K and never considered lower ports A-J were selecting APB address from the table below.

//*****************************************************************************
//
// The base addresses of all the GPIO modules.  Both the APB and AHB apertures
// are provided.
//
//*****************************************************************************
static const uint32_t g_pui32GPIOBaseAddrs[] =
{
    GPIO_PORTA_BASE, GPIO_PORTA_AHB_BASE,
    GPIO_PORTB_BASE, GPIO_PORTB_AHB_BASE,
    GPIO_PORTC_BASE, GPIO_PORTC_AHB_BASE,
    GPIO_PORTD_BASE, GPIO_PORTD_AHB_BASE,
    GPIO_PORTE_BASE, GPIO_PORTE_AHB_BASE,
    GPIO_PORTF_BASE, GPIO_PORTF_AHB_BASE,
    GPIO_PORTG_BASE, GPIO_PORTG_AHB_BASE,
    GPIO_PORTH_BASE, GPIO_PORTH_AHB_BASE,
    GPIO_PORTJ_BASE, GPIO_PORTJ_AHB_BASE,
    GPIO_PORTK_BASE, GPIO_PORTK_AHB_BASE,
    GPIO_PORTL_BASE, GPIO_PORTL_AHB_BASE,
    GPIO_PORTM_BASE, GPIO_PORTM_AHB_BASE,
    GPIO_PORTN_BASE, GPIO_PORTN_AHB_BASE,
    GPIO_PORTP_BASE, GPIO_PORTP0_AHB_BASE,
    GPIO_PORTQ_BASE, GPIO_PORTQ0_AHB_BASE,
    GPIO_PORTR_BASE, GPIO_PORTR_BASE,
    GPIO_PORTS_BASE, GPIO_PORTS_BASE,
    GPIO_PORTT_BASE, GPIO_PORTT_BASE,
};

The (else) patch above corrects GPIOPCTL entries for lower A-J port addresses, required for proper AHB calls to GPIOPinCofigure(). Somehow patch quiets the last configured ADC channel AIN16 (PK0). Oddly exactly where the APB - AHB address table pointers splits (J-K). According to the datasheet if GPIOPinConfigure() only access the AHB address range A-J thus the GPIOPCTL can not set bit fields for APB lower index address ranges of TM4C123 ports A-J, that simple. The subject APB-AHB is clouded by misinformation in Tivaware calls to GPIOPinConfigure() and the datasheet figure 1-1.  

Does TM4C1294 datasheet provide accurate and detailed address ranges (GPIOPCTL REG22) and APB - AHB apertures can be controlled or selected as shown in Figure 1-1? Electrical specifications and GPIO text do contradict idea all GPIO or GPTM CCP ports are being forced to use AHB against Figure 1-1 indicating these peripherals can access APB aperture too. If Figure 1-1 is not factual GPIO and GPTM should not be illustrated as still connecting to AHB and APB apertures.

Datasheet text implies REG22 can not use TM4C123 lower APB aperture ports (A-J) from index table pointer top of (gpio.c) for calls made to GPIOPinConfigure(). Again GPIOPinConfigure() and AHB aperture address table lookup ports (A-J) requires GPIO_O_HBCTL register that does not exist in TM4C1294 MCU. Tivaware and datasheet implies GPIOPCTL bit fields are never touched for APB ports A-J being GPIO_O_HBCTL doe not exist. Likewise CCS debug is the last resort to troubleshoot issues not the first line of defense to prove datasheet is factual or not.

Perhaps TM4C1294 datasheet only distorts APB-AHB topic and omits required facts any good detective must have to fix SW issues suspected of causing HW failures?  Perhaps TI had chosen to follow inaccuracy documentation methods to handle these architecture changes?

Hello BP101,

Yes the datasheet is correct. I already commented about your concerns with APB on TM4C129x devices here: https://e2e.ti.com/support/microcontrollers/other/f/908/p/782356/2922470#2922470

I think I understand your source for confusion, and it's regarding the nomenclature of the defines for the GPIO ports where we have defined names like GPIO_PORTK_BASE and GPIO_PORTA_AHB_BASE

The reason for why there is GPIO_PORTA_AHB_BASE through GPIO_PORTJ_AHB_BASE, but then from GPIO_PORTK_BASE and onwards the AHB_BASE tag is dropped is a bit of a historic one.

From what I investigated, original Stellaris LM3S devices stopped at Port J, and the nomenclature that stops at GPIO_PORTJ_AHB_BASE was kept for what I presume (wasn't on the team at the time) for interoperability reasons as TivaWare was originally Stellarisware.

If you look at the defines in TivaWare though, you still see from GPIO_PORTJ_AHB_BASE to GPIO_PORTK_BASE follows the datasheet table exactly:

#define GPIO_PORTJ_AHB_BASE     0x40060000  // GPIO Port J (high speed)
#define GPIO_PORTK_BASE         0x40061000  // GPIO Port K

Hopefully this helps resolve your confusion on the topic and helps you feel more confidence in the accuracy of our datasheets again.

Hi Ralph,

Seemingly you missed my point, GPIOPinConfigure() ports (A-J) left side of table are for TM4C123 addresses and being incorrectly selected to configure GPIOPCTL REG22. Again GPIO_O_HBCTL exists in the TM4C123, so calls to GPIOPinConfigure() default to (else) which incorrectly selects APB addresses from the table in gpio.c that don't even exist in TM4C1294.

It don't matter the pin type was first configured (digital) but we must properly address REG22 for TM4C1294 GPIO's from GPIOPinConfigure() or previously configured pins A-J will overlap the GPIO analog mux. The GPIOPCTL bit field is not being set for ports A-J in the TM4C1294 according to the datasheet ADDRESS MAP disclosure!

Far as Stellarisware is concerned, version 10636 was the last driverlib to support LM3S MCU. Tivaware driverlib is not compatible with LM3S MCU's

GPIO port addresses are not disclosed TM4C1294 datasheet memory map.

hw_memmap.h 

#define GPIO_PORTA_BASE         0x40004000  // GPIO Port A
#define GPIO_PORTB_BASE         0x40005000  // GPIO Port B
#define GPIO_PORTC_BASE         0x40006000  // GPIO Port C
#define GPIO_PORTD_BASE         0x40007000  // GPIO Port D
#define GPIO_PORTE_BASE         0x40024000  // GPIO Port E
#define GPIO_PORTF_BASE         0x40025000  // GPIO Port F
#define GPIO_PORTG_BASE         0x40026000  // GPIO Port G
#define GPIO_PORTH_BASE         0x40027000  // GPIO Port H
#define GPIO_PORTJ_BASE         0x4003D000  // GPIO Port J

Hello BP101,

I thought you had already seen this post from Amit that states we removed that register to make it clear to use AHB: e2e.ti.com/.../1316370

So TivaWare is working correctly and it would not default to the else statement for TM4C129x as you implied, but as Amit stated in a post you already referenced before and saw, the register is not listed in the D/S.

Sorry that I thought you had seen and understood that.

Ralph Jacobi said:

The reason for why there is GPIO_PORTA_AHB_BASE through GPIO_PORTJ_AHB_BASE, but then from GPIO_PORTK_BASE and onwards the AHB_BASE tag is dropped is a bit of a historic one.

The AHB should not have been dropped at port K since it is an AHB port up to port Q. Array table top (gpio.c) posted above is correct for TM4C1294 Address Map as disclosure in datasheet. Why on earth would anyone Symbolically call an AHB port by any other name when it exists K-Q as AHB? Seemingly would not select the correct GPIO PCTL address field from the index. We must add +1 to each shift in the else to specify the higher address ranges in array table for TM4C1294. Again GPIO_HBCTL register does not exist in TM4C1294 so the (if) test will pass on to the (else) and as it was written incorrectly select the lower APB A-J address of TM4C123 posted above.

    if(HWREG(SYSCTL_GPIOHBCTL) & (1 << ui32Base))
    {
        /* The AHB aperture GPIO Base Address for TM4C123 MCU */
        ui32Base = g_pui32GPIOBaseAddrs[(ui32Base << 1) + 1];
    }
    else
    {
        /* Set AHB aperture range for TM4C1294 Class as
         * the GPIO base address in the port array index. */
        ui32Base = g_pui32GPIOBaseAddrs[(ui32Base << 1) + 1]; //[ui32Base << 1]
    }

Analog ports will still seem to work however the digital isolation barrier set by GPIOPCTL and GPIO analog mux will overlap A-J since they were never configured as datasheet GPIO port address map indicates. If the GPIO port address map is incomplete in the datasheet, might explain how TM4C123 APB aperture addresses (A-J) might still function to set GPIO_PCTL in TM4C1294. That kind of deception would not be intuitive way of doing things and wastes may hours yours/ours tracking down CCP internal edge count trigger issues!    

Ralph Jacobi said:

So TivaWare is working correctly and it would not default to the else statement for TM4C129x as you implied

Sorry to disagree but the if test would fail to find or return GPIOHBCTL address bit field from register that is not listed in TM4C1294 datasheet register map.

Ralph Jacobi said:

I thought you had already seen this post from Amit that states we removed that register to make it clear to use AHB

Amit does a double back narrative and others PM me think Amit inferred GPIOHBCTL is read only in TM4C1294 and still not listed in register maps. 

The legal system calls what Amit said in forum post "hearsay" and not considered admissible evidence in any US court. AKA non-sense, hypothetical, anything but factual. If it ain't in writing it don't exist when it comes to microprocessor logic gates, memory addresses or special functions on & on.

Secondly if the SYSCTL_GPIOHBCTL did exits it would be present in CCS debug GEL file as RO memory map address.

#define SYSCTL_GPIOHBCTL   0x400FE06C  // GPIO High-Performance Bus Control

Hello BP101,

Did further testing which has some mixed results. Using a TivaWare build with the driver library directly included to debug driverlib functions, I checked the GPIOPinConfigure API. As I expected, the GPIOHBCTL does return a value, but it has the relevant AHB bits cleared for comparison that is made in GPIOPinConfigure. So I do see at the end of GPIOPinConfigure, it is seemingly configuring register 0x4000.4000. I need to look into this further to understand what happens when 0x4000.4000 is programmed. I am actually off-site today so I will investigate further tomorrow.

What I will say though is whatever is going on, if you see the PORTA_AHB register configuration, it is properly being configured despite the base address not being 'right'. So my suspicion is there is an internal mapping in the device that anything going to 0x4000.4000 is forwarded to 0x4005.8000 and so on for the other ports.

Hi Ralph,

Ralph Jacobi said:

So my suspicion is there is an internal mapping in the device that anything going to 0x4000.4000 is forwarded to 0x4005.8000 and so on for the other ports.

Yet no mention in TM4C1294 datasheet for omitting GPIOHBCTL REG22 or Amit's answer to poster. Poster had TM4C123G code migration over to TM4C1294. However Amit did not mention AFSEL bits and GPIOPCTL via APB seemingly result in low port address overlaps on the AHB. 

Edge counts being trigged internally (GPIOMUX) even when CCP1 (PL5) input is grounded seems to align with AHB/APB aperture issue. Perhaps one or more internal mappings you mention are not correct? We assign all GPIO pins type via AHB nomenclature, Port K-Q were missing Tivaware (v12753/v21171) (hw_memmap.h). Simply added AHB K-Q after reporting in forum (2014) the AHB addresses were missing. Perhaps that defeats the internal mapping you mention might exist? It seemed ridiculous to have some ports without AHB in application when ports are actually using the AHB aperture per Fig 1-1. It seemed a no brainer adding K-Q addresses being TM4C123G text (below table) ports K-Q default to AHB. Why then did Tivaware not include in (hw_memmap.h) the AHB ports K-Q if both MCU class are locked to AHB aperture? Not really important unless somehow the GPIO name matters and the port address map does not.  

Anyway below is the TM4C123G memory map for GPIO ports and the SYSTRL_GPIOHBCTL register review. 

Hi Ralph,

Confirm GPIOPCTL decodes (3) was being set for GPIO (PL5/4) CCP0/1 and (6) for other ports peripherals use. Shared GPIO port L peripherals USB0 (PL6/7) (analog), PWM0Fault3 (PL0) and QEI PHA,PHB,IDX (PL1,2,3) are not suspected as affecting noise sources. However other analog Mux signals somehow cross into digital Mux as the analog voltage level rises just above 1400mV.

Ralph Jacobi said:

anything going to 0x4000.4000 is forwarded to 0x4005.8000

The question in my mind, are imbedded APB bus address translation somehow not enabling AHB digital isolation barrier in GPIO mux? As the GPIO mux signals level rises above 1400mV the digital CCPn mux lines are to easily impacted by other low voltage analog signals. Again Grounding PL5 input pin should stop CCP edge count captures from occurring. Hard to imagine the CCP digital Schmidt trigger would fire so easily even if it reached 500mv.     

 The PL5 input is open collector, originally had external 20k PU +3v3 yet produced the same odd edge count results via internal WPU. Note all analog input AMSEL bit fields are verified correct setting viewed from CCS debug register view.

Perhaps something in the analog area could impact PL5 digital isolation when analog signals rise above 1400mV? The question in my mind "How can that ever occur when analog inputs are proven to be resistant to any signal crossing into digital GPIO mux up to 3v3?"

Anyone would think WPU rail is internally isolated from analog/digital GPIO pin Mux. Perhaps WPU on certain other GPIO pins is a likely suspect how analog signals <1400mV can easily bypass digital isolation barrier in the process? Again PL5 input when grounded still counts edges starting at 49.5Hz and speeds up interrupt counts when seemingly PWM0 12.5Khz or a number of other GPTM/GPIO pins are asserting. The PL5 CCP1 edge counts remain exact number of expected edges yet accelerate with GPIO speeds of other peripherals that begin asserting on the AHB aperture.