RoboDurden / Hoverboard-Firmware-Hack-Gen2.x

with different defines_2-x.h for different board layouts :-) Compiles with Keil version 6
GNU General Public License v3.0
89 stars 29 forks source link

Gen2.4.2 (MM32SPIN05) + EFeru FOC port !!! #96

Open RoboDurden opened 1 month ago

RoboDurden commented 1 month ago

thanks to @trondin , continuation from https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/issues/22

master front

Gen2 4 5 schematics

RoboDurden commented 1 month ago

phase currents

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 ?

trondin commented 1 month ago

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.

trondin commented 1 month ago

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.

RoboDurden commented 1 month ago

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.

trondin commented 1 month ago

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.

RoboDurden commented 1 month ago

Nice. With the makefile i might be able to add your repo to my online compiler: https://pionierland.de/hoverhack/

RoboDurden commented 1 month ago

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

RoboDurden commented 1 month ago

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.

trondin commented 1 month ago

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?

RoboDurden commented 1 month ago

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};
I-hate-2FA commented 1 month ago

he already said he have exact same board as mine

RoboDurden commented 1 month ago

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..

trondin commented 1 month ago

Yes. it is error in the picture, but schematic is correct - I mean UART.

RoboDurden commented 1 month ago

@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..

Candas1 commented 1 month ago

Yeah FOC control cannot be used without Phase Current, only sinusoidal can be used.

RoboDurden commented 1 month ago

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.

I-hate-2FA commented 1 month ago

he use COM_SPEED which is the worse control method, if he used SINE_VOLT itll perform at least better then the gd

I-hate-2FA commented 1 month ago

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

I-hate-2FA commented 1 month ago

IMG_20240925_182626 this is literly the same

I-hate-2FA commented 1 month ago

idk why you started new layout, and i already said mm32 shouldnt have a id

RoboDurden commented 1 month ago

@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.

I-hate-2FA commented 1 month ago

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

trondin commented 1 month ago

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 IMG_6852

master IMG_6855

RoboDurden commented 1 month ago

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

trondin commented 1 month ago

here is chip gate

RoboDurden commented 1 month ago

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.

chips

So i will remove the 2.4.5 again, sorry for the confusion i caused.

I-hate-2FA commented 1 month ago

now my repo is moved to gitlab https://gitlab.com/ailife8881/Hoverboard-Firmware-Hack-Gen2.x-MM32

RoboDurden commented 1 month ago

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 ?

I-hate-2FA commented 1 month ago

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 ?

image

I-hate-2FA commented 1 month ago

i just use whatever is useable, if you prefer me to use other git controller, i can

I-hate-2FA commented 1 month ago

gitlab is just the second most popular option, nothing more,

RoboDurden commented 1 month ago

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

I-hate-2FA commented 1 month ago

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