Open RoboDurden opened 1 month ago
The two phase currents as usually are taken from the on-resistance of the two low side mosfets. Diode D18 pulls to 36V under 5V when the low side mosfet is off. R79 and R71 seem to be a voltage divider to set the no-current base line above 0 V so that the drain-source voltage of the low side mosfet affects this base line via resistors R82 and R83.
@trondin evaluates the phase current as adc_buffer.rrB = (adc_buffer_raw[0]- adc_buffer_raw[1]) & 0xFFF;
in void DMA1_Channel1_IRQHandler(void)
of his EFeru-port::bldc.c
I guess that is PA0 - PA1
I have no idea what PA2 is good for.
The hoverboard mosfets usually have the HN75N09 which has something like 8 mOhm on-resistance
Type Designator: HN75N09AP
Type of Transistor: MOSFET
Type of Control Channel: N -Channel
Pdⓘ - Maximum Power Dissipation: 200 W
|Vds|ⓘ - Maximum Drain-Source Voltage: 90 V
|Vgs|ⓘ - Maximum Gate-Source Voltage: 20 V
|Vgs(th)|ⓘ - Maximum Gate-Threshold Voltage: 4.5 V
|Id|ⓘ - Maximum Drain Current: 75 A
Tjⓘ - Maximum Junction Temperature: 175 °C
Rdsⓘ - Maximum Drain-Source On-State Resistance: 0.008 Ohm
Package: [TO220](https://alltransistors.com/mosfet/transistor.php?transistor=62215#img10)
At 10A (=360 Watt) that would be a drain-source voltage of only 0.08 Volt ! I can not see how such a low voltage can be measured without amplification. MM32SPIN05 has the one internal comperator on the PA0 and PA1 pins... So maybe it still needs a few more code lines ?
I modified little bit code, but, probably you are right, voltage is too low. At least EFeru's torque mode works terrible, but voltage is fine. Both are with FOC_CTRL mode. The latest code for hardware: timer is same
// -------------
TIM1->SMCR = 0;
TIM1->CR1 = TIM_CR1_CMS_CENTERALIGNED1; // Center-aligned mode 1
TIM1->PSC = 0;
TIM1->ARR = PWM_RES; // 2250
TIM1->RCR = 1;
// master/slave
TIM1->CR2 = TIM_CR2_MMS_UPDATE; // TRGO
//TIM1->CR2 = TIM_CR2_MMS_OC4REF; //CCR4
// ConfigChannel
TIM1->CCMR1 = TIM_CCMR1_OC1M_PWM1 | TIM_CCMR1_OC2M_PWM1;
TIM1->CCMR2 = TIM_CCMR2_OC3M_PWM1;
// break
TIM1->BDTR = TIM_BDTR_OSSR | TIM_BDTR_OSSI | DEAD_TIME;
// enables
TIM1->CCER = TIM_CCER_CC1E | TIM_CCER_CC1NE
| TIM_CCER_CC2E | TIM_CCER_CC2NE
| TIM_CCER_CC3E | TIM_CCER_CC3NE;
TIM1->BDTR |= TIM_BDTR_MOE;
TIM1->CR2 |= TIM_CR2_OIS1N | TIM_CR2_OIS2N | TIM_CR2_OIS3N;
// start
TIM1->CR1 |= TIM_CR1_CEN;
ADC - no need for DMA anymore:
void ADC1_Init(void)
{
RCC->APB2ENR |= RCC_APB2ENR_ADC1EN;
RCC->AHBENR |= RCC_AHBENR_GPIOA | RCC_AHBENR_GPIOB;
GPIOA->CRL = 0;
GPIOB->CRL &= 0xFFFFFF00;
ADC1->CFGR = ADC_CFGR_ADEN | ADC_CFGR_TEN | ADC_CFGR_VEN | ADC_CFGR_SAMCTL_7_5; //14.4MHz, temper & ref enable
ADC1->CR = ADC_CR_SCAN | ADC_CR_T1_TRIG | ADC_CR_ADIE; // interruption
ADC1->CHSR = ADC_CHSR_CH0 | ADC_CHSR_CH1 // phase b
| ADC_CHSR_CH4 | ADC_CHSR_CH5 //phase c
| ADC_CHSR_CH7 // I common
| ADC_CHSR_CH9 // voltage
| ADC_CHSR_CHT; // temperature
NVIC_SetPriority(ADC1_IRQn, 0);
NVIC_EnableIRQ(ADC1_IRQn);
// ADC1->CR |= ADC_CR_TRGEN;
}
and main eFeru's loop-interruption, just beginning
void ADC1_COMP_IRQHandler (void)
{
ADC1->SR |= ADC_SR_ADIF;
adc_buffer.rrB = (ADC1->ADDR0 - ADC1->ADDR1) & 0xFFF;
adc_buffer.rrC = (ADC1->ADDR4 - ADC1->ADDR5) & 0xFFF;
adc_buffer.dcr = ADC1->ADDR7 & 0xFFF;
adc_buffer.batt1 = ADC1->ADDR9 & 0xFFF;
adc_buffer.temp = ADC1->ADDR14 & 0xFFF;
PWM frequency is 12 kHz, 16kHz is too much foe EFeru's algorithm and Cortex-M0. Now hardware related part of software is trivial.
BTW, you are calculating average current, pulse current and voltage for ADC much bigger. With ADC reference voltage 1.2V situation is not dramatically terrible.
How does motor behavior change in voltage mode if simply set
adc_buffer.rrB = 0;
adc_buffer.rrC = 0;
? If motor still spins nicely, then your EFeru port would applay to all MM32 boards, i guess.
Sources are here https://github.com/trondin/MM32SPIN05_Hoberboard_hack Finally it works without Keil - editing/design with Platformio, but Platformio generates wrong binary. A am not willing to modify Platformio. Just use simple make to get working firmware - it work for me perfect.
Nice. With the makefile i might be able to add your repo to my online compiler: https://pionierland.de/hoverhack/
Okay, compilation succeeds and your repo is added to my online compiler. Only a hex (and .elf) file is generated, no .bin. Maybe you can test the hex file: https://pionierland.de/hoverhack/download/trondin_mm32spin05_hoberboard_hack_hover-test_2024-09-25_11_14_43.hex
It might be good to add a simple testserial.ino to your repo so people have an easy start for their ESP8266 / ESP32 or Arduino.
Hex works well! My serial control device use STM32 and scmRTOS - maybe little bit too much for normal users. It is part of dashboard for my mobility scooter with RFID lock, Nokia 5110 LCD, throttle, break and so on.
BTW, do you know any cheap and easy available board with opamps for torque mode?
Your Gen2.4.5 might be pin compatible with Gen2.4.2 that @AILIFE4798 is also working with. Led and hall header is the same as well as BUTTON and CHARGE and VBatt :-) CurrentDC is PB7 for both as well i guess. But in your pin tracing you have tx/rx as PB6 and PD4 whereas 2.4.2 has PB6 and PB4. I guess this is a typo error.
I am not sure if 2.4.1 is compatible. I these are my pinfinder results:
Gen2.4.1
master, master-slave uart
halla ( 0): 28 (PC15) hallb ( 1): 26 (PC13) hallc ( 2): 27 (PC14) ledr ( 3): 8 (PA11) ledg ( 4): 32 (PD3) ledb ( 5): 31 (PD2) ledu ( 6): 23 (PB10) ledd ( 7): 65535 (not set) buzzer ( 8): 65535 (not set) button ( 9): 22 (PB9) latch (10): 15 (PB2) charge (11): 65535 (not set) vbat (12): 14 (PB1) itotal (13): 65535 (not set) tx (14): 19 (PB6) rx (15): 17 (PB4)
uint16_t pinstorage[64]={28, 26, 27, 8, 32, 31, 23, 65535, 65535, 22, 15, 65535, 14, 65535, 19, 17, 65535, 65535, 65535, 65535, 65535, 65535, 65535, 65535, 65535, 65535, 65535, 65535, 65535, 65535, 65535, 65535, 56491, 31, 250, 0, 19200, 8192, 1, 30, 0, 10, 300, 1, 1, 42000, 32000, 1000, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};
slave, bluetooth uart header
halla ( 0): 26 (PC13)
hallb ( 1): 27 (PC14)
hallc ( 2): 28 (PC15)
ledr ( 3): 8 (PA11)
ledg ( 4): 32 (PD3)
ledb ( 5): 31 (PD2)
ledu ( 6): 23 (PB10)
ledd ( 7): 65535 (not set)
buzzer ( 8): 22 (PB9)
button ( 9): 65535 (not set)
latch (10): 65535 (not set)
charge (11): 65535 (not set)
vbat (12): 65535 (not set)
itotal (13): 65535 (not set)
tx (14): 20 (PB7)
rx (15): 21 (PB8)
uint16_t pinstorage[64]={26, 27, 28, 8, 32, 31, 23, 65535, 22, 65535, 65535, 65535, 65535, 65535, 20, 21, 65535, 65535, 65535, 65535, 65535, 65535, 65535, 65535, 65535, 65535, 65535, 65535, 65535, 65535, 65535, 65535, 56491, 31, 250, 0, 19200, 8192, 1, 30, 0, 10, 300, 1, 1, 42000, 32000, 1000, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};
he already said he have exact same board as mine
I see analog mosfet drivers on his boards so i did assign a new board id for the wiki. People start with a look a the board..
Yes. it is error in the picture, but schematic is correct - I mean UART.
@trondin you should start an issue at the Eferu repo to get feedback why an FOC firmware is running without the two phase currents in VLT_MODE and if the missing phase currents are indeed the reason why SPD_MODE and TRQ_MODE do not run smootly. @Candas1 always told me that FOC is impossible without phase currents..
Yeah FOC control cannot be used without Phase Current, only sinusoidal can be used.
Thank you Candas for the quick response :-) Then this EFeru port does not have an advantage over the https://github.com/AILIFE4798/Hoverboard-Firmware-Hack-Gen2.x-MM32 which also offers sinusodial motor control and supports the MM32SPIN2x hardware and my UartBus protocol. Not to mention his nice pinFinder interface for new layouts.
But people used to the EFeru firmware might be happy to go for it.
he use COM_SPEED which is the worse control method, if he used SINE_VOLT itll perform at least better then the gd
all mm32 board is using gate driver chip, it is required, mm32spin05 do not have direct drive capability like gd32, only other mm32 line have
this is literly the same
idk why you started new layout, and i already said mm32 shouldnt have a id
@trondin , as you know how to create a makefile. It would be nice if you fork this Gen2.x https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x-GD32 firmware and add a makefile. Then i could add the Gen2.x to my online compiler as well. The MM32 firmware from AILIFE does not really need that as it offers "two binaries to rule them all".
Yes, 2.4.2 and 2.4.5 might be very close. But the wiki board finders starts with identifying the type of mosfet drivers.
there is version number on back of the board, if you want to make sure its exactly the same, mine is in 2.4.2 issue
as you know how to create a makefile. It would be nice if you fork this Gen2.x Problem is not in makefile. The most important is to do correct startup assembler file and script for linker. I am not able to do it without testing.
Our boards are exactly same, here is backside of mine one:
slave
master
2.4.5 has analog gate drivers, 2.4.2 has three gate driver chips. Why they both label V0.3 on the backside is beyond my imagination. Same for the phase current circuit. I guess the original mcu was a bit to exensive so they replaced that unknown mcu with the MM32SPIN05. AiLife, is this the $2 board ?
Maybe put a permanent link to the by now $4 Aliexpress offer on your repo read.me
here is chip
Okay, all my fault :-) I did not see the chips on your pinout image and was so stupid to not see them on your nice schematics.
So i will remove the 2.4.5 again, sorry for the confusion i caused.
now my repo is moved to gitlab https://gitlab.com/ailife8881/Hoverboard-Firmware-Hack-Gen2.x-MM32
okay i have changed the link on the read.me here. Is there any advantage on gitlab for such a mm32/gd32 repo ? Or is it the usual Linux-believer attitude to avoid any Microsoft product ?
Is there any advantage on gitlab for such a mm32/gd32 repo ? Or is it the usual Linux-believer attitude to avoid any Microsoft product ?
i just use whatever is useable, if you prefer me to use other git controller, i can
gitlab is just the second most popular option, nothing more,
okay. but i never understood why you hate 2fa ;-) Problems with phone number in your country ? But yes, 2fa via cell phone is wide open for hacking: SS7
offer a option is always nice, but not force me to use it, especially all my code is for micro controller, its not safety critical, i use my phone in flight mode, i always use a laptop, i know i can use a android emulator, but what if i need to log in onm other pc, its just asking for trouble
thanks to @trondin , continuation from https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/issues/22