Page Comparison

Date

Individual

Progress

Concerns

sept. 18

Jess

Got CANable adapters working, updated smoke_mcp2515 firmware so it works now.

verified mcp2515 works on MCI rev 5 that has the CANable adapter soldered to it.

Questions:

• is steering rev 4 ok to validate on?

• where are all the power supplies? how long will the aux battery last?

CANable adapter should probably not be soldered to the board in future. Also had to sacrifice a system CAN terminating resistor in the debug process, sorry

Blockers:

• missing pedal

• missing steering stalk + steering rev 5?

sept 21 - 9am

Aashmika + Kristen

• we went in and put away aashmika’s stuff and organized a bunch of boxes

• looked for pedal

• could not find pedal → thinking someone on the team maybe took it home?

• found steering stalk and steering board (dont remember rev, but it’s attached to the stalk)

sept 25

Jess

Figured out how to connect steering stalk to rev 4, tested some firmware

• not much of it worked 😞

• returned MCI box (including aux battery) to the rest of the boxes

• Put CANable adapters in the firmware box on the shelf next to the wire rack

• Will have to do some work to fix firmware for steering? or at least work to figure out where all the gpio pins go

Oct 11

Jess

Found source of CC DECR not working on steering. We implement interrupts in firmware using the STM32 external event input interface, which only has 16 lines. We set this up in firmware so we can register an interrupt on each pin number, e.g. PB1 and PA2 works but if you register PB1 then PA1 registering for PA1 will fail.

The regen button and the CC on/off button still don’t consistently trigger interrupts.

ADC values for CC on/off are consistently ~1600, with no noticeable variability when the button is pressed. The interrupt never triggers.

ADC values for regen toggle are ~1600 when the button is unpressed, then they jump to ~1800 when the button is pressed. Occasionally the interrupt triggers, but not consistently.

To have minicom ADC and interrupt logging, use branch soft_151_steering_validation and project debug, so make program PROJECT=debug

Couldn’t find the center console board.

Tried switching cables for driver display, but it seems pretty busted.

• does this mean we need a new steering rev?

• Where’s the center console board? it wasn’t in the box above the microscope

• Driver display is probably broken, it’s supposed to work out of the box with windows. Tried a different HDMI cable and tried various computers, but banding occurs no matter what. Last thing we could try is a different power supply, otherwise I’m in favour of sending it back and claiming warranty.

Oct. 12 🦃

Jess

===== DAY =====

Tested MCI with a bugfix from MPXE validation, the flow for setting drive output → getting pedal commands seems to work now.

Precharge used to flip PB0 properly, but not PA10 (I was told this was because it only flips PA10 if the relay is connected, which it wasn’t, so this was expected behaviour).

Now, precharge doesn’t seem to flip either, but this is under progress by hardware at the moment so hopefully will be fixed soon.

Aside from that, MCI counts as validated.

===== EVENING =====

Steering: decided it’s not worth fixing it in hardware (too many jumpers required), but stuff sorta works intermittently. Functionality confirmed in firmware, but need to fix up actual project to work in all functionality. Decided DRL toggle is the lane assist button (PA6) and horn (PB1) pin needs to change to allow CC DECR (PA1) to have an interrupt.

MCI: drive fsm + pedal → mcp2515 output flow all works. Precharge logic being validated by hardware.

Power distro: learned how to set it up for testing, will work on it tomorrow w/ Ryan.

Power select: things seem ok, seems like there’s a lot of problems in hardware. Some preliminary test results shown below:

Readings for pins with the front power distro wires hooked up to e-load @ 0.5A (12 volts shown) and aux power wires hooked up to power supply & 12V.

=============== rand# 971464216
DIGITAL:
VALID_1 - 1
VALID_2 - 1
VALID_3 - 0
DCDC_FAULT - 0

ANALOG:
DCDC_I - 458
DCDC_T - 0
DCDC_V - 1817
PWRS_I - 602
PWRS_V - 1532
AUXB_I - 0
AUXB_T - 0
AUXB_V - 2259

Oct. 13

Jess + Aashmika

Worked on power distro, work is on branch bts7200-messs

• ADC driver is broke AF, fixed by adding a volatile bool while while ing rather than using the flag that’s cleared in the IRQhandler.

a different way to fix it that doesn’t involve any volatile variables would be to use 
while (!ADC_GetFlagStatus(ADC1, ADC_IT_EOSEQ)) 
then not clear the EOSEQ bit at the end of the irq handler 
and instead clear it after the while loop
it looks to me like ADC_ClearITPendingBit and ADC_ClearFlag do exactly the same thing

Problem was the load switches couldn’t handle eload in constant current mode and were overload protecting (greater than 500 mA @ 12V for example). Putting eload into constant resistance mode allowed load switch to work consistently.

Also added initialization to pin on PCA9539r to set it properly.

We might have destroyed U6 and U5 from the overloading with constant current mode as they are constantly enabled now. We also shorted a controller board (3v3 or 12v) and it died. RIP.

Aashmika cries. Couldn’t work on MCI.

Oct 14

Jess

Power selection, working on branch soft_151_power_selection_validation. Aux Vsense was already calculated to be approximately right. Tested aux isense, seems correct with a conversion factor of 10/3, i.e. (mA drawn) = (mV read) * 3.333333

The “valid” signals work for aux and DCDC, i.e. they’re all 1 except valid_3 when aux is plugged in, and all 1 except valid_2 when dcdc is plugged in.

Thermistors didn’t seem to be populated.

Power distro, working on branch bts7200-messs. Got ricky to solder on an extra wire to both channel 7 and 3 bts7200s, got what seemed like reasonable readings from both. Gonna call power distro done validation for now until the elec mockup.

Oct 15

Jess + Aashmika + Ricky

Driver Display: did some setup on raspi, working on getting flutter-pi running. Got stuck at a missing header issue, filed an issue on github, the dev is pretty active so should get a response soon. Display itself works well from a power supply, draws ~.6A at 5V.

Precharge: Having problems with precharge and testing to see what could be the issue. Checked fets Q2, Q4 and Q5 all working fine, trying to figure out how the SR latch works. Checked to see if the capacitor is connected to the board and it is connected. Testing the And_out (yellow), reset pin (blue), and SR latch output (purple).

Evening shift: Got the driver display app running on the display, steps here: Driver Display setup

Oct 17

Jess

Tried to talk to new motor controllers. Note: LAWICEL slcan dongle must be used, can’t use peak-can dongle. The old software we were using for the WaveSculptor 20s doesn’t seem to work; it connects but doesn’t seem to read messages and can’t upload/download configs. I suspect the old version of the software isn’t compatible with these controllers. I submitted a request for the newer version of the software through the ‘contact us’ page on their website since the software isn’t listed there.

Candumping using karl ding’s old dbc file on github https://github.com/karlding/wavesculptor-22-dbc (with device id changed to 0x400 rather than 0x80 via kvaser DBC editor) gave some output.

Next steps are hopefully wait for tritium to give us the new software, otherwise reach out to other solar car teams / post in the solar racing reddit to see if anyone else has a copy of the software. Do we have any contacts at tritium?

Oct 24

Hewitt

Worked on figuring out why MCP2515 smoke test isn’t working on MCI rev. 4. Wasn’t working on the MCI rev. 5 either, but loopback tests passed on the MSXII charger interface board.

We’re also not communicating with the MCP2515 on the MCI rev. 4 (registers read either 0 or 255 before and after trying to change them), but other two boards seem to be working okay in that regard. MCP2515 SPI connections should be identical across all boards, so seems like the rev. 4 one isn’t working.

Since it seems to be working, will try to get the charger interface board connected to the WaveSculptor 22 CAN bus tomorrow and start looking at getting readings from it + figuring out whether the MCI is sending all CAN messages at once.

Oct 25

Selina + Jess

I2C communication not working with ads1015 on pedal board (failing at i2c_write). It was working last time though, before the two potentiometers were soldered on.

Also tried to run the smoke test for bts_7200. It’s working on the power distro board when running from the bts7200-messs branch, but not from master, so it’s definitely just a firmware issue. We created a new branch off of master called soft_151_power_distro_validation , and are currently working on migrating relevant changes from the bts7200-messs branch so that it can get merged eventually.

Oct 25

Hewitt

Got MSXII charger interface board connected to the WaveSculptor CAN bus. It didn’t seem to be receiving messages when running the MCP2515 smoketest, but was sending messages fine. Flashed MCI FW to the board and verified that it can see CAN messages; it consistently stops calling both velocity and bus message CBs once it gets a bus measurement message. Will look into figuring out the cause of this and look into manually triggering MCI CAN messages tomorrow/later on in the week.

Additionally, looks like the WaveSculptor is sending all the update messages at the same time, so we’ll need to look into ways to make this work with the MCP2515.

Oct 26

Jess

Found another pedal board in the box, so since the ADS1015 is fried on the original one we’re using, Ricky is porting the connectors to the working one. We fried the old one because the potentiometer used was shorted, so now we’re just not connecting the grounds on the pots for the new one. Didn’t get to check it worked fully, but it should work.

Oct 26

Aashmika + Ricky

Precharge:

• After much testing for several days (lol) found out that the weird spike on 12V_ISO_SW was caused by by the cap that turns the fet q10 to temporarily turn on, which causes iso_latch out to go high and latch high even when 12V_ISO_SW is GND (when the cap is charged + the 12V from latch out is high and since its a latch this makes sense why it stays 12V on the output). I took out C25 and found that it no longer latches! which is good because it wasn't supposed to since I did not even connect HV in.

• Now I connect 37V to the HV in of the board and see that everything works up until Q2 which doesnt turn on because there is -2.2V at the gate wrt source. Looking at the datasheet, James and I believe that we need to have it at least at -4.5V to turn on, so we will change R13 to be 100k. I will do that tomorrow and see if it works out

AFE: Soldered on the duraclik and microfit connectors, also fixed two ICs that was soldered on the wrong way

Pedal Board: Soldered the two potentiometers onto the board for the 3V3 and potentiometer pin but not the ground pin

DCDC and Power Distribution: Soldered on the connectors that has easy connections

Power Select: Soldered the two thermistors onto the board

Oct 27th

Aashmika + Ricky

Precharge:

• replacing r13 with a 100kohm for the purposes of testing with a 37V supply turned Q2 on but for some reason the motor controller hv was not charging (it seemed). After probing around a few rails and looking at how in- was at 0.55V while in+ was at 2.36V, we found that D2 was on the wrong way. After more validation, we saw that there was a 14V drop on the charge resistors, making the capacitor charge to 23V instead of 37V. We found out that the charge pump output was 0V even though ISO_12V was high. We then realized that this is due to the charge pump also being populated the wrong way. We then took a good look at the board to make sure everything else was populated correctly, and cleaned the board of all it’s flux. We then tried again and saw that precharge and discharge work, but the in+ node was still .5V for some reason. We then found out that D7 was also backwards. After fixing that, we now see that there is 1.8V on in+ meaning that it still won’t close. We noticed that it does latch when the in+ node is then probed on the lower side of r12, when it is a floating probe. It’s werid because this only seems to make it latch after a delay after probing voltage with a ground. If we just use a floating probe after iso_12v goes high, it will latch when we place the probe. We took off c19 and saw the same problem. We will remove/replace U7 tomorrow, unless we think of something better. Note that the voltage on the cap is 37.2V and it seems to be charged, it’s just that the in+ node is technically at 1.9V until I guess we give it a floating probe.

Oct 27

Hewitt

Worked on figuring out the issue with the MCP2515/WaveSculptor. The MCP2515 driver doesn’t have functionality to set the RTR bit when TXing, which is needed to request a message from the WaveSculptor, so we’ll need to implement this.

Generally, the issues seem to stem from the filter configuration on the MCP2515. The current MCI FW uses generic_can_register_rx to configure CBs for WaveSculptor messages, but I don’t think this actually configures the filters on the MCP2515, so every CAN message still gets loaded into the MCP2515 buffer. After directly using the mcp2515 driver to configure the two filters to have one correspond to the velocity message ID, and the other to an ID unused by the WaveSculptor, the velocity messages were consistently processed. The mcp2515_filter_debug branch on GitHub contains a working implementation of this.

It seems like the MCP2515 issue where it would only receive a few messages and then stop calling the CBs happens when multiple CAN messages are received at the same time. This is consistent with previous behaviour where we’d sometimes see multiple speed rx’s before seeing a bus measurement rx and eventually failing, since the WaveSculptor seems to send ~4 speed rx’s at around the same time, then a delay, then one of every expected rx at the same time.

When testing with the config on mcp2515_filter_debug, I was able to send a few messages using the CANable with an ID of 0x1 (the unused filter mentioned above); a few of these got processed before the CBs stopped getting called.

It seems like the MCP2515 supports 6 filters total across both rx buffers, so it might make sense to look into adding this functionality to the driver if/when we get the current filter issue resolved.

Oct 28

Ricky

AFE: fixed the led on the board and checked all components to make sure that they are in the correct direction

MCI: I fixed LED4 and Q8 to be in the correct direction now. Found one last U7 left in the MCI Precharge box

Battery Module Connector: I have soldered all of the 14pin connectors on the 30 boards

Oct 28

Hewitt

Continued work on MCI: wrote mcp2515_set_filter in mcp2515.c to allow for changing the MCP2515 filters after initialization. Working on mcp2515_filter_debug branch, implemented a (really rough) way to iterate through the filters after a CAN message is received for each one. This works with the wavesculptor, so we just need to modify mci_broadcast.c to work with this implementation.

Looked into requesting status messages by sending a CAN message with the RTR bit set, but I couldn’t get an implementation that didn’t stop working after getting a few messages (similar to earlier MCP2515 issues), so leaving this for now.

Oct 28

Jess + Selina

Worked on soft_151_pedal_validation. Found out the channel might be 2 and 3 instead of 0 and 1 from the schematics, but before we could test those, i2c started failing. We realized the board was getting really hot so we stopped messing with the ads1015. We determined that the board gets really really hot even if you just flash controller_board_blinking_leds and stick the controller board on it, so it’s not ads1015 specific. The board doesn’t heat up if the controller board isn’t on it.

Oct 29th

Aashmika + Ricky

Precharge

Precharge now works! Latching and precharge + discharge sequences were scoped and matched expected function. We also put on the other connectors on MCI for the power train testing. See precharge v5.0 testing document for more information.

Pedal

Found that the 3V0 pedal regulator is dead on the original pedal board. Replaced it with the reg from the other pedal board, but this regulator seems to only output 1.25V. Note that the other board has a short from 3V3 to GND which is not a priority fix. 1.25V is not enough for the operating conditions of the ADC, so I will look for a replacement. Ricky also crimped the input pots so they can go in the pedal connetor. After replacing the IC, communication works once again! Now with the pots in place, both pots give readings of 3-1486 depending on the turn.

Power Distribution + Precharge: Crimped power and ground wires from the PD and put the wires into Precharge to give power

Power Distribution + Power Selection: I connected the power supply from the power selection to the power distribution

Power Selection + DC-DC Converter: Soldered the power and GND wires from the power DC-DC Converter to power selection

Oct 30 🎃🎃🎃🎃

Jess + Selina + Ryan (remotely) + help from Aashmika

I saw a black cat walk into the bushes right outside the windows in the atrium. I’m fairly sure I wasn’t tripping but you never know? Felt very seasonal.

Box: Discovered running a test on hardware can sometimes give a python error in GDB (unsure?) about importing module usb in select_programmer.py. Discovered you can just press enter to skip the error and it’ll work correctly.

Pedal: Hardware values changed for the ADC channels we’re using; we’re now using channel 0 for throttle and channel 1 for brake. Also discovered a bug where if the pedal potentiometer is very large, rollover can occur in the output (INT16_MAX rolling over to negative numbers). Fixed by changing the math (shoutout Selina for carrying that part) to divide by EE_PEDAL_VALUE_DENOMINATOR as the last step. Branch is soft_151_pedal_validation.

Power Distribution: Some things weren’t set up properly in smoke_bts7200, so Ryan took care of fixing it up to be usable. We tested with the lights driver board as a load and were very confused by fluctuating readings, but it turned out that board fluctuates in load significantly past a certain brightness. We switched to the E-load and things were consistent. We did some more math (thanks Ryan for showing the desmos linear fit trick) to determine a more accurate conversion from the ADC converted reading to an actual current from the bts 7200s. Put the now working smoke_bts7200 on branch soft_151_bts7200_validation, Ryan will work to port changes to the actual power distro project.

Oct 30

Aashmika

• Found some extra microfit crimps from our previous stock and used it to attach all the buttons to center console

• Cleaned the pads on updated current sense and fitted it into a shunt resistor (started taking off the old one from the previous shunt to salvage the expensive component but did not finish)

• Made the can to MC harnesses x2 (1M long twisted cables with power and CAN lines with microfit and duraclik connectors on either ends)

• need to fix the center console power connector eventually

Oct 30 + 31 🎃

Hewitt

Worked on getting MCI fully functional. There’s something it doesn’t like in cruise control (specifically, when cruise_command = 1 in prv_cruise_command_rx) that causes it to not see any messages, so I still need to get that sorted. The branch get_mci_output_working has a fully working version (aside from the cc issue), the soft_353… branch has a version that should be pretty much the same but stops seeing messages from the wavesculptor after a bit, so I’ll need to fix that as well.

I also need to test these changes on the actual MCI board, I’ve been using the MSXII charger interface to communicate with the motor controller so far but there shouldn’t be much of a change, if any.

Overall MCI will hopefully be good to go by EOD tomorrow, since I assume, if worst comes to worst, it isn’t a huge deal if we don’t have cruise control working for the powertrain mockup.

Nov 1

Hewitt

Continued MCI work. MCP2515 is still kind of wonky, sometimes after flashing it won’t see any messages at all but will work fine after power cycling the board. Either cruise control or precharge FW was causing the issue with it not seeing messages, so I’m leaving both commented out for the powertrain mockup.

Switched from the charger interface to MCI boards and the MCP2515 stopped seeing/sending messages on the CAN bus. The CANable is still able to pick up messages on the bus, and when testing the driver it appears that SPI is working OK; additionally, I probed the CAN connections directly on MCI and they’re working as expected.

I also ran the MCP2515 smoketest and didn’t see its messages on the bus. The smoketest failed to pick up any messages in loopback mode, which (probably) indicates an internal error to the MCP.

One other note: the MCI MCP’s 3 tx buffers fill up after the first 3 tx messages the smoketest tries to send in normal mode.

Tested with MCI rev4 instead and it performs as expected (on the get_mci_output_working branch)

Also started working on power selection (branch: soft_341_power_select_rev2). Some notes:

• Scaling factor for aux voltage seems a bit too high but is pretty good

• Aux current readings are inconsistent, but we’re only drawing 14 mA from the power supply anyways. Need to confirm scaling factor with HW

• DCDC voltage reading is ~7V after conversion, but actual measured input is just under 1V

• Need to figure out conversions for thermistor readings

• Should probably test CAN broadcasting of measurements to confirm that it works

Overall, power selection should be good to go soon-ish

Nov 2

Jess

CENTRE CONSOLE
MISC:

• moved USB hub to mockup board (rip Aashmika's tape job)

• moved keysight 35V power supply to mockup table

• created mockup branch!

HARDWARE TESTING:

• i2c init was missing, added to

• wrong i2c address, should be 0x20 rather than 0x27

• many led / button addresses wrong because hw is msxii not msxiv

• hazard button latches but none of the others do??

• drive and neutral are reversed in the hw, in hw drive is A6, neutral is A5

• drive and neutral LEDS are also reversed in hw, so those buttons are probably wrong?

• spare, bps, and parking LEDS don't work, the extra LED attached via connector doesn't seem to do anything

• on branch soft_151_cc_validation, created project smoke_console that toggles all LEDs and prints what buttons are pressed

FIRMWARE TESTING:

• added a ton of logging to stuff

• created project smoke_acks on soft_151_cc_validation and added option to run x86 can with can0

• to start project: make run PROJECT=smoke_acks PLATFORM=x86 DEFINE=CAN_HW_DEV_USE_CAN0 &, then wait for it to say "now acking all critical messages". This lets you run other commands, but still shows the output of smoke_acks

• note that the acks don't appear on cantools monitor because the source is wrong

• to stop project: do fg, then ctrl+C

• strat for mocking acks is to change all expected bitsets to just babydriver, also have to change any expected ack counts to 1 rather than anything else

• note that ack timeout is set to 25 ms, so by computer lag sometimes they fail, maybe worth turning this up for the mockup for more stability

• kinds of tests to do: off->aux->off, off->aux->main->aux

• relay logic is legacy, gotta rip it out for the most part

• switching between power states seems to work! haven't tested lights + power states yet, or drive states

Nov 3

Ricky

BMS Carrier: I soldered on some of the components and connectors, before that I took off all of the hanging wires insulated and not insulated

MCI Precharge: I replaced the MCP2515

BMS AFEs: I put on the remaining 12 pin connectors on all of the AFEs

Center Console: put some tape over the drive and neutral to switch them

Nov 3

Selina

Power Distribution: I got started on front power distribution validation and was concerned at first about hardware breakpoints when I ran tests, but it wasn’t actually a problem because unit tests running on stm32 do run gdb. The publish_data unit test is currently failing 2/7 tests, which are test_power_distribution_publish_data_send_can_msgs_front and test_power_distribution_publish_data_send_can_msgs_rear. It’s pointing to a problem with the MS_TEST_HELPER_ASSERT_NO_EVENT_RAISED check.

Nov 3

Jess + Ryan

CENTRE CONSOLE

• drive fsm has ebrake code :( gotta remove

• car starts in neutral, so neutral should light up when power main completes (I dunno how to do that in led manager)

• we shouldn't process neutral events if we're on aux

• to unmock the ack on things in the mockup, do a search in console for //.+SYSTEM_CAN_DEVICE, then switch the commented lines as appropriate

• other than the led manager shenanigans, seems to work ok! states switch as expected

• added mock precharge to smoke_acks, gotta uncomment that too whenever testing for real

POWER DISTRIBUTION

• flashing the power distro project actually seems broken.

• right before shutdown command invoked, program power_distro puts
  Error: stm32f0x.cpu -- clearing lockup after double fault
  target halted due to debug-request, current mode: Handler HardFault
  xPSR: 0x60000003 pc: 0xfffffffe msp: 0x20001df8
  Polling target stm32f0x.cpu failed, trying to reexamine
  Info : stm32f0x.cpu: hardware has 4 breakpoints, 2 watchpoints

There’s a terrible segfault going on. The code is haunted by santa claus.

Branch: mockup. initing a pin in bts7200 and bts7040 re-called pca9539r_gpio_init with a 0 i2c port, which overwrote the previous i2c port of I2C_PORT_2. This caused a segfault after i2c timed out in the timeout-recovery function. There's still another segfault somewhere. You can add __asm(“BKPT #1\n”); anywhere to cause it to breakpoint. Running make gdb PROJECT=power_distribution will breakpoint, whereas just programming it with a breakpoint will cause the programming to fail.

Nov 3

Hewitt

Power selection: FW seems to work, implemented the thermistor code from the old power selection with a few changes and got reasonable values. Gonna look over the FW but it should be good to go (haven’t tested whether the CAN messages are getting sent correctly yet). One note is that adding the aux switch seems to have resulted in us not needing to jump start it by powering the controller board through the programmer at first – not 100% sure why this is happening.

MCI: tested after Aashmika replaced the MCP2515. It seemed to be working better (seeing messages now, at least, and the rx buffers weren’t filling up) but still wasn’t calling the CBs, even in loopback mode. Aashmika replaced the CAN transceiver later on as well, so I’ll try and test whether that fixed the issues we’re having tomorrow/Thursday.

Nov 3

Aashmika

• started sorting connectors from Newark order (not done)

• Found and fixed six controller boards so they’re functional for mockup (there are absolutely no others that work unless we pick and place)

• Replaced can transceiver in hopes MCI rev 5 will work (its possible the original one could have died from all the backwards components)

  • Finished the contactor coil harness for BMS carrier

• when carrier is probed from 12V to GND, there doesn’t seem to be a short. When the 12V is supplied to carrier, there is definitely a short somewhere on the board. The board can’t be used until we find the short.

Nov 4

Selina

Dug around in power distribution current_measurement.c and main.c with breakpoints and gdb with the code commented out that Jess and Ryan discovered cause the program to fail before main(). Here are some things:

• zero-initializing s_bts7200_storages and s_bts7040_storages did not do anything.

• the for loop that reads bts7040_get_measurement is definitely running as expected.

Nov 4

Jess

Found that the power distribution code was using so much static memory that there wasn’t any RAM left for the stack, so memory corruption was causing crashing without printing. Discovered that our linker script (stm32f0discovery_def.ld) caused only half our available memory to be used. Increasing the available stack space (_estack) to make use of all our memory solved the issue.

Nov 6

Hewitt

MCI: tested with the CAN transceiver replaced and it works now! Somehow it seems like the CAN transceiver was affecting how the MCP2515 worked in loopback mode, which is weird. It’ll definitely make sense to revisit the MCP driver soon-ish to get a better sense of what’s going on.

Power distribution: tested when also powering centre console, pedal. Didn’t have a ton of time to look at the setup but it wasn’t acking the requests sent from centre console (testing with aux power on sequence). The rx cb in can_rx_event_mapper isn’t getting called at all so it might just not be connected correctly to the centre console controller board. Will look at it more tmrw to figure out the cause.

Nov 6

Aashmika

BMS Carrier:

After taking off way too many components, I realized that the 12V microfit harness was made incorrectly - I did not make it but found it in the mockup crimped wires box, and used it thinking it would follow our standards of orientation of pin 1 and 2 to gnd vs pwr. It did not, big rip. After figuring this out I put everything we took off back on, and it’s awaiting firmware validation to tell if anything died with the reverse supply polarity. For now on the mockup, it will only be used for the kill switch and the relay implementation

Other:

I figured out how to depin microfit connectors - use a thin set of tweezers and using one side of the tweezers, insert into the microfit pin on either side (on at a time) from the front of the plug connector. This pushes back the metal tabs and allows the wire to come out. To use the crimp again, take the tweezers and pull back the metal tabs once again.

I also made a dual microfit-banana plug harness to use with the power supply and our boards (which from now on are trying to follow the microfit-power connector standard)

I organized all the crimps and connectors that came from newark, mouser and digikey. Anything on board is now in the original four bins with dividers in the red shelves, and anything mx150L or High Power is now sitting in a box under the center white table.

I finished crimping the MCI contactor connector to have the sense lines on the relay connected

To do :

• solder a connector to P4 and route the kill switch to it (purple wires) (BMS Carrier)

• Label the slots in the on board connector boxes (top lid) correctly (i.e. update labelling)

Nov 7

Hewitt

Power distribution: seems like CAN isn’t working on the controller board we were using (labeled “8,” has some string attached to it). Switched it out for the power select controller board and changed front PD ACKs that were initially mocked to actually go through PD and aux/main power on sequences worked as expected, albeit with a really high can ack timeout since my laptop’s slow af.

Powered centre console + pedal off PD instead of the power supply and that worked fine as well.

Tested power select out by setting it as an expected device in power_main_sequence.c for EE_POWER_MAIN_SEQUENCE_CONFIRM_AUX_STATUS and EE_POWER_MAIN_SEQUENCE_CONFIRM_DCDC and it acked the messages, sequence worked as expected.

Still need to test power select and power distro at the same time to be sure, but there shouldn’t be any issues between them and centre console during the power on sequences.

Nov 8

Jess

MISC

• to filter pedal out from cantools apply filter ^((?!PEDAL_OUTPUT).)*$

• changed controller_board_blinking_leds to leds

• found that some controller boards only work when powered from a board, not from the programmer (power select board (4) works like this)

• dug through the dead ones and somehow found a working one?? controller board jesus???

CENTRE CONSOLE

• hazard button now works properly

• after failing precharge, goes into unknown state and doesn't seem to recover

  • can't power off, but can press neutral to retry precharge trigger

• note that to properly transition drive state the ack stuff must be running

  • should eventually unmock mci

• updated to auto-set neutral led on power on

• happy path basically gucci for drive fsm

• Ryan changed lights logic to only have a drive light on if we're on main, not aux

MCI

• added logs to precharge

• found out precharge needs external stuff, so mocked it for now

• haven't really done a ton of testing, but happy path is basically gucci

• QUESTION: how do we tell what mci output is? we need another terminal I guess for mcp2515 reading

POWER SELECT

• merged to mockup branch

• commented out dcdc validity check in prv_rx_callback for console ack

BMS

• if we want to test killswitch we should probably add the button for it

FULL

• wired everything up to be good for mockup. For some reason I'm now struggling with proper acks, computer won't respond to them

Nov 9

Ricky

BMS Carrier: Soldered on p4 and attached the kill switch to the board

Charger interface: Soldered on about half of the components to the board

Nov 10

Jess + Ricky

• Finished sequencing testing ish, the power distro -> mci wire got ripped out so that was fixed by Ricky, otherwise sequencing seems to work pretty ok. The changes to led manager by Ryan work great.

• the pedal potentiometers have somehow reversed polarity, I have no idea how. Plus is now down, and minus is now up.

  • suggested firmware task: add pwm led on controller board to show pedal %

BUG: sometimes computer says it acks but it doesn't actually ack. In this case unplug-replug the CAN dongle, and set it up again, then it acks properly.

BMS CARRIER

• tested relays by just plugging them into the board and setting them with babydriver. Nothing happened, I thought I was supposed to get an audible click.

• tested killswitch by setting firmware to trigger on killswitch monitor and log something, but nothing happened when I pressed it. Assuming killswitch monitor is PA15

• tried registering interrupts on all pins PA0 -> PB16, but no luck, nothing happened when killswitch pressed

• basically, carrier seems not functional for mockup. We could still use it for CAN acks in sequencing I guess.

CENTRE CONSOLE

• sequencing bug: if we're power main and request precharge and it fails, can't turn off again

POWER DISTRIBUTION

• previously we were erroring out of a loop when we were setting pins for a power sequence, so I changed it to not error out and now we set all the pins

Charger Interface: Soldered on the rest of the components

Front Power Distribution: Soldered on the 12V power directly to the IC and as well as hot glued the wires to the board to make it less likely for the pads to come off

BMS Carrier: There was a short on pins 7 and 8 on the R23 Res Array

Nov 11

Jess + Aashmika

BMS CARRIER

• replaced high side driver, now killswitch works

• started putting together a smoke_bms for easier debugging

• gnd relay clicks, but hv relay has hardware issue

  • discontinuity in harness

• basically working now, just shitty button connector

• issue: everytime the relay coils energize, the rest of the system restarts. This is really bad.

• Actually, it was just current limit on power supply. Need 6 amps for perfect functionality. No problems with the killswitch, and both relays close.

MISC

• to check if a controller board is dead, probe C12. If shorted, MCU dead.

• gotta email kentucky solar to beg for ws config software

• possibly just make a reddit post asking for config software

• recalibrated scope cus it was being dum

CBs:

• Revived 3, killed 1- replaced the MCU on 2 of the boards with shorts, and fixed the debug header on the other 1

• Have the check if 1 of them flash since it wasnt tested after replacing the MCU

EVENING SHIFT

MISC

• controller board labeled "TO TEST REPLACED MCU" works

• some programmer cables are upside down, the red wire needs to be on the side of the programmer with the jumper cable

• from now on just going to leave the programmer cables attached to controller boards, much easier to move around to different boards this way

MCI

• seems like we're not getting anything from mcp2515, but that may be a cannable vs programmer conflict in linux, so will re-verify

BMS

• set up firmware project to only enable killswitch and relay sequence. relay sense doesn't seem to work, but if we disable checking after setting it seems to work ok.

• created a relay_set.py in projects/bms_carrier/, running it waits a second, closes the relays, waits two seconds, then opens the relays (over CAN)

• killswitch was tested, seems to properly fault the relays open

• killswitch still seems to need some debouncing or something, the button seems inconsistent in firmware

• relays seem to be working ok as part of the power main sequence

• bps heartbeat doesn't seem to close relays on failure when running from centre console, but it does when running from smoke_acks? this is strange

CENTRE_CONSOLE

• sometimes an ack from power distro(?) will fail on power off, causing a bad state in centre console and requiring a system reset. This is probably just from too much logging in power distro causing the ack to time out, but unsure

POWER_DISTRIBUTION

• for some reason couldn't flash it, will try again at some point

Nov 12

Ricky

AFE: Creating the 14 pin connectors by stripping and crimping wires. Soldered the wires to the battery holders.

Cut 60 pieces of heat shrinks. Put on all of the heat sink inserts. Strip all 22G and 18G wires on one end with 3 clicks.

Nov 12

Jess

MCI

• sometimes turns on when we flip the aux switch? I'm assuming this is because inrush current / voltage flood / blablabla I almost failed electricity physics but I'm also assuming this is not good

• mcp2515 not working. Seems to be firmware issues

Nov 14

Hewitt

MCI: spent a bit of time looking at why it wasn’t working. Eventually traced it down to what looked like HW issues. Aashmika found a short on the CAN transceiver, replaced it, and MCI started working again.

For future reference: when starting the MCP2515 in normal mode, we should see roughly the following output on minicom:

[0] libraries/ms-helper/src/mcp2515.c:249: before write 0

[0] libraries/ms-helper/src/mcp2515.c:252: after write 5

[0] libraries/ms-helper/src/mcp2515.c:259: before write 2 31

[0] libraries/ms-helper/src/mcp2515.c:262: after write 2 0

If these values are different and we’re having problems with the MCP2515/CAN transceiver it may point to a HW issue.

I did notice an issue where sometimes the filters on the MCP2515 let through the wrong message ID, so started writing code to deal with that – shouldn’t be an issue as long as we’re calling the right callback, which I’m 99% sure we are. Not sure if this is new, I remember looking through a bunch of the CAN messages earlier to make sure this wasn’t happening and they all seemed to be working okay. Will look into further over the next few days