Show page

Differences

This shows you the differences between two versions of the page.

--- pm:prj2026:bianca.popa1106:timotei_iosif.cicu [2026/05/09 13:42]
timotei_iosif.cicu [Injectors and spark plugs outputs]
+++ pm:prj2026:bianca.popa1106:timotei_iosif.cicu [2026/05/12 10:30] (current)
timotei_iosif.cicu [Analog inputs, internal MAP and battery voltage]
@@ Line 487: / Line 487: @@
 So in conclusion, my injector and spark plug output blocks work as they are, but I still ordered the new resistors and I have changed them.
-With the 100Ohm resistors, I require a heating on them as they reach 80C at 25C ambient.
+With the 100Ohm resistors, I require a heatsink on them as they reach 80C at 25C ambient.
 ==== Crank and Cam inputs ====
-When my first order from mouser came, I noticed that the comparator was missing (as can be seen in some of the images), so I placed another order. After it arrived, I soldered the comparator to the PCB. I tested the crank and cam inputs using a signal generator set at Pk-Pk 20V centered at 0V using multiple types of signals at multiple types of frequencies. On the software aspect of things, for the low speed runs I blinked the LED at the same frequency as the signal that I was reading, and at higher frequencies I divided that frequency so that I could visually see that the comparator was reading fast enough. I tested the VR detection circuit at up to 3000Hz. I also confirmed with an oscilloscope that I was detecting the VR signal at the right frequency.
+When my first order from mouser came, I noticed that the comparator was missing (as can be seen in some of the images), so I placed another order. After it arrived, I soldered the comparator to the PCB. I tested the crank and cam inputs using a signal generator set at Pk-Pk 20V centered at 0V using multiple types of signals at multiple frequencies (max 5KHz). Using an oscilloscope I measured the output of the comparator. As can be seen in the VSS section, my Mcu is more than capable of handling the required frequencies.
-TODO: Insert image of the setup.
+{{:pm:prj2026:bianca.popa1106:timotei_iosif.cicu:whatsapp_image_2026-05-09_at_17.42.49.jpeg?300|}}
+{{:pm:prj2026:bianca.popa1106:timotei_iosif.cicu:whatsapp_image_2026-05-09_at_17.42.49_1_.jpeg?300|}}
 ==== Analog inputs, internal MAP and battery voltage ====
@@ Line 500: / Line 501: @@
 For the analog inputs, I checked them using a potentiometer and compared the readings from them to the readings on my multimeter. I did the same for the internal MAP and battery voltage. Afterwards, for the latter two, I converted the reading to their respective units and representations and confirmed that for the MAP I was reading around atmospheric pressure and for the battery voltage I was reading 12V (the value that I set my power supply at).
-TODO: Insert image
+At first the Adc_Calibrate function failed, after investigating further in the S32K3 Datasheet and Reference Manual, and measuring VREFH and VDD_HV_A with a multimeter (and later an oscilloscope), I determined that I made an error in the hardware design. VREFH is 0.01V higher than VDD_HV_A, and the datasheet states this is only valid in transient mode (the VREFH line can jump higher than VDD_HV_A only momentarily for a short period).
+To fix this, I cut the track from the 5V_SENSORS net going to VREFH and I soldered a wire from VREFH to 5V_DIGITAL. This fixed my issue
 ==== CAN transceiver ====
 To test the CAN transciever, I wired up a CAN network with two devices on them: my ECU with the internal termination resistor turned on, and one of my old projects that also had CAN on it, with another termination resistor near it. For the first test I confirmed using an oscilloscope (that can decode CAN packets) that my ECU was sending the correct information, and in the second test I set my other project to send CAN packets and using the debugger I confirmed that my ECU was receiving the correct CAN packets
-TODO: Insert image of the setup
 ==== VSS ====
-To test the VSS input, I used a singal generator at 5000Hz using a square wave between 0V and 5V. I then used the same methodology as the validating the Crank and Cam input blocks.
+To test the VSS input, I used a singal generator at 60KHz using a square wave between 0V and 5V. I created a blinking LED with a divider from the frequency of my VSS input. And confirmed with an oscilloscope that all of the interrupts were caught.
-TODO: Insert image of the setup
+{{:pm:prj2026:bianca.popa1106:timotei_iosif.cicu:whatsapp_image_2026-05-09_at_17.12.49.jpeg?300|}}
 ==== UART ====
 I could not buy the Uart-to-USB chip because it was out of stock when I placed the order, instead I ordered an external Uart-to-USB module and I confirmed using it that my ECU can communicate to a computer using UART over USB.
-TODO: Inset image of the setup
 ==== Internal flash ====
@@ Line 528: / Line 525: @@
 ==== RTC ====
-I have used this RTC IC in the past with great success. Inorder to validate that the RTC is wired correctly, I first tried getting the vendor id from it using an I2c command, then I tried setting the clock and reading it back a few seconds later to see if it has increased. My tests were successful.
+I have used this RTC IC in the past with great success. Inorder to validate that the RTC is wired correctly, I first tried getting the vendor id from it using an I2c command, then I tried setting the clock and reading it back a few seconds later to see if it has increased.
 ==== Digital outputs ====
-To test the digital outputs, I turned them on and placed a 10 Amp load on one of them, then I measured the temperature rise on them.
+To test the digital outputs, I turned them on and placed a 9 Amp load on one of them, then I measured the temperature rise on them. After 2 minutes, they never reached above 60C with an ambient of 25C
-(TODO): Insert image of the setup
+{{:pm:prj2026:bianca.popa1106:timotei_iosif.cicu:whatsapp_image_2026-05-09_at_13.54.31.jpeg?200|}}
+{{:pm:prj2026:bianca.popa1106:timotei_iosif.cicu:whatsapp_image_2026-05-09_at_13.54.32.jpeg?200|}}
 ==== Hardware validation conclusions ====
-(TODO)
+After the hardware validation step, I can confirm that the PCB works as intended, and I can move unto the firmware.
 ===== Software requirements and architecture =====