What could inhibit PWM control block pins state changes for 150ms or so TM4C1294

BP101 said:

Your several claims of required low pass filtering being external to scope in my view article infers to be required and present in the ADC circuit of your link aliasing definition

Articales cannot infoer anything. They don't imply any such thing either (which is probably what you actually meant).

BP101 said:

DSO better have such low pass filtering built part of horizontal sweeps lower frequency to account of slower ADC sample acquisition hold times.

Nope. First that would require an enormous number of discrete filters, second there is not an obvious filter to use that would be universally acceptable, third the sample acquisition time does not change with sampling frequency.

BP101 said:

Hard to believe any argument (term aliasing) pre existing WW2, might expect such in the vacuum tube era.

And yet you can follow the references and see that it does. Of course the term pre-dates even those where alias is used in quite different contexts.

BP101 said:

NVIC most definitely has control over PWM zero flag interrupt priority

I have never claimed otherwise.

BP101 said:

 another interrupt even lower rank can take focus away from the PWM peripheral.

By definition of the way the NVIC is implemented no. Only exceptions from higher priority groups can interrupt a running exception.

BP101 said:

NVIC priority queuing can only do so much if the application execution cycles repeatedly take focus away from a peripherals pended flags in any closed loop. 

Only if you assign your priorities incorrectly.

BP101 said:

Your aliasing PWM void not valid argument is only half founded

Well it would require someone to overturn the work of Shannon and Nyquist and while there has been some pushing at the edges of it, all that has done is confirm that work. There has been some remarkable achievements but none AFAIK have produced any cracks. OTOH I've not kept up with the field so any eference to the contrary would be interesting.

Robert

BP101 said:

>NVIC does not have a priority. It makes no sense for it to have one. SYSTICK priority is not set in stone either. Depending on how you are using it there is a very good argument for making it one of the lowest priorities in the system, certainly it should be lower priority than those interrupts that occur more frequently.

Disagree - NVIC has local bus priority over (any peripheral) on the MCU local bus

http://www.keil.com/support/man/docs/gsac/gsac_nvic.htm

The NVIC does integrate tightly with the core but as near as I can tell it is never a bus master, as such the question of bus priority never comes up except as a function of the priority of the associated core. In any case the NVIC design would ensure it does not interrupt a higher priority interrupt with a lower priority interrupt.

BP101 said:

SYSTICK timer holds highest of priorities in that it has no priority assignment other than fault handler being SYSTICK exists at the NVIC level!

That's nearly incoherent but I think you mean that the systick priority is not programmable but to quote

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0179b/ar01s02s08.html said:

The SysTick can be polled by software or can be configured to generate an interrupt. The SysTick interrupt has its own entry in the vector table and therefore can have its own handler.

So Systick has it's own entry in the NVIC

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0179b/ar01s02s08.html said:

Interrupt priorities

Each individual interrupt can be assigned a priority level via the Interrupt Priority Registers.

And it appears its priority is programmable

SYSTICK is interrupt 15 and we find on page 104 of the following

Exception Type - Systick, Vector Number - 15, Priority - Programmable (via SYSPRI1

This field configures the priority level of the usage fault. Configurable priority values are in the range 0-7, with lower values having higher priority

BP101 said:

>If - as you claim - a, "Low Pass Filter" should be permanently emplaced - how then would frequencies "above" F0 be displayed?

I hear digital controlled filters were the talk of the day a decade ago.

Non-sequiter

Robert

>So it doesn't have a fixed priority (and indeed FreeRTOS suggests it be given the lowest priority). It doesn't even need to drive an interrupt.

Not sure datasheet fully explains function of SYSTICK masked interrupt vector handler behavior. That is when timer exception occurs the vector address must change to the non-maskable exception address at of applications interrupt priority assignment.

Systick timer is built into NVIC has no interrupt priority assignment for timer time out since it resides in NVIC it PENDS at highest priority for SYSTICK timer expirations, RTOS claim is simply wrong. Datasheet shows INT15 is registered for exception Fault handling of timer errors and NVIC must handle INT PEND of a (non exception) type event interrupt for timer timeouts. Though not directly written NVIC seems to act as bus master of the private peripheral bus and reports bus status errors and faulting memory addresses in NVIC registers. Therefore it perhaps acts as a (logical) bus master and interrupt controller of all peripherals located on the advanced peripheral bus.

Like I stated earlier it don't always matter priority of an interrupt in a single priority grouping, after INTPEND has been serviced the application can divert and later return to finish that same interrupted routine. Reason why SW should disable any interrupt sources that reference the output invert state of PWMENABLE control register or any other interrupt source that might otherwise cause a premature branch. GPTM taco edge counter was interrupting NVIC so often at 2EPS the PWM closed loop was acting very clunky or at times crashing. That edge count timer loop SW rewrite now acts dynamic and matches a variable edge count in the same 1 second one shot timer interval interrupt handler. There you go 2 reoccurring interrupts at a much lower priority were reeking havoc on PWM zero counts during the updates of pulse width periods. So want to go dual core after seeing this NVIC behavior but may be a simpler solution to help NVIC with house keeping tasks outside the closed loop. 

However as it seems that was no guarantee watchdog timeout period being extended by HW beyond the set expiration time if NVIC some how intercepts arbitrates bus control and asserts wait states on any peripheral INT PENDS. Perhaps a good reason to configure more than one interrupt priority group or building several priority groups and levels of interrupts to control NVIC behavior in the application loop. Priority grouping part of datasheet is a bit vague in details of what several priority groups might accomplish for NVIC logical arbitration of the advanced peripheral bus.

BP101 said:

>So it doesn't have a fixed priority (and indeed FreeRTOS suggests it be given the lowest priority). It doesn't even need to drive an interrupt.

Not sure datasheet fully explains function of SYSTICK masked interrupt vector handler behavior

I'm impressed. FreeRTOS doesn't understand how SYSTICK works neither do the users who complain about how the FreeRTOS requirements conflict with another vendors hardware abstraction layer. TI couldn't get it right and even ARM mistakenly thinks that SYSTICK priority is programmable but you, BP, have figured out they are wrong.

I have no doubt you will now be providing a test case so that ARM will realize how seriously they have misunderstood their design and create an errata for the core.

BP101 said:

That is when timer exception occurs the vector address must change to the non-maskable exception address at of applications interrupt priority assignment.

Nope.

BP101 said:

Systick timer is built into NVIC has no interrupt priority assignment for timer time out since it resides in NVIC it PENDS at highest priority for SYSTICK timer expirations, RTOS claim is simply wrong.

You don't actually read the datasheets do you?

BP101 said:

Like I stated earlier it don't always matter priority of an interrupt in a single priority grouping, after INTPEND has been serviced the application can divert and later return to finish that same interrupted routine. Reason why SW should disable any interrupt sources that reference the output invert state of PWMENABLE control register or any other interrupt source that might otherwise cause a premature branch.

Well that's unparseable.

BP101 said:

GPTM taco edge counter was interrupting NVIC so often at 2EPS the PWM closed loop was acting very clunky or at times crashing.

The NVIC does not get interrupted any more than an OR gate does.

BP101 said:

There you go 2 reoccurring interrupts at a much lower priority were reeking havoc on PWM zero counts during the updates of pulse width periods.

Nonsense

BP101 said:

So want to go dual core after seeing this NVIC behavior but may be a simpler solution to help NVIC with house keeping tasks outside the closed loop. 

Sure, why not solve a non-existent problem.

BP101 said:

However as it seems that was no guarantee watchdog timeout period being extended by HW beyond the set expiration time

That should never happen. The watchdog should never be extended, that would be a serious bug.

BP101 said:

Priority grouping part of datasheet is a bit vague in details of what several priority groups might accomplish for NVIC logical arbitration of the advanced peripheral bus.

Actually the documentation is very clear and the APB has naught to do with it.

Robert

>TI couldn't get it right and even ARM mistakenly thinks that SYSTICK priority is programmable but you, BP, have figured out they are wrong.

No TI data sheet indicates INT15 is an exception interrupt and SYSTICK timer timeout is not considered an exception, no error occurred. NVIC obviously polls SYSTICK timers exception flag and vectors into the NMI handler ever STYSTICK rises an exception flag. INT15 priority can be set only for the exception event flag and not the timer expiration vector handler which exists at the highest NIVC priority or above all other priority assignments. If that is not the case the datasheet thus illustrates INT15 being in the wrong place. 

>That should never happen. The watchdog should never be extended, that would be a serious bug. >Well that's unparseable.

You obviously assume M4 NVIC interrupt tail chaining is not capable of being interrupted by NVIC himself trying to service lower priority interrupts that persistently bang on the drum (metaphorical). The datasheet does not give all the conditions that tail chaining might become a condition of or otherwise become non-granular in behavior. That is understandable but don't for one second believe NVIC behavior is written in stone when all inflicting conditions are not spelled out in text of datasheet.

>Actually the documentation is very clear and the APB has naught to do with it.

Disagree as datasheet states NVIC has 8 priority (0-7) levels but does not give CLEAR written reasons how or if grouping helps NVIC retain granularity. Nor does it say at what point lumping all interrupt priority into a single group might interfere with tail chaining. Tiva SW examples only configure 4:4 split IE: priority group 4 : 4 bits of priority interrupt levels 0x00 - 0xF0. Oddly the high order nibble in 4 bits split sets INT priority from the lower nibble of the configured split. Need ideas how to set more groups to keep NVIC smooth tail chaining without interruptions from watchdog timer 0.

Hard to know if by 8 priority levels does that infer groups are constrained in priority order (0-7) and 4 split bits of interrupt priority is constrained by the group level? The illustration half explains the physical group splitting not so much the group priority ordering and seemingly (>> 4)  the INT priority in lower nibble of the split. Very confusing explanation of the split and grouping when more than 1 group might exist.  

>Well that's unparseable.   

Watchdog timer 0 expiration was interrupting so often 150ms timeouts it often bounced IOT connection, even when dog was not being fed. Had to disable the Dog on idle for IOT connection and enable it each motor run time to stop all the interrupt chatter. That seems to be due to the dog INT handler checks motor status even during idle time. So the Watch dog is now set 333ms expiration and that has helped to stop some of the chatter. That directly seems to indicate NVIC tail chaining is susceptible to the time length of application branching and the ability to keep him from normally expiring during idle time.

Watchdog timer 1 is disabled.  

void
WatchdogIntHandler(void)
{
		/* Check if the interrupt belongs to Watchdog-0*/
		if(ROM_WatchdogIntStatus(WATCHDOG0_BASE, true))
		{
			/* Clear watchdog 0 interrupt */
			ROM_WatchdogIntClear(WATCHDOG0_BASE);
			//
			// If the motor is in the running state, fault when this occurs,
			// otherwise, do nothing.
			//
			if(g_ulState & STATE_FLAG_RUN || g_ulState & STATE_FLAG_STARTUP)
			{
			    // Disable all the PWM outputs.
			    PWMOutputOff();

				// Indicate an watch dog fault.
				MainSetFault(FAULT_WATCHDOG);

			}
		}
}

BP101 said:

No TI data sheet indicates INT15 is an exception interrupt and SYSTICK timer timeout is not considered an exception, no error occurred.

Exception and interrupt are generally synonymous. No one suggested an error occurred.

infocenter.arm.com/.../index.jsp

BP101 said:

NVIC obviously polls SYSTICK timers exception flag and vectors into the NMI handler ever STYSTICK rises an exception flag. 

No

BP101 said:

INT15 priority can be set only for the exception event flag and not the timer expiration vector handler which exists at the highest NIVC priority or above all other priority assignments.

There is no such thing as NVIC priority. See

infocenter.arm.com/.../index.jsp

for exception priorities. Note that system exceptions and interrupt exceptions have their own registers for setting priorities.

BP101 said:

>That should never happen. The watchdog should never be extended, that would be a serious bug. >Well that's unparseable.

You obviously assume M4 NVIC interrupt tail chaining is not capable of being interrupted by NVIC himself trying to service lower priority interrupts that persistently bang on the drum (metaphorical).

It's quite clear that lower priority exceptions do not interrupt higher priority exceptions and pose no CPU load. This would be quite easy to prove if  it were otherwise. Just set up a high priority interrupt and have it sit in an infinite loop toggling an output. measure that output and watch for any change as a lower priority interrupt is rapidly toggled.If the lower priority interrupt has an effect you will see the maximum pulse width of the toggle change. This is a very easy measure to take if you want to show that the chip behave contrary to the documentation.

BP101 said:

>Actually the documentation is very clear and the APB has naught to do with it.

Disagree as datasheet states NVIC has 8 priority (0-7) levels but does not give CLEAR written reasons how or if grouping helps NVIC retain granularity.

As I said the documentation is very clear and quite obvious.

BP101 said:

Nor does it say at what point lumping all interrupt priority into a single group might interfere with tail chaining. 

It doesn't

BP101 said:

Tiva SW examples only configure 4:4 split

You do realize that the grouping is fixed in hardware don't you?

BP101 said:

 Need ideas how to set more groups to keep NVIC smooth tail chaining without interruptions from watchdog timer 0.

If you are getting watchdog timer interrupts you have big problems. Tail chaining isn't among them.

BP101 said:

>Well that's unparseable.   

Watchdog timer 0 expiration was interrupting so often 150ms timeouts it often bounced IOT connection, even when dog was not being fed.

From unparseable to nonsensical. If the watchdog isn't fed then you will get a reset. (and what on earth are you doing with an IOT setup on a motor drive? Even if that made sense it's something to be added well after you have the drive working)

BP101 said:

That seems to be due to the dog INT handler checks motor status even during idle time.

What an interrupt does is a function of your code. If you don't know what's in it then it's a wonder anything works. Having said that if the watchdog is feeding an interrupt you've implemented it wrong.

BP101 said:

void WatchdogIntHandler(void) { /* Check if the interrupt belongs to Watchdog-0*/ if(ROM_WatchdogIntStatus(WATCHDOG0_BASE, true)) { /* Clear watchdog 0 interrupt */ ROM_WatchdogIntClear(WATCHDOG0_BASE);

Oh, Good Lord!!! That's bad in so many ways

Robert

>There is no such thing as NVIC priority.

That is a matter of opinion. It is also said SYSTICK has the highest default INT priority in that it exists at the NVIC level in HW, therefore NIVIC alone holds highest nested priority over any peripheral or SW configured interrupt priority. All other GPTM and peripherals are on the vendor advanced bus and not on the NVIC private bus with SYSTICK, that alone says a lot for the argument of a default and highest HW priory level of NVIC as he is the boss.  There is No INT priority SW assignment required for normal SYSTICK timer timeouts having the highest default HW priority of NVIC himself.

>Exception and interrupt are generally synonymous. No one suggested an error occurred.

Disagree -  Exception and Fault are synonymous terms. Silly for ARM to claim an error free INT source when C+++ programmers are being taught processor exceptions are not normal SW flow, rather fault events to capture and write error trap handlers for.

2.3.5 Exceptions and Interrupts
The Cortex-M4F processor supports interrupts and system exceptions. The processor and the Nested Vectored Interrupt Controller (NVIC) prioritize and handle all exceptions. An exception
changes the normal flow of software control. The processor uses Handler mode to handle all exceptions except for reset.

SYSTICK: A SysTick exception is an exception that the system timer generates when it reaches zero when it is enabled to generate an interrupt. Software can also generate a SysTick exception
using the Interrupt Control and State (INTCTRL) register. In an OS environment, the processor can use this exception as system tick.

Otherwise in an non-OS environment Systick priority might behave differently if the INTCTRL register is left intact 0x0 after POR. 

>You do realize that the grouping is fixed in hardware don't you?

Texts states Multiple NVIC Groups are configurable via SW and a group seemingly can be given a priority 0-7. That seems to imply lower level priority interrupts could divert interrupt processing even from a lower level if highly persistent callers are not placed outside the more persistent interrupting peripheral group. There is a reason to have multiple groups and perhaps one is to keep tail chaining granular when lower priority interrupts must be serviced at some point diverting away from higher level priority SW loops when or if that occurs. 

2.5.6 Interrupt Priority Grouping

To increase priority control in systems with interrupts, the NVIC supports priority grouping. This grouping divides each interrupt priority register entry into two fields:

■ An upper field that defines the group priority

■ A lower field that defines a subpriority within the group

Only the group priority determines preemption of interrupt exceptions. When the processor is executing an interrupt exception handler, another interrupt with the same group priority as the interrupt being handled does not preempt the handler.

So you are saying the advanced peripheral bus interrupts are all considered exception level events and handlers even when there is no raised fault event? So why does Only the group priority then determine preemption of  interrupt exceptions? To me that infers only a fault preemption occurs for exception events, could it also infer tail chaining might otherwise be preempted if an exception occurs for all normal interrupts?Terms do matter and calling an exception event normal SW flow interrupt waters down the definition as defined by 2.3.5 above an exception changes the normal flow of SW. Our SW normal flow is mostly nterrupt driven and very little exception fault hanlder driven.

>If the watchdog isn't fed then you will get a reset. (and what on earth are you doing with an IOT setup on a motor drive? Even if that made sense it's something to be added well after you have the drive working).

When dog is not fed he expires normally driving and interrupt each cycle of down counter and reload value, this case 333ms past 150ms in captures. We feed dog only during each pass in the closed loop to keep him from expiring (barking). That's just the way the dog works in a closed loop and dis/enabling dog is the only work around less you have a better solution. The IOT stats of application loop is jumper selectable during POR and not being asserted in these tests other than posting motor stats to a local USB device. Local LWIP TCP stack is moving 512 byte data packets up to motorware GUI in less than 1ms ping returns and minimal traffic results. 

TI has implemented IOT into motorware on the Piccolo controller and that is not by any means nonsensical at 150DMIPS of M4.  Yet IOT requires tight NVIC constraints with a single core processor and configuring Willy Nellie priority assignments in a single group may invite issues with NVIC tail chaining. Granular NVIC chaining infers there is no SRAM push/pop stack manipulation from any part of SW including LWIP, text does not infer non-granular tail chaining behavior will not occur under times of stress. The vendor is not going to write NVIC has chaining limitations based on the frequency of the advanced bus and peripheral interrupt access time behavior when in reality it is clearly the reason for multiple priority groups to exist. No reason is given for the need of NVIC priority groups but if it were a horse I'd lay odds they can help to keep NVIC granular in tail chaining.  

Debug capture below proves Systick (Non OS) does not set bits PENDSV or UNDPENDV in REG56 INTCTRL nor ever post Systick INT15 address in VECTPEND. Likewise it seems very unlikely setting a Systick priority has any effect in Non OS exception handlers. Still don't like the word exception being tied to handler interrupts as that seems to confuse 3 types discussion somewhat. An exception priority can be preempted by higher exception but topic is vague on the required exception condition regarding tail chaining inside sub priority groups that might over ride interrupt exception priority handling. More on that below.

2.5.7: ■ Preemption. When the processor is executing an exception handler, an exception can preempt the exception handler if its priority is higher than the priority of the exception being handled.

■ Tail-Chaining. This mechanism speeds up exception servicing. On completion of an exception handler, if there is a pending exception that meets the requirements for exception entry, the stack pop is skipped and control transfers to the new exception handler.

>You do realize that the grouping is fixed in hardware don't you?

Agree: It appears a priority group becomes fixed after initial configuration as you must have meant regarding (4:4 split) and it seems there can only be one group configured. Also seems REG58 APINT partitions the sub priority into the (lower 4 bits) of INTA,B,C fields in the interrupt priority levels. The priority groups subpriority 4 bit fields are currently all set to 0x0. The INT priority table now has several interrupt handlers configured at the same level indicated by the (upper 4 bits) of the INT priority value with no subpriority order configured other than 0x0. Point is a sub priority 0x0 seems to allow undesired preemption in NVIC when more than one interrupt source is configured to the same physical INT priority level even though physical INT number should control NVIC nesting behavior. Perhaps the sub group priority is allowing an NVIC nesting violation of the physical INT source levels configured inside the same INT priority grouping. Perhaps good reason to stage sub priority levels being the lower physical interrupt number seems non constrained in PENDS to NVIC nesting behavior when priority groups are configured.

BP101 said:

>There is no such thing as NVIC priority.

That is a matter of opinion.

Nope, it's a matter of documentation. There is no documentation at all that I can find that indicates that there is any such think as an NVIC priority.

BP101 said:

It is also said SYSTICK has the highest default INT priority

That's true of the external interrupts as well.

BP101 said:

therefore NIVIC alone holds highest nested priority over any peripheral or SW configured interrupt priority. All other GPTM and peripherals are on the vendor advanced bus and not on the NVIC private bus with SYSTICK, that alone says a lot for the argument of a default and highest HW priory level of NVIC as he is the boss.  There is No INT priority SW assignment required for normal SYSTICK timer timeouts having the highest default HW priority of NVIC himself.

This is nonsense

BP101 said:

>Exception and interrupt are generally synonymous. No one suggested an error occurred.

Disagree -  Exception and Fault are synonymous terms. 

Yep, sometimes they are, sometimes they are not. Most usually faults are a subset of exceptions. This holds true for ARM architectures.

BP101 said:

Silly for ARM to claim an error free INT source when C+++ programmers are being taught processor exceptions are not normal SW flow, rather fault events to capture and write error trap handlers for.

You are confusing C++ compilers which have their own peculiar definition of exception (and BTW it is not synonymous with fault for C++). Unix uses yet another definition for exception. Neither map completely nor cleanly to the ARM definition.

I don't know any manufacturer that claims an errored int source.

BP101 said:

An exception
changes the normal flow of software control. The processor uses Handler mode to handle all exceptions except for reset.

Notice that maps to interrupts cleanly and completely.

BP101 said:

SYSTICK: A SysTick exception is an exception that the system timer generates when it reaches zero when it is enabled to generate an interrupt. Software can also generate a SysTick exception
using the Interrupt Control and State (INTCTRL) register. In an OS environment, the processor can use this exception as system tick.

Otherwise in an non-OS environment Systick priority might behave differently if the INTCTRL register is left intact 0x0 after POR. 

I don't see what point there is here. I also don't see why Systick priority would behave differently if left intact  after power on. I am glad to see you accept that the Systick priority is changeable though.

BP101 said:

>You do realize that the grouping is fixed in hardware don't you?

Texts states Multiple NVIC Groups are configurable via SW

But within the limits determined by the TI HW implementation. Other manufacturers limit to different splits. I have not seen any yet that allow the full range but such may exist.

BP101 said:

That seems to imply lower level priority interrupts could divert interrupt processing even from a lower level

That is directly contrary to what the text states, no need to look for subtle implications.

BP101 said:

Only the group priority determines preemption of interrupt exceptions. When the processor is executing an interrupt exception handler, another interrupt with the same group priority as the interrupt being handled does not preempt the handler.

Yes, that's what is documented and it is the expected behaviour.

BP101 said:

So you are saying the advanced peripheral bus interrupts are all considered exception level events and handlers even when there is no raised fault event? So why does

Now you are starting to catch on

BP101 said:

 Only the group priority then determine preemption of  interrupt exceptions? 

Maybe to prevent stack explosion? It also give the individual implementers a hook to control HW complexity. Which in turn gives a cost/performance trade-off they may find useful.

BP101 said:

To me that infers only a fault preemption occurs for exception events, could it also infer tail chaining might otherwise be preempted if an exception occurs for all normal interrupts?

Wrong use of infer. Still wrong if usage is corrected.

BP101 said:

Terms do matter

Like the difference between infer and imply.

BP101 said:

calling an exception event normal SW flow interrupt waters down the definition as defined by 2.3.5 above an exception changes the normal flow of SW. Our SW normal flow is mostly nterrupt driven and very little exception fault hanlder driven.

No on both counts

BP101 said:

>If the watchdog isn't fed then you will get a reset. (and what on earth are you doing with an IOT setup on a motor drive? Even if that made sense it's something to be added well after you have the drive working).

When dog is not fed he expires normally driving and interrupt each cycle of down counter and reload value, this case 333ms past 150ms in captures. We feed dog only during each pass in the closed loop to keep him from expiring (barking). 

No you don't. You are feeding the dog in the interrupt, effectively rendering it a toothless wind passing mutt sleeping in the corner.

BP101 said:

That's just the way the dog works in a closed loop and dis/enabling dog is the only work around less you have a better solution.

The usual way is to feed the dog in the fastest inner loop (with the time to reset from watchdog timeout some where from 1 to a few times the loop time). More sophisticated methods bootstrap that to check slower loops and yes I do that.

BP101 said:

TI has implemented IOT into motorware on the Piccolo controller and that is not by any means nonsensical at 150DMIPS of M4.

It is when you are debugging the basic motor control. There are multiple issues

• It's too much to attempt to debug at once
• IoT may steal needed resources from motor control, especially if you are doing high performance work such as controlling the PWM cycle by cycle at high rates.
• And of course there is always security, not a small concern

BP101 said:

No reason is given for the need of NVIC priority groups but if it were a horse I'd lay odds they can help to keep NVIC granular in tail chaining.  

I don't even know what you mean by that statement (on multiple levels).

Robert

BP101 said:

Debug capture below proves Systick (Non OS) does not set bits PENDSV or UNDPENDV in REG56 INTCTRL nor ever post Systick INT15 address in VECTPEND.

No

BP101 said:

Likewise it seems very unlikely setting a Systick priority has any effect in Non OS exception handlers.

Since Systick has the same priority structure as all other interrupt source I don't see what you are getting at. I also don't see what you are getting at with NON OS exception handlers. It's certainly possible for an OS to have it's own exception structure (Windows and Unix come to mind) but that seems a little overkill for an RTOS for a chip this size. Could be done though. In any case Systick will have a greater effect of the HW interrupt sources than any OS exception (unless the OS uses the underlying HW interrupts for exceptions which is certainly possible)

BP101 said:

Still don't like the word exception being tied to handler interrupts

Doesn't much matter. We don't get to choose what the terminology is. It generally grows and changes as technology does. Old terms acquire new and additional meanings. New terms gather in older functionality. Welcome to the english language.

BP101 said:

An exception priority can be preempted by higher exception but topic is vague on the required exception condition regarding tail chaining inside sub priority groups that might over ride interrupt exception priority handling.

Not even in the slightest.  The documentation is quite explicit and clear.

BP101 said:

2.5.7: ■ Preemption. When the processor is executing an exception handler, an exception can preempt the exception handler if its priority is higher than the priority of the exception being handled.

Not sure where you are quoting from. I agree that could use a couple of caveats. The problem is those caveats might actually make it harder to understand The two caveats would be

1. The new interrupt must be of a higher priority group (subgroup priority is not relevant)
2. The interrupt priority must be greater than the priority maskiing

BP101 said:

■ Tail-Chaining. This mechanism speeds up exception servicing. On completion of an exception handler, if there is a pending exception that meets the requirements for exception entry, the stack pop is skipped and control transfers to the new exception handler.

That, however, seems clear and complete.

BP101 said:

 The INT priority table now has several interrupt handlers configured at the same level indicated by the (upper 4 bits) of the INT priority value with no subpriority order configured other than 0x0. Point is a sub priority 0x0 seems to allow undesired preemption in NVIC when more than one interrupt source is configured to the same physical INT priority level even though physical INT number should control NVIC nesting behavior.

No. Any new interrupt will not preempt the existing interrupt unless is has a higher group priority. That is clear. The subpriority number allows the NVIC to choose the highest subgroup priority interrupt amoung all active interrupts of the current highest priority. I don't recall how it chooses if there are multiple interrupts of the same group priority and subpriority, generally if you have that situation it's because you don't care which has priority.

BP101 said:

Perhaps the sub group priority is allowing an NVIC nesting violation of the physical INT source levels configured inside the same INT priority grouping. 

There is absolutely no reason to believe that.

Robert

>Since Systick has the same priority structure as all other interrupt source I don't see what you are getting at

■ System Handlers. NMI, PendSV, SVCall, SysTick, and the fault exceptions are all system exceptions that are handled by system handlers.

INT15 is a processor fault exception and Systick is a SVC service handler built into NVIC, INT15 is never asserted for anything but a Systick timer fault condition it is not an normal IRQ exception. We can set INT15 fault priority but not for Systick SVC handler entry or the fixed priority 0 it defaults to. The service handler name is registered under INT15 but never uses an interrupt to enter the handler seemingly by symbolic name only. Again Systick never interrupts NVIC for timeouts via REG56 as one might expect it would in debug register view. Technically we should be able to force a Systick INT15 triggering NMI fault, WR 1 to the STINT REG64 bit 11 TICK bit. Fact is there is no way to directly program or configure any of the processor service INT's 0-15 other than NMI, all are fixed system processor handlers.

The catch phrase "NVIC uses deterministic, fast interrupt processing 12 cycles 6 when tail-chaining.

Point again is lower group priority interrupts have to be serviced by NVIC. If lower priority IRQ's are actively-pending more often than higher priority IRQ's are active at 80us then lower priority IRQ's at 40us likely effect deterministic NVIC time slices. Good enough reason to limit frequency of interrupts from edge count timers when a slower PWMENABLE output time slice at a higher priority should not be interrupted so often.

> also don't see what you are getting at with NON OS exception handlers.

NONOS means processor handlers are not running in thread mode such as RTOS likely uses.

BTW: Our lazy brown dog jumps over the red fox (!POR), auto reloads count during timeout interrupt, never fed a bone in the handler but only in the closed loop he gets a refreshing bone each cycle. So the timer at idle never expires rather passes through the handler persistently on normal timeouts.

More proof Systick INT15 is not used for INT handler entry: Disable (Fault_Systick) priority INT15 and the bits in NVIC_SYS_PRI3  change from 3 to 0.  No matter what priority is assigned INT15 it defaults to internal level 4(Priority 0) after Reset, NMI. TICK bit never indicates activity even at 500ms debug refresh and 10ms Systick interval time.

■ SysTick. A SysTick exception is an exception that the system timer generates when it reaches zero when it is enabled to generate an interrupt  (Unfounded claim). Software can also generate a SysTick exception

using the Interrupt Control and State (INTCTRL) register. In an OS environment, the processor can use this exception as system tick.

BP101 said:

void WatchdogIntHandler(void) { /* Check if the interrupt belongs to Watchdog-0*/ if(ROM_WatchdogIntStatus(WATCHDOG0_BASE, true)) { /* Clear watchdog 0 interrupt */ ROM_WatchdogIntClear(WATCHDOG0_BASE);

BP101 said:

never fed a bone in the handler but only in the closed loop he gets a refreshing bone each cycle.

Stuff and nonsense. You feed the watchdog immediately upon entry to the watchdog interrupt. Very bad practice and directly contradictory to your assertion.

Robert

BP101 said:

No matter what priority is assigned INT15 it defaults to internal level 4(Priority 0) after Reset

So do all the external interrupts.

BP101 said:

■ SysTick. A SysTick exception is an exception that the system timer generates when it reaches zero when it is enabled to generate an interrupt  (Unfounded claim).

You are quoting yourself here.

But let me see if I can find a reference (as you should have). Ah here we go

SysTick

A SysTick exception is an exception the system timer generates when it reaches zero. Software can also generate a SysTick exception. In an OS environment, the processor can use this exception as system tick.

BP101 said:

BP101:
■ SysTick. A SysTick exception is an exception that the system timer generates when it reaches zero when it is enabled to generate an interrupt (Unfounded claim).
Robert:
You are quoting yourself here.

Quote is from Tiva datasheet

The original is but you provided no reference instead just quoted your previous quoting. I had to search to find it since it was clearly not your writing. And unlike you I did provide the reference.

BP101 said:

Quote is from Tiva datasheet and as the debug report above proves Systick exception occurs on timer timeout is an Unfounded claim.

Quite the reverse actually. The fact it comes from ARM provides a high a-priori probability that it is correct. You would need fairly good evidence that it was otherwise to gainsay it. You do not have that.

BP101 said:

The only other possibility is CCS debug is not updating several simulator registers but that should never happen, right?

I seem to recall that the fact that CCS updates take time is something you have run across before. (BTW they are not simulator registers, CCS is reading the real registers).

BP101 said:

Tell me, ARM is making unfounded assumptions about their own processor core in their documentation of that processor core because.....?

You've got to learn how to quote. Those are my words not yours.

BP101 said:

Perhaps ARM link assume OS thread mode is in effect and Systick operational characteristics differ in system handler mode.

No and if you would actually read ARM's documentation you would see that is not so. ARM is describing the core's behaviour. This is the documentation used by people who write OS's and by people who don't need an OS.

BP101 said:

Either way the CCS debug register should indicate if HND_CTRL_TICK bit is being set, even one time but it never toggles.

NO.

BP101 said:

set the HND_CTRL_TICK bit to trigger a NMI fault.

I see no documentation for any bit of that name either in TIVAWare or the ARM documentation. NMI is documented by TI (In the TIVAWare manual) as coming from multiple possible sources but Systick is not amoung them. Google finds no references either.

In any case the ARM documentation is quite explicit that Systick does not cause an NMI. It does cause a regular interrupt (exception if you must, they behave identically) when the Systick timer times out. Also this has a configurable priority and can be disabled.

BP101 said:

Perhaps if we disable INT15 Systick will stop clocking but that opens an another can of worms.

I think Systick auto-reloads so the timer will still count but any results on the timeout won't occur. So if it is set for 10mS timeouts then the 10mS ticks won't get updated. It's very clearly documented.

Robert

BP101 said:

For sake of Pete there is no way to assign a priority to Systick INT -1

If you read table 2.16 you would see ARM disagrees.

ARM does also go into detail about it

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/CIAGECDD.html said:

4.3.8. System Handler Priority Registers

The SHPR1-SHPR3 registers set the priority level, 0 to 255, of the exception handlers that have configurable priority.

SHPR1-SHPR3 are byte accessible. See the register summary in Table 4.12 for their attributes.

To access to the system exception priority level using CMSIS, use the following CMSIS functions:

• uint32_t NVIC_GetPriority(IRQn_Type IRQn)

• void NVIC_SetPriority(IRQn_Type IRQn, uint32_t priority)

The input parameter IRQn is the IRQ number, see Table 2.16 for more information.

...

System Handler Priority Register 3

The bit assignments are:

Table 4.23. SHPR3 register bit assignments

Bits	Name	Function
[31:24]	PRI_15	Priority of system handler 15, SysTick exception
[23:16]	PRI_14	Priority of system handler 14, PendSV
[15:0]	-	Reserved.

It's all referenced from the links I keep giving you to ARM's documentation

BP101 said:

Can't view or find system exception INTS in CCS debug. Again Systick holds the highest priority over any other GPTM, that is my reference to the NVIC priority level being a timer but of higher non-settable priority order.

That's not a reference that's a claim that one does not exist. I've several times and again above given you references that show it is configurable.

BP101 said:

Again Systick holds the highest priority over any other GPTM

Nope, and again the documentation (and the usage by others) says otherwise.

BP101 said:

Robert:
Systick is configurable then it follows it must be maskable, and therefore not NMI.

BP101: In great belief after this post Systick INT15 exception flag rises for the benefit of OS thread mode but will cause an NMI fault trap if no fault handler is assigned to INT15.

Sigh, learn how to quote.

Nope, you cannot get away with not defining a vector. Now you might assign it the same vector as you assign the NMI vector but that does not make it an NMI interrupt.

However, since you are actually using Systick, you have assigned a vector since otherwise it would not be working. Check your interrupt table.

BP101 said:

BP101:
TM4c1294NCPDT Datasheet:
2.5.3
■ System Handlers. NMI, PendSV, SVCall, SysTick, and the fault exceptions are all system exceptions that are handled by system handlers.

OK, that's a naming convention TI is using that ARM does not appear to share. It is, however, from all appearances just a naming convention. The exceptions still require a handler, it's still the same kind of interrupt/exception call. There is nothing particularly special about them.

Robert

Robert:

However, since you are actually using Systick, you have assigned a vector since otherwise it would not be working. Check your interrupt table.

BP101: Agree Systick INT source -1 appears to be separated in HW from the processor system fault exception 15 handler used for the Systick timer errors. Perhaps for good reason an OS primary tick source and an NMI recovery HW can arrest Systick hard fault condition without crashing OS into PANIC state. After discussing all this recently disabled NMI source in the vector table to Reserved 0 since PD7 is ANI-4. Agree Systick stops working removing name vector from table but that don't mean the timers fault exception 15 is not separate from INT -1, after all you said both are synonymous terms INT/exceptions. 

Robert:

Nope, you cannot get away with not defining a vector. Now you might assign it the same vector as you assign the NMI vector but that does not make it an NMI interrupt.

BP101:

Ok see the problem I used word NMI to describe the system Fault exceptions, those 9 exceptions being not configurable in my mind makes all NMI but TI calls them exception Faults (below). We have assigned a fault handler to all system exceptions accept Systick 15 in vector table. The other odd thing TI used IRQ # value to assign priority to all peripherals But.. used fault exception 15 to configure Systick priority assignment. Though it seems the priority is assigned to the exception Fault 15 but not INT-1 as all other peripherals are configured by the INT source and not the system exception number like Systick. 

Please explain why CCS debug register view continuous refresh fails to toggle (Systick Fault Exception Active) bit, ARM claims directly controls fault exception 15 with INT -1. Again it was very odd TI used fault exception15 versus INT source -1 to configure Systick handler priority. That alone makes a great argument for exception fault 15 being uniquely separate from Systick INT-1 and system exception fault priority assignment.

Does NVIC REG64 (NVIC_HND_CTRL_TICK --- Systick Exception Active) bit ever toggle in your CCS debug register view ?????

Regarding capture CH2 pulses take on an AC sine wave shape (1 sec sweep) in repeating Ch1 voids. Perhaps AC sine wave (60Hz) is crossing into PWM generators from INA282 current monitors and causing an analog disturbance in PWM peripheral silicon. Dawns on me 3 phase motor #12 gauge wires cross over top an 110v AC power generator source. Typically the magnetic field of generator stator remains internal and 1/4" of cast Iron surround the stator entirely shielding it but is not yet grounded to earth.  This condition might be an 60Hz RF signal though very strong indeed, will post a capture of AC sine wave shape.

//*****************************************************************************
//
// The following are defines for the fault assignments.
//
//*****************************************************************************
#define FAULT_NMI               2           // NMI fault
#define FAULT_HARD              3           // Hard fault
#define FAULT_MPU               4           // MPU fault
#define FAULT_BUS               5           // Bus fault
#define FAULT_USAGE             6           // Usage fault
#define FAULT_SVCALL            11          // SVCall
#define FAULT_DEBUG             12          // Debug monitor
#define FAULT_PENDSV            14          // PendSV
#define FAULT_SYSTICK           15          // System Tick

BP101 said:

Still the CCS debug register view is a simulator (copy) of the peripheral/MCU registers data values being updated by the Trace Macrocell (SWO).

Simulation is "not" a, "Simple copying of MCU Registers."   How do you "come to" such conclusions?

Myself/others would benefit from learning just,"How you've enabled - and harnessed - the Trace Macrocell - and done such via SWO?"   Does not SWD (still) over-challenge CCS?   Again - which documents support today's "reaches?"

BP101 said:

Robert:

However, since you are actually using Systick, you have assigned a vector since otherwise it would not be working. Check your interrupt table.

Learn to quote. Damnit, you seem to make a habit of making things difficult for others.

BP101 said:

Robert:

However, since you are actually using Systick, you have assigned a vector since otherwise it would not be working. Check your interrupt table.

BP101: Agree Systick INT source -1 appears to be separated in HW from the processor system fault exception 15 handler used for the Systick timer errors. 

Nope. There is no interrupt for systick timer errors, there are no such errors detected.

BP101 said:

crashing OS into PANIC state

That is an OS specific term. I rather doubt you are using an OS that has a PANIC state.

BP101 said:

Perhaps for good reason an OS primary tick source and an NMI recovery HW can arrest Systick hard fault condition without crashing OS into PANIC state.

That is gobbledygook. Your fault and fantasized recovery do not exist.

BP101 said:

After discussing all this recently disabled NMI source in the vector table

NMI cannot be disabled. That is its existential flaw.

BP101 said:

Agree Systick stops working removing name vector from table but that don't mean the timers fault exception 15 is not separate from INT -1, after all you said both are synonymous terms INT/exceptions. 

I think you managed to contradict yourself within two sentences. Quite a feat.

Exception #15 and Interrupt -1 refer to the same entry in the interrupt table. If you are not going to read the references you should at least glance at the table I copied from the references for you. This is very clear and very explicit. I don't see how you can claim otherwise without deliberately misreading the table.

BP101 said:

Robert:

Nope, you cannot get away with not defining a vector. Now you might assign it the same vector as you assign the NMI vector but that does not make it an NMI interrupt.

BP101:

Ok see the problem I used word NMI to describe the system Fault exceptions, those 9 exceptions being not configurable

There are only three non-configurable exceptions Reset, NMI and hardfault. The rest are configurable. PendSV and Systick are the ones I would expect it might be worth changing priorities on.

I don't see why you might change the priorities on the others but I suspect someone, somewhere has a case where it makes sense to do so.

BP101 said:

The other odd thing TI used IRQ # value to assign priority to all peripherals But.. used fault exception 15 to configure Systick priority assignment.

Not so odd, exceptions that are not part of the external interrupt list have a separate method for setting up priority (I have not checked the addresses to see if they might be made to match in SW) so using a different setup to setup priority is hardly surprising.

BP101 said:

Please explain why CCS debug register view continuous refresh fails to toggle

The flag would be on normally for what, maybe 1/10 uS? Every 10mS? So a duty cycle of 0.001% Assuming the read is uncorrelated with the systick clock you've a 1 chance in 100000 reads to catch a 1. So an expectation value of once a week or so watching it 24/7. This was explained to you previously, in another context. Or to put it another way aliasing pops up again.

BP101 said:

That alone makes a great argument for exception fault 15 being uniquely separate from Systick INT-1 and system exception fault priority assignment.

Nope, Nope, Nopity, nope, nope. No. At best it's a non-sequiter.

BP101 said:

Does NVIC REG64 (NVIC_HND_CTRL_TICK --- Systick Exception Active) bit ever toggle in your CCS debug register view ?????

I don't use CCS

I have no idea what NVIC_HND_CTRL_TICK is and neither does google. Whatever it is, it's apparently of your own invention.

BP101 said:

Regarding capture CH2 pulses take on an AC sine wave shape (1 sec sweep) in repeating Ch1 voids.

These voids exist as the result of an invalid measurement. If they exist after proper filtering of the incoming signal then you will have something to search for.

Those voids are as real as  Percival Lowell's Martian Canals.

Robert

Not sure what you are talking about needing to learn how to quote, you did the very same thing several times, name (:) etc... You even quoted your own quote a few times no big deal, post hacking?? Perhaps you are not reviewing quotes on the forum webpage (required) and are using email to cut and paste responses from, (very wrong).  Perhaps try to keep reply response message short as possible, no need to answer every single point (less is more). I have no disillusion you CB1 are a brilliant engineers though try to keep an open mind not all is as it may be written or as it may be perceived by the human brain. Ever watch brain teasers show on TV ?? that has opened my perception to question everything my eyes tell my brain it just perceived. 

Obvious you didn't bother to look at the NVIC debug registers I posted above and are baffled by (NVIC_HND_CTRL_TICK). In my opinion If you are not using CCS or one of the TI supported IDE debug engines you really should not be responding to this Systick issue in such contrasting detail.  

Robert: The flag would be on normally for what, maybe 1/10 uS? Every 10mS?

Ok but my argument is that several other GPTM 5-10ms interrupts are toggling normally in same CCs debug, yet system exception 15 (NVIC_HND_CTRL_TICK) never toggles. TI needs to keep consistent behavior in CCS debug register simulator or there is no real truth to any of it that includes ARM knowledge base links. Again TM4C1294 uses an M4 core not M3, many of the links referenced M3 core not M4. Please confirm Non-OS SW platform (NVIC_HND_CTRL_TICK) activity on your TM4C1294/123 launch pad before disputing what is occurring in CCS debug register view.

Robert: Nope. There is no interrupt for systick timer errors, there are no such errors detected.

Agree at this point they appear to be separate. You don't know the architecture of the silicon and are making unfounded assumptions that your knowledge of the M4 core is accurate based on literature that might not be updated or is even flawed. Again there are two modes M4 core (thread & handler) reason for OS several times Systick behavior likely is not the same in either modes. The RTOS might flag PANIC if an Systick 15 system handler exception occurs but not via INT-1 rather it perhaps can raise an exception 15 flag through HW OR's access wired into exception 15 alone. That's the way it appears to indicate Systick function in CCS debug. BTW you can disable NMI from the vector table by removing NMI INT handler replace it with (0, Reserved) and disable PD7 NMI.   

Robert: These voids exist as the result of an invalid measurement.

Perhaps not and with reasons you are not considering such as BLDC motor regeneration can cause current bursts and not effect DC bus voltage ADC readings. The logical explanation is the AC generator driven by the BLDC is pushing momentum back into BLDC rotor and SW compensates by rapidly adjusting PWM duty cycle. The rotor speed change is not of the BLDC or SW origin and reverse current is produced in the phase coils disrupting PWM. Your wrong in this case that aliasing is causing AC sine wave like current bursts and that even shows up at 100ns though is less revealing to the human brain.

BP101 said:

Obvious you didn't bother to look at the NVIC debug registers I posted above and are baffled by (NVIC_HND_CTRL_TICK).

BP101 said:

Not sure what you are talking about needing to learn how to quote, you did the very same thing several times, name (:) etc... You even quoted your own quote a few times no big deal, post hacking??

Nope, If you look you will see that my quotes have boxes around them. This is important because it not only tells you where the quote starts but where it ends. To do this you just highligt the section to quote and click on the quote link. If you click on that link w/o highlighting you quote the whole article. From there become obvious how to mark up sections manually when quoting from manuals etc...

It doesn't deal well with nested quotes, I'll have to try a manual work around at some point.

BP101 said:

Obvious you didn't bother to look at the NVIC debug registers I posted above and are baffled by (NVIC_HND_CTRL_TICK). In my opinion If you are not using CCS or one of the TI supported IDE debug engines you really should not be responding to this Systick issue in such contrasting detail.  

Chester's nicely found the actual name, I'll take a look at it separately. However Systick is not CCS specific. so I feel no qualms about commenting upon it.

BP101 said:

Robert: The flag would be on normally for what, maybe 1/10 uS? Every 10mS?

Ok but my argument is that several other GPTM 5-10ms interrupts are toggling normally in same CCs debug, yet system exception 15 (NVIC_HND_CTRL_TICK) never toggles

Yes but there are a couple of points upon that. First there is the question of synchronization, just because you do see something does not mean it's predictable that you must see it. Second, remember our aliasing conversations. The point of aliasing is not that signals will not be present but that they will not be meaningful. With sampling like this with aliasing then if the signal varies you can say it varies but you cannot say at what frequency, but if it does not vary you cannot that it is constant.

BP101 said:

TI needs to keep consistent behavior in CCS debug register simulator or there is no real truth to any of it that includes ARM knowledge base links. 

It's perfectly consistent, it reads whatever happens to be in the register at the time of reading.

BP101 said:

Again TM4C1294 uses an M4 core not M3, many of the links referenced M3 core not M4.

I took some care to always reference the M4 version of the documentation but please point out the ones that are not and we can compare the two. I would expect them to be the same since the M3 and M4 share a lot in common in this area but any differences could be important.

BP101 said:

Please confirm Non-OS SW platform (NVIC_HND_CTRL_TICK) activity on your TM4C1294/123 launch pad before disputing what is occurring in CCS debug register view.

I have not disputed what you are seeing only your assertion that it will present a filtered version of reality rather than what is occurring when it is reading the register.

BP101 said:

Robert: Nope. There is no interrupt for systick timer errors, there are no such errors detected.

Agree at this point they appear to be separate.

Well, that's a response that ignores the original sentence. There are not two separate interrupts there is only one. There is no indication anywhere that there should be an error interrupt, just the timeout interrupt. You are inventing interrupts that do not exist.

BP101 said:

You don't know the architecture of the silicon and are making unfounded assumptions that your knowledge of the M4 core is accurate based on literature that might not be updated or is even flawed.

Considering that

• The referenced literature is the only valid source of this information (direct from the developer)
• The developer actively updated the documentation
• It is confirmed by other literature that makes use of the functionality
• No one ever mentions it working in any other fashion other than you
• There is no experimental evidence it works in any other fashion

It hardly appears either unfounded or inaccurate.

BP101 said:

Again there are two modes M4 core (thread & handler) reason for OS several times Systick behavior likely is not the same in either modes.

There is absolutely no reason to believe this. You have presented to evidence for it and the existing manufacturers documentation states otherwise.

BP101 said:

The RTOS might flag PANIC if an Systick 15 system handler exception occurs but not via INT-1 rather it perhaps can raise an exception 15 flag

INT -1 and exception 15 are the same thing. INT 0 and exception 16 are the same, int -14 and exception 2 are the same. See the earlier references. You are inventing behaviours that do not exist and for which there is neither evidence nor reason to suspect exist.

BP101 said:

That's the way it appears to indicate Systick function in CCS debug.

Oh? How? Quite frankly I don't believe you.

BP101 said:

BTW you can disable NMI from the vector table by removing NMI INT handler replace it with (0, Reserved) and disable PD7 NMI.   

That doesn't disable NMI it sets its vector to point to the start of memory. It's also an invalid vector which probably results in a bus fault or maybe usage fault if it fires. Disabling PD7 removes one source of NMI, there are others. I do consider TI's use of the NMI a weakness but that doesn't change the essential characteristics of an NMI.

BP101 said:

Robert: These voids exist as the result of an invalid measurement.

Perhaps not

No perhaps, they are invalid by definition. It would not be hard to make valid measurements you just need to add a filter to your probe. You seem strangely resistant to making meaningfule measurements.

One thing to note again about these scope shots you keep showing. They contradict your assertion that there are missing pulses, if there were no pulses both channels would show a gap, only one does.

Robert

Chester Gillon said:

Obvious you didn't bother to look at the NVIC debug registers I posted above and are baffled by (NVIC_HND_CTRL_TICK).