Bafang M500/M600 thread

[4πr^2]

NXP has more papers about things than you might expect:
https://www.nxp.com/docs/en/application-note/AN5327.pdf

I knew that reconstruction of the phase current is possible because others also do that but seems is the more complex to implement, I wish they were doing the most simple way
Thanks for pointing to this document. Maybe you could link on the repository documentation this document about the motor control done on this motor controller.

I updated the hardware readme accordingly

Yes, I do see only the one shunt resistor and on the main bus, so likely doing current reconstruction - though I think that is the simple way, no? Just one resistor and some math, not the extra power dissipation and heat of three more resistors? Plus, I think this is what makes 'ludicrous mode' option possible... just parallel in a second resistor so the controller only 'sees' half the current?

I measure my shunt resistor at 0.049 ohms - using some decent Agilent and Amprobe meters for voltage and current, then calculating R because it is so low. So taking the configuration to be two 0.01 ohm resistors in parallel plus associated tolerances in resistors and measuring devices. I guess there is a bit of a markup in the 'ludi mod' price.... parts: one resistor, $0.59, knowing where to place it: $299.41!

I've updated the image - sorry I don't seem to get github working... will keep trying there.

 

[ornias]

NXP has more papers about things than you might expect:
https://www.nxp.com/docs/en/application-note/AN5327.pdf

I knew that reconstruction of the phase current is possible because others also do that but seems is the more complex to implement, I wish they were doing the most simple way
Thanks for pointing to this document. Maybe you could link on the repository documentation this document about the motor control done on this motor controller.

I updated the hardware readme accordingly

Yes, I do see only the one shunt resistor and on the main bus, so likely doing current reconstruction - though I think that is the simple way, no? Just one resistor and some math, not the extra power dissipation and heat of three more resistors? Plus, I think this is what makes 'ludicrous mode' option possible... just parallel in a second resistor so the controller only 'sees' half the current?

I measure my shunt resistor at 0.049 ohms - using some decent Agilent and Amprobe meters for voltage and current, then calculating R because it is so low. So taking the configuration to be two 0.01 ohm resistors in parallel plus associated tolerances in resistors and measuring devices. I guess there is a bit of a markup in the 'ludi mod' price.... parts: one resistor, $0.59, knowing where to place it: $299.41!

I've updated the image - sorry I don't seem to get github working... will keep trying there.

To be fair:
I kinda like the board layout, it's heavily overbuild for its purpose, nicely soldered and pretty well designed imho

Dont worry about github, I can manage to copy and format things from here as well

About Ludi: yeah those shunts where known for some time, but indeed the knowhow how to do it right has a markup.
If my work on the firmware mods works out I might send one to Chris Ludi one with 48v/42a set for testing, might save them 0,60 and some labor

 

[casainho]

ornias, you are doing a great work by putting all the information on the README files on the repository. I have a big suggestion:

Focus the repository main / front page of repository for final users instead and dedicate only last 1/3 for developers. The idea is that most of users are final users and will be lost on the technical details, so, give them only what they need, like the Hardware page that has the wiring connections, specifications, battery and power - the pictures and details about the motor controller, I think should be on pages for developers.

Also, highlight on the main page the actual extra value this project can bring to them, which I think is a place where they can find different original firmware to try and how they can install them.

Also for final users (maybe on a dedicated page), a important missing information are links to shops, where to buy motor parts. Also some notes and links about motor disassembling for repair.
And maybe some pictures of bicycles, taken from Facebook group for instance, just as example / inspiration of type of bicycles the users can buy with this motor, and links / names of this shops / brands.

For developers, I would mostly link a main developer page to bring them there, maybe put a short phrase with some keywords like "Hardware motor controller and firmware for developers".

Also will be better if you put short links and not the full links on the text.

 

[ornias]

ornias, you are doing a great work by putting all the information on the README files on the repository. I have a big suggestion:

Focus the repository main / front page of repository for final users instead and dedicate only last 1/3 for developers. The idea is that most of users are final users and will be lost on the technical details, so, give them only what they need, like the Hardware page that has the wiring connections, specifications, battery and power - the pictures and details about the motor controller, I think should be on pages for developers.

Also, highlight on the main page the actual extra value this project can bring to them, which I think is a place where they can find different original firmware to try and how they can install them.

Also for final users (maybe on a dedicated page), a important missing information are links to shops, where to buy motor parts. Also some notes and links about motor disassembling for repair.
And maybe some pictures of bicycles, taken from Facebook group for instance, just as example / inspiration of type of bicycles the users can buy with this motor, and links / names of this shops / brands.

For developers, I would mostly link a main developer page to bring them there, maybe put a short phrase with some keywords like "Hardware motor controller and firmware for developers".

Also will be better if you put short links and not the full links on the text.

We currently have nothing to offer end-users and it is a development project.

I just document for other developers what I find out, so others can continue my work someday. I donnot document anything with the expectation end-users are going to use it. A github repository is a resource for developers,

People should start working on this shit, instead of bothering if my documentation is perfect for the average joe, because there is nothing we can actually currently offer to the average joe.

It's a WIP frontpage and I'll get to change it eventually, it's really of zero importance if we are not going to offer anything to the end user some time soon (tm). It's also already pretty outdated, so your comments about it make close to zero sense and distract me greatly.

i'm not going to distract myself with such unimportant BS, if you've visited by other big project you know i'm pretty well capable of nice frontpages. But currently that should not be something we put our limited time and energy into.

Also:
My formatting sucks and i'm aware of that, i'm quickly writhing things down as I go and i'm not going to bother perfecting the document formatting at this stage. I want the development to speed-up, not slow-down because lead devs get distracted by the length of some dumb url somewhere on a development-document-draft.

 

[casainho]

ornias, you are doing a great work by putting all the information on the README files on the repository. I have a big suggestion:

Focus the repository main / front page of repository for final users instead and dedicate only last 1/3 for developers. The idea is that most of users are final users and will be lost on the technical details, so, give them only what they need, like the Hardware page that has the wiring connections, specifications, battery and power - the pictures and details about the motor controller, I think should be on pages for developers.

Also, highlight on the main page the actual extra value this project can bring to them, which I think is a place where they can find different original firmware to try and how they can install them.

Also for final users (maybe on a dedicated page), a important missing information are links to shops, where to buy motor parts. Also some notes and links about motor disassembling for repair.
And maybe some pictures of bicycles, taken from Facebook group for instance, just as example / inspiration of type of bicycles the users can buy with this motor, and links / names of this shops / brands.

For developers, I would mostly link a main developer page to bring them there, maybe put a short phrase with some keywords like "Hardware motor controller and firmware for developers".

Also will be better if you put short links and not the full links on the text.

We currently have nothing to offer end-users and it is a development project.

I just document for other developers what I find out, so others can continue my work someday. I donnot document anything with the expectation end-users are going to use it. A github repository is a resource for developers,

People should start working on this shit, instead of bothering if my documentation is perfect for the average joe, because there is nothing we can actually currently offer to the average joe.

It's a WIP frontpage and I'll get to change it eventually, it's really of zero importance if we are not going to offer anything to the end user some time soon (tm). It's also already pretty outdated, so your comments about it make close to zero sense and distract me greatly.

i'm not going to distract myself with such unimportant BS, if you've visited by other big project you know i'm pretty well capable of nice frontpages. But currently that should not be something we put our limited time and energy into.

Also:
My formatting sucks and i'm aware of that, i'm quickly writhing things down as I go and i'm not going to bother perfecting the document formatting at this stage. I want the development to speed-up, not slow-down because lead devs get distracted by the length of some dumb url somewhere on a development-document-draft.

Your reaction is strange to me. Following the last comments here and on Github, seems we are near to get the original firmware with changes for different currents and voltages and that will be for sure for final users, as the Bafang tool to flash the firmware and the firmware files are for final users, no way this users are developers.

And you are disregarding the other efforts, when you say "People should start working on this shit ...", like if until now there was no work from the others.

 

[ornias]

ornias, you are doing a great work by putting all the information on the README files on the repository. I have a big suggestion:

Focus the repository main / front page of repository for final users instead and dedicate only last 1/3 for developers. The idea is that most of users are final users and will be lost on the technical details, so, give them only what they need, like the Hardware page that has the wiring connections, specifications, battery and power - the pictures and details about the motor controller, I think should be on pages for developers.

Also, highlight on the main page the actual extra value this project can bring to them, which I think is a place where they can find different original firmware to try and how they can install them.

Also for final users (maybe on a dedicated page), a important missing information are links to shops, where to buy motor parts. Also some notes and links about motor disassembling for repair.
And maybe some pictures of bicycles, taken from Facebook group for instance, just as example / inspiration of type of bicycles the users can buy with this motor, and links / names of this shops / brands.

For developers, I would mostly link a main developer page to bring them there, maybe put a short phrase with some keywords like "Hardware motor controller and firmware for developers".

Also will be better if you put short links and not the full links on the text.

We currently have nothing to offer end-users and it is a development project.

I just document for other developers what I find out, so others can continue my work someday. I donnot document anything with the expectation end-users are going to use it. A github repository is a resource for developers,

People should start working on this shit, instead of bothering if my documentation is perfect for the average joe, because there is nothing we can actually currently offer to the average joe.

It's a WIP frontpage and I'll get to change it eventually, it's really of zero importance if we are not going to offer anything to the end user some time soon (tm). It's also already pretty outdated, so your comments about it make close to zero sense and distract me greatly.

i'm not going to distract myself with such unimportant BS, if you've visited by other big project you know i'm pretty well capable of nice frontpages. But currently that should not be something we put our limited time and energy into.

Also:
My formatting sucks and i'm aware of that, i'm quickly writhing things down as I go and i'm not going to bother perfecting the document formatting at this stage. I want the development to speed-up, not slow-down because lead devs get distracted by the length of some dumb url somewhere on a development-document-draft.

Your reaction is strange to me. Following the last comments here and on Github, seems we are near to get the original firmware with changes for different currents and voltages and that will be for sure for final users, as the Bafang tool to flash the firmware and the firmware files are for final users, no way this users are developers.

And you are disregarding the other efforts, when you say "People should start working on this shit ...", like if until now there was no work from the others.

If that work is done, I ofcoarse will document accordingly. But at the moment we need testing and confirmation.

I'm not disregarding other efforts, i'm saying those efforts take precedence over stupid discussions over a readme file. You aimed your comment at me, which distracted me with something irrelevant imho. Please next time just file a github issue if you've things on github that need work.

Sorry for my tone, but I really prefer to stay focussed on my actual goals instead of getting sidetracked on readme's. I really get support annoyed over it. Not because of the question, but because It breaks my "flow", which meant I got nothing done this morning for example.

 

[casainho]

Sorry for my tone, but I really prefer to stay focussed on my actual goals instead of getting sidetracked on readme's. I really get support annoyed over it. Not because of the question, but because It breaks my "flow", which meant I got nothing done this morning for example.

You can manage your notifications to avoid being distracted during your flow.

And seems I wrongly assumed you did like structuring and documenting, that is why I asked you.

I can not help more on this phase, as I do not have an ebike with this motor and I do not have any hardware. But, the more I see the project going on, the soon I will want to invest on that ebike. I will be following closely the project.

And I also need to develop the firmware for TSDZ2 V2 hardware, which I have the hardware for and ebikes with it. And I hope what I will learn there, will help me on future projects like this one. And I really want to believe in small and light motors like the M800, that I hope we can push it to twice of the 200W, that would be great for a motor of 2.3 kgs, on road / gravel and even light MTBs - which is what I am looking for.

 

[ornias]

@4πr^2 and @casainho

I think thats a JTAG connector right there :-D

 

[casainho]

@4πr^2 and @casainho

I think thats a JTAG connector right there :-D

As I wrote on Github,
That is nice that big header for JTAG. Maybe they need that to be fast programming during production and testing of the board.

I would expect to use that connection only to flash the firmware and debug it for development.

Be careful, almost for sure there is a bootloader on the firmware specifically for communication with the CANBUS software on PC and update the firmware on the controller. We do not have this bootloader, we only have the firmware. If you connect you JLink and for some reason erase.the microcontroller, the bootloader will be removed and the controller will not work anymore.

 

[4πr^2]

Possibly so. The outer-most holes are 5V and ground, the inner two holes have 10K resistors for pull-up and pull-down, respectively. I've labeled them as well as some pins in the smaller sockets in a new image.

[EDIT: Noticed an error in the image which was uploaded here. Skip to my next post in this thread for an updated version.]
https://endless-sphere.com/forums/viewtopic.php?f=28&t=100777&p=1668218#p1668218

 

[mjohn]

Hi M500 tweakers,

I admire everyone who is able to do this digital stuff and I hope that the result is also useful for simple end users like me. Fingers crossed that you are successful.
In all this discussion and exchange of ideas about DIY controllers and firmware I would like to ask a more simple question concerning the existing software modifications. Was anyone able to adjust the max speed using the USB2CAN adapter lately with the latest M500 motor and firmware? Or in other words, did Bafang close this door?

I tried it multiple times (as posted before) and it did not work for me. I would appreciate some feedback and help. Even 'the door is closed' ... would help.

Tks

 

[ornias]

Hi M500 tweakers,

I admire everyone who is able to do this digital stuff and I hope that the result is also useful for simple end users like me. Fingers crossed that you are successful.
In all this discussion and exchange of ideas about DIY controllers and firmware I would like to ask a more simple question concerning the existing software modifications. Was anyone able to adjust the max speed using the USB2CAN adapter lately with the latest M500 motor and firmware? Or in other words, did Bafang close this door?

I tried it multiple times (as posted before) and it did not work for me. I would appreciate some feedback and help. Even 'the door is closed' ... would help.

Tks

The earlier posted guide is actually wrong, the address is wrong mostly.
Afaik the function still exists.
Try the same instructions with the following frameid:
05103203

 

[savaoaknyc]

Hi Guys,

can someone measure the exact dimensions of the m500 or m600.I have some frames for e8000 shimano and i am wondering if somehow i can make the m500 or m600 to fit the frame.

Here some pictures from the framesshimano1.JPGshimano2.JPG

Hi,
I am in the exact situation, did you manage to check the dimensions or even better did you try it?

Hi i have bought dengfu with bafang so we did some trials, it is pretty close.

I would love to do this like this:
m800 into m500/600 slot

 

[ornias]

Some news on the reverse enginering and opensource firmware effort:
- We have as of today also managed to reverse engineer the Firmware Upgrade protocol which is used by BESST to upgrade controller firmwares. This means that in the future we will be able to create update software that does not require the BESST tool
- We also figured out why m500 files and not be uploaded to the m600, and the other way around.
- We've managed to unlock the hidden configuration GUI in BESST, although we have not seen any controller that actually responds on the configuration "read" and "write" commands. We encourage anyone to try it though, it might also be compatible with M620 CANBUS version.

 

[4πr^2]

Noticed an error in my previous image where the CAN low/CAN high labels were reversed on the 22 pin header. This is the corrected image:

 

[ornias]

Noticed an error in my previous image where the CAN low/CAN high labels were reversed on the 22 pin header. This is the corrected image:

Do you also happen to have a j-link or similair SWD tool, to check if you can get SWD data out of that 4 pin?
(and any experience using it)
https://nl.aliexpress.com/wholesale?catId=0&initiative_id=SB_20210728044627&SearchText=ST-LINK%2FV2+swd

 

[4πr^2]

Unfortunately, nothing like that on hand. I put an oscilloscope on the high/low terminals last night and did not see any recognizable data stream just 'flowing', but possibly it needs a proper handshake or two-way communication initiation?

I'm not opposed to new equipment and learning a new skill. Would either of these work for the purpose?

https://www.ebay.com/itm/224352543979

https://www.ebay.com/itm/231719363925

 

[ornias]

Unfortunately, nothing like that on hand. I put an oscilloscope on the high/low terminals last night and did not see any recognizable data stream just 'flowing', but possibly it needs a proper handshake or two-way communication initiation?

I'm not opposed to new equipment and learning a new skill. Would either of these work for the purpose?

https://www.ebay.com/itm/224352543979

https://www.ebay.com/itm/231719363925

SWCLK should and SWIO should both be supplied by the connecting device and not by the board itself, so no signal on the osci seems to be a good sign

Yeah both of those should work, one (cheap one) is a clone of the other (bigger one). But i've not read bad quality reports about either of them...

New skills always pay of someday, so I totally 100% understand you there
Maybe @casainho could give you some advice which workflow he would follow on these to get more info we could use.
For example I could really use a complete dump, including firmware, bootloader and memory addresses.

 

[casainho]

Unfortunately, nothing like that on hand. I put an oscilloscope on the high/low terminals last night and did not see any recognizable data stream just 'flowing', but possibly it needs a proper handshake or two-way communication initiation?

I'm not opposed to new equipment and learning a new skill. Would either of these work for the purpose?

https://www.ebay.com/itm/224352543979

https://www.ebay.com/itm/231719363925

SWCLK should and SWIO should both be supplied by the connecting device and not by the board itself, so no signal on the osci seems to be a good sign

Yeah both of those should work, one (cheap one) is a clone of the other (bigger one). But i've not read bad quality reports about either of them...

New skills always pay of someday, so I totally 100% understand you there
Maybe @casainho could give you some advice which workflow he would follow on these to get more info we could use.
For example I could really use a complete dump, including firmware, bootloader and memory addresses.

You need the JLink, not the STLinkV2.

Follow this page that I wrote, for how to setup the development tools to program the microcontroller on TSDZ2 v2 hardware, that uses JLink: https://github.com/OpenSourceEBike/TSDZ2_motor_controller_v2/blob/master/Documentation/how_to_develop.md

And you will most probably not be able to get a dump of original firmware, it is almost for sure locked and you will need to erase before be able to program a new one.

 

[ornias]

And you will most probably not be able to get a dump of original firmware, it is almost for sure locked and you will need to erase before be able to program a new one.

I'm not so sure about that tbh, there are a lot of protection features supported by the s32k1xx series SoC and i've yet to encounter Bafang using ANY of them. Like:
- No firmware validation
- No firmware signing
- No firmware encryption
- No in-transit-encryption.

Nothing.

 

[4πr^2]

OK - JLink is on order. I will poke around and see if there is anything to see!

In other news, believe I've found the weakest component so far...looks like they are running battery voltage through an SMPS buck converter before sending it on to the rest of the system and the linear regulators. A 13S "48V" battery could be approaching 54V fully charged and that is just too much to slam into simple LVRs. The SMPS looks to be based on an MP2459 driver which has rated max voltage input of 55V and "absolute maximum" of 60V.

https://www.monolithicpower.com/en/documentview/productdocument/index/version/2/document_type/Datasheet/lang/en/sku/MP2459/document_id/259

So if anyone is thinking of hotrodding the controller beyond a 14S pack, which might already put you a bit north of 58V fully charged, then it might be wise to do some surgery on the 2459 and provide a more robust way to get down to 'nominal' voltage levels.

 

[savaoaknyc]

Guys do you think that the m600 controller might fit in the m500 motor?

 

[ornias]

Guys do you think that the m600 controller might fit in the m500 motor?

Physically for sure.
You do need to rewire the phase colors though....

 

[ornias]

OK - JLink is on order. I will poke around and see if there is anything to see!

In other news, believe I've found the weakest component so far...looks like they are running battery voltage through an SMPS buck converter before sending it on to the rest of the system and the linear regulators. A 13S "48V" battery could be approaching 54V fully charged and that is just too much to slam into simple LVRs. The SMPS looks to be based on an MP2459 driver which has rated max voltage input of 55V and "absolute maximum" of 60V.

https://www.monolithicpower.com/en/documentview/productdocument/index/version/2/document_type/Datasheet/lang/en/sku/MP2459/document_id/259

So if anyone is thinking of hotrodding the controller beyond a 14S pack, which might already put you a bit north of 58V fully charged, then it might be wise to do some surgery on the 2459 and provide a more robust way to get down to 'nominal' voltage levels.

Thank you, this explains their hard maximum on 58v in firmware. If you go over the board wont start.

 

[casainho]

OK - JLink is on order. I will poke around and see if there is anything to see!

In other news, believe I've found the weakest component so far...looks like they are running battery voltage through an SMPS buck converter before sending it on to the rest of the system and the linear regulators. A 13S "48V" battery could be approaching 54V fully charged and that is just too much to slam into simple LVRs. The SMPS looks to be based on an MP2459 driver which has rated max voltage input of 55V and "absolute maximum" of 60V.

https://www.monolithicpower.com/en/documentview/productdocument/index/version/2/document_type/Datasheet/lang/en/sku/MP2459/document_id/259

So if anyone is thinking of hotrodding the controller beyond a 14S pack, which might already put you a bit north of 58V fully charged, then it might be wise to do some surgery on the 2459 and provide a more robust way to get down to 'nominal' voltage levels.

Thank you, this explains their hard maximum on 58v in firmware. If you go over the board wont start.

I use only 14S with TSDZ2 and I use this very small DC-DC module, I am not aware of a smaller one. I think there is a 12V version output. Do you know what voltages does the controller use?

STH0548S05: XP Power Surface Mount DC-DC Switching Regulator, 5V dc Output Voltage, 9 → 72V dc Input Voltage, 500mA Output