On car testing minimal

[RCMast3r]

No description provided.

[RCMast3r]

• ensure that code works consistently on car
• add back in the checks in the state machine for pedal plausibility
• fully integrate actual main
• remove debug print statements
• make tests run

[RCMast3r]

issues we ran into and fixes we made:

• initially pin definitions were incorrect for watchdogs and other safety features so car wouldn't latch

• next, we had issues with SPI as it would get stuck in transferring, this was resolved with moving setting the pinmode of pins into an init function and removing the setting of the pinmodes for the actual SPI pins to let the spi lib control its own pins (except for the clock select pin). The symptom that was seen with this was the ADC would hang in the transferring step of the SPI lib.

• we introduced an error while debugging when we thought that we could fix what we thought was AMS timeout issue with using a millis() call in the CAN receive function instead of using the systick millis however this caused underflow errors which would look like a really big time diff so it would trigger a watchdog timeout. This was unfucked by switching back to systick millis. The actual cause for the issue of not latching fully was electrical as the AMS itself was not able to fully latch (second contactor) as a component on the TSB was not populated.

• The next issue we ran into was dealing with inverter startup and malformed CAN msgs being sent to the inverter. This was remedied and / or caused by either un initialized memory in the CAN msg itself for the MC_setpoint_cmd and we were checking the length of a reference instead of a full copy of a msg which we changed to being a full copy of a message for the writing of the CAN msg to the output queue. This issue was confounding with an error in phase wiring as one motor had phases swapped (right front motor).

• We also switched to rate limiting the send on the inverter interface itself instead of in the drivetrain system with commands. We switched to setting all of the fields verbosely in the setpoints command as well in the inverter interface. Once all of these changes were made the inverters would consistently initialize and get to a state in which they could be commanded

• The thing we fixed was the scaling of the torque limit being set for the motor command as the inverter would error as soon as command would be sent in ready to drive. This was in an attempt to resolve an issue where as soon as we entered ready to drive the inverter would throw a comms error.

• the issue that we are currently still unsure if it is fixed or not occurs when in ready to drive. once disabling software ok check for debugging and disabling pedals check to ensure testing of just the ability to command inverters with pedals data we were able to command the inverters using pedals while our testing harness (Serial monitor and usb to CAN adapter connected) was being used. However when this harness is disconnected it seems that we cannot attempt even to enable inverters.

• We removed print lines in switching into the RTD state as we thought that potentially in outputting debug print we were timing out the comms on the inverter so it would error as the inverter needs constant CAN msgs being sent to it once initialized.

issues that are known right now:

• buzzer on time seems to be inconsistent

potential next steps:

• ensure that we still can get to RTD and command while debug harness is attached.

• if we still can enter RTD and command inverters while debug attached to inverter CAN line and serial monitor to mcu, next is to see if inverters are error while debug not attached

• next is to see if if with just CAN line being sniffed by seeing if we can init inverters when CAN is being sniffed. if we can init, then CAN line is unstable maybe due to load? O-scope will need to be brought out if so.

• if CAN line being sniffed doesnt effect behavior, then it is most likely serial print causing issues. to debug this we can just remove all Serial prints and / or hal_prints.

• if this still doesnt fix the issue and when plugged in we are fine vs not plugged in we arent then it is probably an electrical issue?