nerdoug
commented
3 years ago modified my board so that DRV1 fault pin (also known as Vdd due to backwards compatible drivers) now connects to cpu physical pin 5, gpio 26. To enable correct symbol redefinitions, define the symbol avoidEspLed in the line before the huzzah32 include statement. (huzzah file has also been modified.) no longer getting any fault counters. Maybe it's my imagination, but the motors seem smoother.
Will use motor command to do a 10 minute test, then will change Vref to 1.1 to see if I can induce faults. But first I do a git merge, which will include some updates docs.
va3wam
The right side DRV fault counter seems to increment whenever there is activity on either motor. I've verified Vref is 0.85 on both DRV's, swapped them and get same result: faults being counted for the right side DRV when either motor is activated. Need to verify the associations between DRV 1 & 2, left and right, and physical and GPIO pin numbers used for fault interrupts.
From circuit board silkscreen info, and continuity testing on the board:
DRV2 is the one closest to a corner of the circuit board DRV2 connects to the motor on TWIPe's left (same as amber pushbutton) (above are correctly documented in SB7D-stepper-wiring.odg) DRV2's fault pin connects to GPIO pin 32, physical pin 20 on the CPU DRV1's fault pin connects to GPIO pin 13, physical pin 25 on the CPU (above is correct in huzzah32_pins.h) (I've added more info to sb7D-pinouts-CPU.ods) reviewing the source code
the gp_DRV2_FAULT gpio pin is attached to the leftDRV8825fault ISR, which is correct that ISR correctly increments health.leftDRVfault above is correct for the DRV1 / right as well the right eye display routine (actually in updateLED() ) outputs 3 numbers on the 4th line, separated by stars: percent time in MQTT routines, health.leftDRVfault, health.rightDRVfault it's the last number that's incrementing, i.e. the one for DRV1, right side, GPIO pin 13, physical pin 25 So, the faults don't follow the physical DRV chip, but are always reported for DRV1. I don't see any software bugs that would cause incorrect fault counting. Thus I turn to hardware causes, and I see notations in several places that using GPIO 13 may conflict in some way with the onboard LED. I think 13 was used due to circuit board layout constraints before we started using a double-sided layout.
I'll investigate possible board mods to move the DRV1 fault line to a different CPU pin. Candidates are: GPIO 26, physical 5 GPIO 34, physical 7 (input only pin, but that's OK) GPIO 36, physical 9 (input only pin, but that's OK)