Originally Posted by simonk

Ok, I see it with git HEAD bs_nfet.hex and avrdude 5.11.1 as well:

avrdude.stock: verification error, first mismatch at byte 0x0840
0xff != 0x95

It actually seems to be writing the same thing, just verifying incorrectly. The bug seems to be in the optimization for jumping over holes. Flashing unfinished pages is fine, and flashing a small single-part .hex is fine, but when flashing a .hex file with holes or pages with just 0xff, it complains about the parts in the middle that it never flashed containing non-0xff data. This didn't show up before because the main code segment hasn't shrunk since the boot-loader addition until now.

The problem is that the writing part still optimizes all-0xff pages away (the same as the address not being specified), but the verification still forgets about it (even with -D(on't erase)), so I don't see a way of working around avrdude's bug unless I make the boot loader try to tidy up after the end of the main segment before avrdude can read it back. It works if we pad it with nops (0x00) instead...or I guess I could just only release new versions when there are enough new features to make it bigger.

Did you also try the avrdude I am bundling with the kkflashtool? It is SVN version build after the 5.11.1 was released. I unfortunately don't remember the revision number.

Best Christian

Originally Posted by ABLomas

it's the same as RedBrick 200A, just much cheaper. Used birdie70a.hex (again with SLOW_THROTTLE, BRAKE) - works OK, but didn't tested with more than 40A (no spare motor that could take such current). Only problem - MLF package, not so easy to solder pins...

No! The picture on your post shows a voltage doubler supplying the IR2101 drivers at <10V. The 200A controllers have an XXXX662 voltage tripler whioch can supply 12V with a lot more current.

Originally Posted by simonk

The problem is that the writing part still optimizes all-0xff pages away (the same as the address not being specified), but the verification still forgets about it (even with -D(on't erase)), so I don't see a way of working around avrdude's bug unless I make the boot loader try to tidy up after the end of the main segment before avrdude can read it back. It works if we pad it with nops (0x00) instead...or I guess I could just only release new versions when there are enough new features to make it bigger.

Offer smaller versions without the bootloader? And a separate bootloader?

Originally Posted by George Shering

No! The picture on your post shows a voltage doubler supplying the IR2101 drivers at <10V. The 200A controllers have an XXXX662 voltage tripler whioch can supply 12V with a lot more current.

Well, probably.
But they still rated as "200A peak" @ HiModel and other places. Currently i do not have setup requiring such current, but should get one motor soon - needs ~160A peak, will be good test...

Originally Posted by simonk

The problem is that the writing part still optimizes all-0xff pages away (the same as the address not being specified), but the verification still forgets about it (even with -D(on't erase)), so I don't see a way of working around avrdude's bug unless I make the boot loader try to tidy up after the end of the main segment before avrdude can read it back. It works if we pad it with nops (0x00) instead...or I guess I could just only release new versions when there are enough new features to make it bigger.

Is the problem the completely blank pages? I thought it's just those few bytes at the end of the current page, those need to be set to 0xFF like I think the Arduino bootloader does (maybe I'm wrong). In other words if a write comes in and doesn't completely fill the page then 0xFF padding needs to be added at the end. Whole empty 0xFF pages don't need to be padded though because avrdude won't verify them. I don't know, I'm just guessing.

I actually have never looked at how the STK500 protocol works so I don't really know what I'm talking about. If there is no such thing as page alignment of a specific size then it would be impossible to tell how much padding needs to be added.

He is using long phase wires, laying around in circles, could the bemf be perturbed in that case?

manu

Originally Posted by alll

For Simon?

manu

Esc - motor - prop compability
http://www.rcgroups.com/forums/showp...&postcount=236

Hi-

Simon came up with this:
When you want to test the ESC reaction on fast throttle changes it might not be sufficient to use a servo tester or just move the throttle stick.
Just program your transmitter such, that a switch sets the throttle to max.

I used a mix of a 100% switch to my normal throttle, so I can set the throttle from what ever the stick input is to 100% with the flip of this switch- easy and efficient!



Greets

Originally Posted by LittleMo

Is the problem the completely blank pages?

It doesn't matter if the page is full or not. It's the fact that it is verifying pages that it never flashed. It skips verification properly if you only write one segment with no gaps, so what George suggested would work, but this would make it more complicated for people to flash since it would turn into a two-step process. So, hmmm....

Originally Posted by alll

He is using long phase wires, laying around in circles, could the bemf be perturbed in that case?

Hey manu Actually, longer wires (higher resistance) typically helps the issue. Meanwhile, I commented on the video and he replied that it works fine with the latest release.

Hello, can please someone advice with my problem?

I have HobbyWing Pentium 40A ESC connected to RCTimer BC3536-11 motor.
I have issues with this configuration and unfortunately it seems that this ESC cannot handle this motor
I'm building a HEXa so I have 6 motors and 6 ESC's.. tried almost all of them with same results.

Problem stock firmware: When applying throttle, it works fine until about 50%. If pushing more, motor is having erratic power dropouts and actually can slow down so much that it almost stops - its unusable.

SimonK tp_nfet.hex: Situation improved, but still a lot of drop outs (with strange sounds) and sometime even erratic behaviour.

I have modified tp_nfet.hex to 8Mhz as I have seen someone proposed this solution. I have set lfuse=0xa4 hfuse=0xdf.
This has improved the overall performance, but still when the throttle is at about 75% the motor looses power and it didn't catch up until 100% - then it turns on to full speed.
I have tried to modify the value MOTOR_ADVANCE - currently it is at 30.

WORTH to mention - when there is no propeller on motor, it works fine (even with stock firmware)

Please see the attached video with latest setup (best so far).

Hobbywing Pentium 40a ESC SimonK firmware (0 min 45 sec)

Originally Posted by simonk

It doesn't matter if the page is full or not. It's the fact that it is verifying pages that it never flashed. It skips verification properly if you only write one segment with no gaps, so what George suggested would work, but this would make it more complicated for people to flash since it would turn into a two-step process. So, hmmm....

I don't know why I didn't try this in the first place but I just tried flashing it with the Arduino bootloader and it fails also so yes, you're correct. I wouldn't worry about it then, nothing that can be done.

Just one of those things that will have to be a known issue. "Upgrade your avrdude."

Originally Posted by LazyZero

Did you also try the avrdude I am bundling with the kkflashtool? It is SVN version build after the 5.11.1 was released. I unfortunately don't remember the revision number.

I couldn't try the Linux version (libusb version fail) but I ran the Windows version via WINE and it worked. I believe I was using version 0.70beta8 of your tool. I just tested the bundled version of avrdude.exe directly, not the whole kkflashtool.

Originally Posted by LittleMo

I couldn't try the Linux version (libusb version fail) but I ran the Windows version via WINE and it worked. I believe I was using version 0.70beta8 of your tool.

Very good too know. But what is the problem with libusb

Christian

Originally Posted by LazyZero

Very good too know. But what is the problem with libusb

The bundled Linux avrdude is 32-bit and I don't have a 32-bit version of libusb (Arch Linux).

Originally Posted by alfi666

I have HobbyWing Pentium 40A ESC connected to RCTimer BC3536-11 motor.
Problem stock firmware: When applying throttle, it works fine until about 50%. If pushing more, motor is having erratic power dropouts and actually can slow down so much that it almost stops - its unusable.

SimonK tp_nfet.hex: Situation improved, but still a lot of drop outs (with strange sounds) and sometime even erratic behaviour.

I have modified tp_nfet.hex to 8Mhz as I have seen someone proposed this solution. I have set lfuse=0xa4 hfuse=0xdf.

Hello! Hmm, I do not have that motor or that board (and it is no longer available). I have not heard that sort of sound before. There definitely seems to be a problem with the sense feedback, or maybe with the signal input. You say this happens with all of the boards and motors, right? Does the logic side of the board look like this image? If not, please take and post a picture of it. Have you tried with a servo tester just to rule out input signal problems?

might sound stupid but i had a sim problem. ended up being a bad connector. the bullet was hanging on by a coulpe of strands and under load the motor would scream and die. Lovin the simonk software. i love it more than my kids (there teenagers)