Jump to content

Firmware


jayjay23

Recommended Posts

Something to think about when it gets to firmware interoperability is - beside quite some other details - is the basic frequency source. Today I got my 30kmh controller and started to install it (I will make a new thread about it once it's more finished), and it has an external 8MHz osciallator, so probably the firmware relies on it instead of the internal as in my controller from the generic wheel.

I was also curious and the STM32 chip is exactly the same as mentioned above (and MP6050) and there is also again a SWD connection which I already soldered the pins to rigth from the beginning. Once I can power it on being installed I can just check how is the protection here (without unlock :-)).

I checked the PIN out according to the PCB layout and it should be the same order then previously, but without warranty, I will check with the JTAG/SWD adapter and existing wire.

img_1009824_small_e.thumb.jpg.dc80533f9b

Edited by jayjay23
  • Upvote 1
Link to comment
Share on other sites

One would normally expect the chip to be locked unless a particular factory got lazy.

There's no need to buy an expensive programmer for STM32 parts - any of the "discovery" series eval boards for any member of the STM32 family should work with any other chip from any STM32 family as an off-board target (just don't buy an STM8 one as those are different).  Many of these boards are in the $10 range.

Edited by PedalFaster
  • Upvote 1
Link to comment
Share on other sites

@Rash: Ok, thanks, still I'm too curious and will just give it a short try, unfortunately less time atm.

@PedalFaster: Ok, can you be more precise on how to do it. What I did is, without any preknowledge of the chip, went down from the connectors I've seen on the board, so at this time I could not choose one from several roads. Do you mean that you can flash a discovery STM32 with a certain firmware so it can communicate to the controller STM32 or do you mean to reroute one of the debug access ways from the discovery board to the controller board? The JTAG adapter I bought was a very, very, very cheap one compared to what else is there on the market, and finally it has just a FTDI2322 on it, something similar (FTDI232) of what I already used for the LPC chips programmer and which is well known from nearly all those cheap USB-RS232 converters.

@oschemes: I currently build up my knowledge so nothing I can provide right away, but the topic is very interesting so motivation is currently high and I have all the hardware to play with.

An short update into the direction of a own firmware is that I analysed and documented the controller layout as far as I understood it. I read some good articles on BLDC motor controlling and everything that's digital is very simple to see, so I know were all the leds, the I2C(MPU6050), the hall sensors, the H bridge FETs are, but I'm very unsure about the analog stuff, there are 4 operation amplifiers and 2 wires which go somewhere. Just from logically thinking I could think of these missing functions: Measurement of total power (ampere) which is needed for good BLDC control, maybe there is 3 phases power measurment also. And one of the unknown wires is probably the voltage measurement.

  • Upvote 2
Link to comment
Share on other sites

I mean that you can use a $10 discovery board as an SWD adapter to program or debug an STM32 chip on your board (most of these boards are wired for SWD, not full JTAG)

An FT2232 is another option, yes, typically using a different software chain such as openocd rather than ST-specific vendor or open source tools.

One of the things you will need to figure out is if the board has electronic rotor position detection in addition to the hall sensors - some e-bike controllers have that (usable at high speed), and as a result they can discover the hall sensor wiring for themselves (to use at low speed) rather than having to have it explicitly programmed.  

For your op-amps, figure out where the inputs come from

One thing to watch out for on an e-wheel controller vs. some commonly hacked R/C aircraft ESC is that while currents are comparable or lower, you have a much higher, and potentially dangerous, power rail to be careful of.

 

 

  • Upvote 2
Link to comment
Share on other sites

The device uses hall sensor feedback quite definitely for speed and position at low speeds.  Not sure if it switches to phase sensing at high speeds.. I think not, but I'm not sure.

The hall feedback is hard-wired, not determined through sensing or anything fancy.

One interesting note is that "high-speed" boards seem to have buffers on the hall inputs.  This leads me to believe that speedup hacks may be limited by the slow switching of the onboard hall sensors.  But perhaps we can just lower the pull up resistors to lower their delay IF the speed calculation is ever found and hacked...

 

The op amps measure phase current, one for each half-bridge.

 

Since you can do some crude debugging using the swd port, I did kill one board in an interesting manner by setting a breakpoint in the "beep" routine for overspeed.  My hope was to trap the stack after tilting the airwheel in free air and causing an overspeed warning.  My idea was stupid, though.  Although the main loop was successfully breakpointed the ISRs kept processing tilt and accelerating the motor until BANG!  I believe what happened was the motor outpaced the hall sensors and the AW mistakenly tried to energize the free phase.  It blew one phase entirely, and sadly also blew the op amp and STM's ADC on that channel.  That board could never be repaired for some reason..

So for what it's worth, breakpoints in a motor feedback system are probably not a good idea.  :)

Edited by oschemes
  • Upvote 2
Link to comment
Share on other sites

So for what it's worth, breakpoints in a motor feedback system are probably not a good idea.  :)

Normally, a breakpoint stops the processor core itself.  For an ISR to keep running would require that the software running on the debug host re-enabled things, or that the breakpoint may not have occurred or the SWD connection failed somehow.  It's also possible that the chip restarted somehow, perhaps a watchdog.

I'd agree that running the debugger or doing much bench testing of a motion system without some additional limiting is risky - at the least you probably want a kill switch and might consider a fuse or circuit breaker or current limited supply, which could be set lower than normal since you probably don't have a usual load to move.

My concern with a breakpoint in something with software commutation is more that a phase might remain energized longer than it should - though if the board uses floating N-channel drivers on the high side, those could possibly de-energize themselves (albeit passing through through a region of higher than normal loss) if they don't continue to be actively switched.

Link to comment
Share on other sites

One more thing I have to check is on the top, buzzer and I2C int, I read that the MPU6050 can be polled by just using the 2 I2C lines or it can trigger interrupt on data ready via a separate line, but I guess the missing line is buzzer and the MPU6050 is polled,

One more comment, if all my assumptions so far are correct one of the two missing lines (PIN 25 and 15) is battery voltage measurement.

  • Upvote 1
Link to comment
Share on other sites

  • 3 weeks later...
  • 3 weeks later...

Jayjay23, great work!!!

In past I worked with STM32F1xx, to make a controller for a BLDC electric bicycle:
https://www.youtube.com/watch?v=trihb86_mnw
https://www.youtube.com/watch?v=wrrfMGUwaAM
https://www.youtube.com/watch?v=M8jWLfEaA3E

Unfortunately, I lost the wiki were I documented my work :-(
But the firmware and schematic are still on my github: https://github.com/casainho/EBike-Smart-Controller/

NOTE: the controller uses hall sensors, I was never able to make Back EMF working...
I did it for fun and to learn. My professional background is firmware.

I assembled my own electric bicycles using chinese DIY electric bicycles kits.

I also bought, just yesterday, that cheap chinese EUC with the same image as yours and I want to hack it!!!!!!!! <3

Jayjay23, why don't we write our own firmware from the start as OpenSource collaborative project??

 

  • Upvote 2
Link to comment
Share on other sites

Jayjay23, I read all your messages. You now have a lot of information!!

Can you please setup a github for your code?? - even maybe using the wiki from github, we could document the code and the board.

I bet this cheap generic unicycles will be available for long time and so they will be a good platform for us to learn and improve the technology.

An example of an OpenSource firmware, for MP3 players, that were developed by the community to improve their own devices. Rockbox started 13 years ago and is still alive!!!
The same firmware have ports for many different hardware/devices: https://en.wikipedia.org/wiki/Rockboxhttp://www.rockbox.org/wiki/WebHome

If I burn the board of my EUC, can I buy a new one somewhere??

What are the tools needed to develop?? (I have a JTAG, Linux, OpenOCD, Eclipse, Osciloscope, lab power supply and soldering iron with hot air. I also have 20 lithium 14500 cells ready to make a battery pack)

Link to comment
Share on other sites

Hi @electric_vehicle_lover,

I would prefer to make something public only if it is of use for somebody, as long as the state is in development  and there are only a few people I would prefer a repository that can be opened to the public once there is something useful in it :-)

You are maybe right with how long the generics will live, at least I think any development will be very useful also for later adaptions to other platforms which may be not much different anyway.

> If I burn the board of my EUC, can I buy a new one somewhere??

Yes, they are available from various china stores (e.g. this one http://www.alibaba.com/product-detail/controller-for-self-balance-unicycle_60253695672.html?spm=a2700.7724838.0.0.LN13YL is the exact layout of what I worked on in this thread). Actually I plan to order

at least one to build another wheel, but maybe I can not resist to have some spare parts in stock, in case some motor controller development destroys something.

> What are the tools needed to develop??

Well there are many, many options, as I'm a console guy, I choose the one with less GUI, that is no IDE at all and just preparing the proper makefile and surrounding files using

nedit or any other text editor for programming. An oscilloscope could be valuable at any point of time for quite a lot of debugging purposes (just general). JTAG / Linux / OpenOCD is what I use for debugging (well together with GDB). Does your lab power supply reaches 60 or better 70V? If so it's very very useful as you could power the controller directly from it and could also use low currents to reduce risk of damage, I actually have though about getting one, but even cheap ones were already a few hundred euros (I think 139,- was the cheapest).

For your cells, well I'm not sure, if you reach the nominal 60V you can use them for testing for sure, if you have a loader (with security circuit).

If you are ok, I can setup a git repository to share between developers and open it up more when there is really something useful.

 

  • Upvote 2
Link to comment
Share on other sites

@jayjay23, thank you for sharing your code on github: https://github.com/qjayjayp/myewheel.org

I don't know other way to develop OpenSource colaborative projects without public code and documentation. It is for sure usefull for anyone that will search and want to learn about the subject. Will help to attract developers/testers/users.

Next step, I think could be documenting the circuit. Seems you already figure some pins of the STM32Fxxx and would be great if you could start drawing the schematic. And since you are a Linux guy ( I believe), you could use the KiCAD software :-)

I will read your current firmware code and do pull requests - for example, the readme file that explains how to build the code, toolchain used, etc.

Link to comment
Share on other sites

Hi @electric_vehicle_lover,

it's not nice of you not respecting some very basic wishes, you could risk burning openness from my side (if not already). I appreciate any contribution, bit I would like to talk to people and see whether there is enough drive to contribute, having a ton of people who give nice recommendations is not the way I prefer to proceed. If there is real input to the project I will really appreciate it.

Which is the areas you can give a piece to the whole puzzle, you said you are experienced with ARM programming, so I understood you can contribute to writing parts of the code right?

Well anyway have to leave for work now, so stay tuned.

  • Upvote 2
Link to comment
Share on other sites

Hi @jayjay23.

I would like to contribute only to an OpenSource project. I can write firmware (some experience with for ARM STM32F1xx and others), I can use oscilloscope and power supply, to test the circuit. I can also draw a circuit. In resume, I can develop and test.

I am really interested in learning more about electronics and firmware technology for this cheap generics EC. I can for sure go ahead and create a git repo for this project BUT I am only interested on a project that is OpenSource and collaborative.

  • Upvote 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...