Firmware

[Restless]

@electric_vehicle_lover thanks it worked with replacing the LFAG in Makefule: to "LFLAGS  = -Tsrc/stm32_flash.ld -L/usr/lib/gcc/arm-none-eabi/4.9.3 -lgcc -nostartfiles"

was able to build and flash.

( @jayjay23 are you using 32bit env? )

Now i'm able to start

[jayjay23]

37 minutes ago, Restless said:

../tools/gcc/bin/arm-none-eabi-ld: cannot find -lgcc

The chain should be as follows, please verify all the path' and variables are in place:

TCPREFIX  = ../../gcc/gcc-arm-none-eabi/

LFLAGS  = -Tsrc/stm32_flash.ld -L$(TCPREFIX)lib/gcc/arm-none-eabi/current -lgcc -nostartfiles

The key is the -L flag, if I verify what's there I get:

 l ../../gcc/gcc-arm-none-eabi/lib/gcc/arm-none-eabi/current/libgcc.a
-rw-r--r-- 1 1607588 Jun  9  2015 ../../gcc/gcc-arm-none-eabi/lib/gcc/arm-none-eabi/current/libgcc.a

So if I look in your -L flag, I can't see the lib directory, can you tell me what tool chain you are using and what the directory structure looks like,

I just took the official launchpad release and oriented the makefile on that structure:

-L../tools/gcc/lib/gcc/arm-none-eabi/current

edit: Ok, the dir actually looks ok, maybe it's just the complete path that is not pointing to the final required directory

 

 

Edited December 11, 2015 by jayjay23

[jayjay23]

8 minutes ago, Restless said:

are you using 32bit env?

No, but this should not make any difference, right?

[jayjay23]

Regarding the serious boot problems the solution should be as follows (http://jeelabs.org/book/1546c/):

It seems if you boot from SRAM instead of Flash the SWD interface works for doing what you want, e.g. reflash with another firmware file.

The ST docu says to pull Boot0 high (which means unsoldering that pin on our boards) and Boot1 low, then reset the board.

The Link above says the inverse PIN powering, so you maybe try both.

[jayjay23]

Ok, just found another interesting point on above mentioned page:

"Note that another way to force control with SWD, is to keep the RESET button pressed during the whole session. SWD, and uploading will work in this mode – while the µC is kept in reset."

If this holds true it may be easier to conduct on our boards, but I don't know if the reset PIN was connected or not.

The reset PIN seems to be pull up on our board,  but it should be possible to cut the line on the board and pull down instead.

[Restless]

Hey guys.

 

I did some minor changes at github, but nothing special.

 

Then i played a bit around with my board and decided to start with USART / RX/TX.

So we could actually use PB10 and PB11. They are unused atm and sepcified as USART Ports

 

The next step was to add some wire and ... guess what, i failed hard

I had the wires soldered to the pins (took me like an hour) for a short time. But, i was a bit clumsy and ripped of one wire AND also the Pin from the STM :/ its not that serious since its not used normaly but it still sucks.

It requires some good soldering skills to actually manage to do it properly, so even if we manage to do that. Most users of our firmware probably couldn't or with a high riskt of just destroying the STM.

 

My thought (that could actually also help us developing) is there anything like an adapter that we could just put on top of the ARM which extends the pins so we can access them easily?

[electric_vehicle_lover]

@jayjay23 thanks. I did a shunt to keep the NRST pin low. The debugger could communicate but couldn't flash as the STM32 were on reset mode. I ended up to cut the PCB trace and is ok now.

I need to detect the PS_signal. It have a capacitor to ground and a 10K resistor (a low pass filter). To activate PS_signal, we shunt the signal no GND.
I think the code should configure the pin as input with pull up resistor but for some reason the code do not work and I always read as 0.

Configure pin:

//PA4                 | in    | ??    | PS_signal           (calibrate_wheel)

#define PS_SIGNAL PA4

  GPIO_InitStructure.GPIO_Pin = PS_SIGNAL;
  GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IPU;
  GPIO_Init(GPIOA, &GPIO_InitStructure);

On main():

  //blocks while the PS_SIGNAL is low (there is a switch to control this signal
  //this is used to block firmware from running if for example it do a short circuit on the H bridges.
  while (!GPIO_ReadInputData(GPIOA, PS_SIGNAL)) ;

Can someone please look and test this code?? We don't have any code yet to read a pin.

@Restless about UART,

I think there will be limitations on current board:
- there are no available free pins (easy to access)
- we only have 64Kbytes for program memory that maybe just enough for the motor control

Maybe we can use the PS_signal that is easy accessible for a kind of 1 wire communication with the exterior. Then we could use for instance a small Arduino that could communicate with the boards and with the serial<->bluetooth module. That arduino could to other tasks like control RGB LEDs. Also it maybe could be connected to to SWD connector (that also have GND + 3V3) and be able to flash the firmware, so we could implement the flash firmware over the app.

[Restless]

@electric_vehicle_lover thanks for the new input. Since i failed to manage the RX/TX thing, ill try to work on reading the input

 

i thought about the idea with a second avr / arm too, might work. The 2 pins are easily accessable IF ur good with smd soldering

But the idea with the SWD connector is good.... that might work

Edited December 13, 2015 by Restless

[lizardmech]

Are you using any of the free RTOS or trying to code everything from scratch? The other similar projects I know of use freeRTOS or chibiOS as base so they don't have to write all the low level code.

[electric_vehicle_lover]

@lizardmech I think the code should be simple and no need for a RTOS. I saw some examples of BLDC motor control, even using STM32, and none use an RTOS.
Also we just have 64kbytes flash, we need to save most as possible.

[lizardmech]

Thats true, most of the others I was looking at were on STMF4xxx. I found an interesting open project that can be adapted to EUCs the controller has a GUI that lets you configure it for virtually any BLDC motor. I need to find someone to help modify it a little to include a MPU6050 and change the layout so it's suited for mass production.

I have a chinese company working on a quote for an upgrade of the common generic board with a usb port for easy firmware flashing and ready to go open firmware. Don't know what they will offer yet though.

I hope I can get something going, I want to try and raise capital to develop a high end EUC platform with redundant gyro + motor control and a proper canbus network to the BMS and other things. It will be much easier if I can show I have already shipped a basic EUC product.

[Mystamo]

Hey Guys,

Got my Controller from FMW on Friday. I didn't realize that they had done a full revamp on the hardware on this controller. A much much better design.

Going to start tearing down the design and reverse engineering the Schematics. This should help us all in trouble shooting, Pin Identification, Improvements, and last but not least building our own boards.

Over the next few posts I'll have a closer look at the active components and upload pictures and data sheets.

Regards,

Mo

 

[Mystamo]

Here is a close up of the PCB with almost all the Active component ID's visible.

Active component list:

1x ASM1117 3.3v Linear Voltage regulator for 3.3v on Invensense 6050 and STM32

2x ACS7121 Hall Current Sensor on 2 separate Phases - To measure phase current

3x IR2184s Gate Driver for Half Bridge. Built in fixed Deadband 1 for each N-Fet Pair

2x XL7005A SMPS Max 80v input Output can be adjusted 1 is used to produce 15-20v for Gate driver IC's The other most likely produces 5-12v for Current sensors or maybe just the 1117 to produce 3.3v with minimal losses.

1x Invensense 6050 (needs no introduction) 6Axis Accel/Gyro with nifity build in filtering

1x STM32 The Brain Child behind it all.

This is a much better laid out board. Still most likely has some design errors in it but we will comb those out.

Regards,

Mo

[electric_vehicle_lover]

You bought the board for the 30km/h (2nd gen)!! Not the one for the cheap generic unicycles (1st gen).
It is also nice to have more information about that boards, that also includes a connection for serial bluetooth modules.
Nice to see the same STM32F103C8T6 that have just the same amount flash programming memory of the 1st gen boards.

[Mystamo]

Datasheets for active components. Left out STM32 and 6050

 

Regards,

 

Mo

ACS712-Datasheet-1.pdf

ds1117.pdf

ir2184.pdf

XL7005A datasheet-English.pdf

[electric_vehicle_lover]

@Mystamo,

Would be better if you could create a folder on the documentation git and share there the datasheets and pictures. Finally you could write the wiki page about this 2nd gen controller. Because the information here will be "lost"/not structured, not organized. And gives us a note of the updates/new information here. Thanks.

[Mystamo]

Hey EVL, my organization skills have always been a little limited. I've usually been one to just kind of do things until it's finished and then clean the mess up after (Always a regrettable exercise at the end of it) I'll try my best to help with documentation. But for now it may be all that I have time for.

Below is another close up of the board with the sections highlighted.

 

Yellow - Phase current measurements

Green - Gate driver section. FETS are located just above not pictured.

Brown - Switch mode supplies.

Blue - LDO 3.3v Voltage Regulator

Purple - MPU MCU

Well lay out on the design. All sections seem to flow effectively.

 

Regards,

 

Mo

 

[electric_vehicle_lover]

@Mystamo, just one note. Since the STM32 is the same, the firmware can have big part in common with gen1 boards. Others devs like me, we just bought the gen1 boards (and we have only motors for gen1 boards) - I would not expect to be able to run soon the firmware we are working on, on the gen2 boards.
I do not remember what are you looking for (maybe just develop a board??) but I would suggest you to buy gen1 boards.

[Mystamo]

I do believe this is a gen1 board?

Regards,

Mo

[Restless]

2 minutes ago, Mystamo said:

I do believe this is a gen1 board?

Regards,

Mo

Yes that looks pretty similar to our dev board

 

Thanks for the input though. Like the way the RX/Tx is provided ... sadly its not on gen 1.

 

 

 

Just as i wrote about there might be a way to provide software serial for any pin selected ... but first i think we should solve the read input problem. Since i wasn't able to figure that out on the weekend :/ very disapointing

Edited December 14, 2015 by Restless

[electric_vehicle_lover]

Yes and you can look here for more information about the gen1 board and motor: https://github.com/generic-electric-unicycle/documentation/wiki/Generic-Electric-Unicycles

[Mystamo]

Well, as far as software development goes. I can be on board with development on the Gen1 boards.

As for designing new hardware. I would use the Gen2 as the benchmark. That controller can be made very generic and used in a wide variety of EV. No sense in continuing with an outdated design from a hardware standpoint.

There may be some changes needed to be made to the Gen1 software once developed to port to the Gen2 But I doubt it will be very involved. Good practice would be one that caters to both gen with a simple flip of a #define

Regards,

Mo

[lizardmech]

I found a chinese company that seems happy to produce a custom board and supply firmware as a base. Any specific hardware requests?

My initial idea is:

USB port that can flash firmware easily.

High end STM32 chip to allow much more development in the future.

canbus or something similar to connect to other devices so I can produce additional modules in the future.

Ability to operate it as a stand alone BLDC controller for ebikes, rc planes etc.

36-100v support so multiple battery chemistry and layouts are possible with only a software change.

Improved layout, monolithic TI mosfet driver and better mosfet location.

I was thinking about adding holes around the mosfets in the same pattern as cpu coolers use on motherboards. It would allow a huge variety of heatsinks to be mounted. Anyone have any input of preferred mosfet location?

[Restless]

That sounds interesting.

I like the idea for sure, but it divides a bit from the initial idea ... like buy or have an generic EUC and just improve by better FW.

 

My guess: Main Focus will be the Gen1 Generic Boards (which should be compatible with these boards) we could add more features and other stuff

 

BUT i also would like to upgrade, so thats the point why i like the improved design

Just for my info. Will it be a OpenSource design? Would be a nice improvement for the whole Project.

 

 

I think if they provide a firmware it will be more in $$$ to buy them, since we build our own, thats definitely not necessary

 

How much would it cost per Board? I think max price per Board has to stay < 20$ incl. shipping (thats my thought)

 

So my points for a board:

All Pins from the STM accessible (TP or whatever, but thats something I think is really a nice to have to improve. Specially for custom improvements)

USB - definitely a yes! prefered micro-usb port or just a pin header

CAN - (not necessary for me) interesting since its a spec from the STM32 but pretty complex, spi or i2c should / could me enough

Rx/Tx ports! At least one. Think max is 3, that would be awesome (BT, Debug, WIFI, whatever)

 

The STM32 hmm... a high end one sounds nice, but its also less compatible with the Generic Board in general :/

64kb flash really is not edge breaking. There is a 128kb version which should match our needs.

What i really would like to see is a STM32 with more Pinouts since we need them for improvements / additional modules. A 64Pin or 100Pin version would be sweet.

The STM32F103R(C-G) or STM32F103V(C-G) version could be the choice.

64Pins (STM32F103Rx) / 100Pins (STM32F103Vx)

Versions STM32F103RC/D/E/F/G same for the V version have 256kb+ Flash

 

 

 

Sorry if my post is a bit unstructured  but it was a lot of brainstorming

 

Kai

 

Edit: As a thought, interesting idea for RC-Planes but (since i play a lot with my multicopter) weight is everything... The Controller is too big and heavy. I dont think that will be one of the use cases  

Edited December 15, 2015 by Restless

[lizardmech]

I want to make this one higher end. The current $20 generics are good enough for basic use, but if you want something with performance like a gotway or kingsong you have no choice but to buy a brand unit and pay a lot. Then you buy one of those and 6 months later they revise the board design. So I want to get something with a stm32 f4 or f7 and very strong mosfets so that overheating and shutdowns isn't an issue even with big motors and heavier riders. If I can get this going my next step will be to create a highend BMS solution that can monitor and transmit data regarding each cell and adapt to different battery types and configurations. I hope to build some sort of battery magazine that does away with the tig welding and allows cells to be easily replaced to reduce the difficulty of trying to order entire battery packs from china.

 

Even if the firmware isn't shared it should be easy to share balance and BLDC code between both.