External ADC triggers from PWM pins locks sequencers, random POR results.

BP101 said:

Something bad is happening to cause POR of the MCU.

You determined POR from the reset register? You're not getting any brownouts?

BP101 said:

Tested 1k ohm between PWM/GPIO inputs reduced frequency of POR events. The PWM pins routed to GPIO are also shared by FET gate driver input. Suspect random spikes are flowing back into GPIO ports strike the ADC trigger. Spike does not seem to effect the PWM peripheral,  only the ADC trigger initiator is inflicted. The 1k resistor adds considerable roll off PWM edges, adding higher R value may further distort edges and real time events.

I wouldn't suspect feedback through the driver, especially at first. More likely, considering you are in a hard switching power environment, is induced voltage spikes on the transitions. The resistor is either slowing the edges either reducing the dE/dt and dB/dt or damping the induced voltage.  These spikes can be quite narrow < 1nS.

Have you 'scoped for the spikes?

Note these can affect an A/D input directly (I have seen this happen). What is your input filtering on the A/Ds? How close is the charge storage/freewheeling capacitor to the actual IC input?

You could add a similar high frequency filter to your drive output.

Robert

BP101 said:

opted again for 1k and set GPIO pin strength 4ma. That seemed to improve things quiet [sic] a bit

Mon ami - is not that pin strength confined ONLY to GPIO when set as Outputs?   (we think so!)   So it is doubtful that you improved - quite a bit - if at all - via that ploy?   Shouldn't you make a series of well controlled measurements - rather than forming (another) opinion upon (not much beyond) a "hunch?"

If it were me - feeding MCU's PWM pin back into GPIO INPUT (which I concede IS clever) I'd use the closest GPIO pin possible - and NOT route to a "conveniently "unused" GPIO (more distant) - as I suspect you are doing.   We happen to feed our Analog Comparator Output "directly" to PWM Fault Input pin - which is TWO pins away!   Such greatly reduces unwanted, "pick-up" of undesired spikes/transients, et. al.

Thank you, Sir - that is as (most) thought here.

Appears that our originating poster's initial "surprise" was correct - and his (new) belief that "drive strength" impacted GPIO (as Input) is incorrect.

Poster's statement, "that becomes apparent" was (apparent) to FEW others (i.e. none) here!   

Well yes - but STILL - the claim that "GPIO Pin Strength" affects GPIO Input (which was only vaguely supported..."somewhere" on the forum) needs to be negated as it may cause others to have similar - "INCORRECT understanding."

My suggestion of employing the shortest, most direct pcb routings intended to lessen any such motor effects.

I fear that KISS is not (much) in play - and w/all of the patches & extensions to original RDK code - poster is experiencing effects too numerous & fleeting to properly detect & note.   By disabling the motor - employing power resistors in its place - and "spoofing" hall signals - poster may eliminate (or at least markedly reduce) any motor caused noise.   I'd always (and only) introduce the motor AFTER all other (proper, lower level) testing had been logged & completed...

Perhaps you, Robert, Chuck, Source_2 & I must all download that video - pause it - and then reveal the "broken" PWM_B. That too may be the cause - isn't that true?

Hi Amit,

And why are other posters in past informed such that sinking strength is equally important? This poster rewrite of Tivaware pin strength as an optional added attribute (ui32PinConfiguration) back fired, compiler inability to know the difference just dropped the pin strength attribute. Seemingly GPIO pad strength has push/pull or sinking/sourcing PAD current direction control over the GPIO pin. That has been stated on occasion this very forum.

Hi Amit,

>The sinking strength of the IO in input mode has got nothing to with the drive strength control. The Drive strength control comes into picture when in output mode.

Odd that a 2k resistor 1.6ma drive strength would not drive the fast GPIO trigger pin the same as a 1k @3.2ma and both produced a 400mv signal floor, 3.2v ceiling. Table 27-7 states 300na maximum (required) for high level and -200na low level maximum so 1.6ma is well above 300na and it should also have worked well.

I particularly distrust manipulating registers with clutter hanging in syntax. Recall another poster asking or suggesting this very question (input pin strength) and received a response quite opposite. Said to myself that sounds plausible the MUX PAD has control over current strength both in and out.   

>Also it is not clear nor there is any example code that you have published which shows that the MCU faults by reading the FIFO.

I had decided to replace all existing HWREG direct reads of sequencer FIFO data to fill array[x] and in some cases ADCSequenceDataGet worked well. On the other hand it faulted repeatedly during processing multiple sequencer steps that had interrupts in each step. It also faulted with (END | IE) last step only while in the same interrupt handler. It may be the order of processing the FIFO for the interrupting (sample step) read back was not always an absolute sequence order 0-1-2..... That seems to be the only difference in how the array is being mandated.

// On immediate direct load of sequencer step 0 into a static array.
g_pusADC0DataRaw[0] = HWREG(ADC0_BASE + ADC_O_SSFIFO0);

// Indirect array linked to a local or global declared static array 
ROM_ADCSequenceDataGet(ADC0_BASE, 0, g_pusADC0DataRaw);    

BP101 said:

There is a 470uf electrolytic 0.1uf ceramic on the B+ of motor power

You need additional protection between the motor supply and the board supply (unless you are driving a tiny motor).

Robert

Hi Mr. Adsett,

They are both powered via same 24v supply and caps are on the bridge high side. The TM4C launch pad is powered via buck down 5v switcher. Might post a picture of the test rig bit later. A dongle PCB connects the motor bridge to TM4C1294  for debugging SW and trying to fix a difficult dead band issue. 

Robert Adsett said:

You need additional protection between the motor supply and the board supply (unless you are driving a tiny motor).

Not sure what exactly you are referring additional, there is a 38v MOV across 24v supply rail plus a high current Schottky diode in series  to low voltage switcher.

>You need additional protection between the motor supply and the board supply (unless you are driving a tiny motor).

That seemingly an understatement is such cases of HW inflicted anomalies no WA in the world could possibly correct.

The Varistor is brand new clamps 180amp surges. Even more interesting is the phase drive PMW trapezoidal peaks reach high as 46 volts are filter by the 200v 470uf low ESR electrolytic. Blue cap next to that, a 0.27uf poly film and 0.1uf ceramic closer to the +24v/GND input terminals. The rainbow ribbons have signal/gnd/signal/gnd.... spacing.

The same ringing pwmB surges were present in LM3S8971 motor RDK , same full bridge piggy backed on top RDK run voltages high as +185v.  A custom PCB is mostly finished but awaits the results of SW/HW debug if that is even possible. Always put the horse before the cart extending bridle/whip only when safe.

The current surges the INA detects seem to emanate from micro shoot through improper pwmB pulse width and PWMnDBFALL register not producing programmed width changes. Have you ever heard of any dead band timings and or shoot through NOT subjecting FET to disastrous results 1/2 bridge hardware? This may be odd out of place reverse current flow through FET body diodes, di/dt lasting less than 20ns is best guess.

You were partially correct that current surges seem to be impacting the 24v DC supply.

The point being made is the FET peak diode recovery seems to be occurring in the wrong places. The dead band drive signals pwmA/B are offset and shifted by the value in PWMnDBFALL register instead of being aligned. The symptom gets worse as motor speed is increased, dead band generator pwmB timing is then truncated as shown several posts above.

The truncated pulse was being created from jamming PWM generators CMPB. So pwmB was actually found to be passing through untouched dead band generator when ever pwmA RED was added to it's pulse width at the very same time.

https://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/533844

Past testing results LM3S8971 with same 3 phase motor firmware is now producing abnormally high voltage artifacts TM4C1294.  

>Your actually running PWMs though that cabling??

Not only that rainbow (Signal/gnd/signal/gnd/signal--etc..) same inverter bridge on TM4C1294 LP started out on top of an TI motorware RDK and was powered by +165 volts using FOC sensorless commutation. 

The fix for this issue GPIO external triggers was to simply don't do that. Sounds funny but it wasn't necessary to uses external ADC triggers from a secondary set of GPIO input pins.

Simply configure existing PWM generator control block pin state changes also present GPIO MUX as external  ADC trigger initiators. So the external GPIO trigger initiator is buffered internally by MUX keeping it away from any and all outside interference.

Very surprised no one suggested to do this instead of triggering ADC external GPIO and detecting edges PWM low pins as the post inferred.

 GPIO MUX ADC trigger initiator driven by PWM control block:

    /* Configure GPIOADCCTL REG23 0x530:
     * Make PWM out pins as trigger initiators ADC0 SS1.    
     * GEN1-3 produce LO side real time triggered samples.
     * Assign the ADCEMUX  2nd highest priority to ADC SS1. */
    ROM_ADCSequenceConfigure(ADC0_BASE, 1, ADC_TRIGGER_EXTERNAL, 1);//PWM1

    /* PWM-LO Phase A ADC trigger initiator source edge event */
    ROM_GPIOADCTriggerEnable(GPIO_PORTF_AHB_BASE, GPIO_PIN_3);
    /* PWM-LO Phase B ADC trigger initiator source edge event */
    ROM_GPIOADCTriggerEnable(GPIO_PORTG_AHB_BASE, GPIO_PIN_1);
    /* PWM-LO Phase C ADC trigger initiator source edge event */
    ROM_GPIOADCTriggerEnable(GPIO_PORTK_AHB_BASE, GPIO_PIN_5);