Flip32 F4 problem

[addaedans]

Dear Werner Daehn! We have a Flip32 F4 board and i flashed it with the latest firmware. We could flash it successfully but the serial console was nat available. So i rolled back and the last date that the firmware worked was 13 August 2017. From 14th the led won't flash on the board and the serial console is unavailable. Could you please help to figure out what is the problem? The project is really cool by the way, we are almost done with ollecting and cutting the parts. Thanks, Peter Bittó

[wernerdaehn]

Hi Peter,

can you do me one favor: Please flash the board again, this time with the "verify after flash" checkbox ticked. I am pretty sure the firmware file is okay as somebody else used it already and it does happen once in 30 flash processes, that it was not correctly uploaded - the verify would tell.

Deal?

[addaedans]

HI! Thanks for the quick reply. Well i alwasy checked the veify after flash box and pressed manually the verify button as well. It always said success. The other thing that is strange is that with the firmware of 13th of august is working, however when i open the console it prints some information every second. I can bring up the help menu but it "goes away" slowly because of the non stop info coming on the screen. I will make a screen shot shortly about that.

[wernerdaehn]

That other firmware did write some debug information for a test. So it was not meant to be a "release" firmware. I can look at the firmware file next weekend - hope that is okay.

[addaedans]

Okay, thanks a lot.

[addaedans]

I talked with the guys and we would have to use it at the weekend, so we are quite in a hurry. We realized it is the same as the airbot f4. It seems that the program won't even start on the chip, but it flashes successfully. Could you give us some hint what could be wrong with it? We may try to fix it in the program. Thanks, Pete

[wernerdaehn]

At the right bottom, there it say "boot". That should be the "switch". Frankly I don't know why it does not start up. It says in the docs for the controller, that it is "compatible using the Revo target". So I assume the pinout is the same but that is no guarantee. The MCU is the correct one, else you would very likely not have been able to flash it in first place.

Btw, this is the controller I bought: https://www.getfpv.com/f4-advanced-flight-controller.html

And last comment: You understand that this cablecam controller is an option, not a mandatory component for operating the cablecam? It just acts as a filter between the RC receiver and the ESC to filter the user input in order to avoid hitting the endpoints, constant acceleration and the such. Just to make sure, since you are under a time pressure....

[addaedans]

Yeah we are in the same conclusion. It is the same thing but it still does not work...Yes we know that it works without it and we even tested it and works like a charm. But it will be on a pretty big event with quite a heavy camera + dji ronin system and the slow start and stop would be mandatory to avoid rope damage.

[wernerdaehn]

Makes sense. How do you suggest to proceed? I could order such controller myself and try to find the difference. Or....... any ideas?

[addaedans]

We just ordered another chip and hope it will arrive in time so we can test it as well. Maybe if you can modify the 13th of august firmware to print some basic information about the chip, it may show some evidence what goes wrong 1 day later. THan compare the 14th of august firmware with it and clean one half of the changes, than i test it. FOr the long run it would obviously be better if you buy one of this type of chip, but to start debugging this would be my idea, if it is possible.

[wernerdaehn]

I will be back at my computer next weekend, maybe Friday.

[addaedans]

OKay than we will try to figure it out than. Last thing(and i promise i leave you now with my problems :D) is could you help us how you develope the software? Do you need special hardware for compiling the program?

[wernerdaehn]

Sorry, overlooked the notification email to your last question. No, no hardware needed. I use EmBitz 1.11 aus Software development environment, compile the software into a hex file and then use the STM "Dfu File Manager" to convert the hex into a DFU file. That DFU file is then uploaded via the DfuSeDemo program from STM as described .

[wernerdaehn]

Okay, I have ordered a board. Looks nice, actually.

[wernerdaehn]

I have downloaded the dfu file from the bin/debug/ folder of this github page, uploaded it to my spare CC3D Revo board. Led is blinking, Console commands via USB are working. The file is identical in every byte to the dfu file I built on my computer on 26th Dec and the one I am using since then. So it is not the DFU file on the github page. ????

[addaedans]

SOmething between this one: https://github.com/wernerdaehn/CC3D-CableCam-Controller/tree/11146ff0d66414371e4624e285eb1fa255f23c92/bin/Debug

and this one:

https://github.com/wernerdaehn/CC3D-CableCam-Controller/tree/2633849a84b734728579d92d52165ffb0bd3318c/bin/Debug

has changed(i see a lot of update info) in one day. So the problem lies in some changes between these two files.

[wernerdaehn]

Why are you using 6 months old files and not the one from December? https://github.com/wernerdaehn/CC3D-CableCam-Controller/tree/master/bin/Debug

A lot of things have changed since then.

[addaedans]

Because the 13th of August one is the latest that works with my chip. After that none of the firmwares are working.

[wernerdaehn]

Understood. But that does not work either. Okay, you might get a firmware version that is running just not working properly as we enhanced the software a lot. The 14Aug was the first with RC input etc.

I have no idea why the firmware does not boot. No EEPROM chip?

[addaedans]

We have this type of eeprom on the chip:

https://www.pjrc.com/teensy/W25Q128FV.pdf

It has some differences so it can be a problem.

[wernerdaehn]

Likely, because I read the Flash Identifier and expect the same always. https://github.com/wernerdaehn/CC3D-CableCam-Controller/blob/master/src/eeprom.c

And in the main I enter the error mode if it is not the correct one. if (eeprom_init() != 0) { / EEPROM is a wrong chip / Error_Handler(); }

[wernerdaehn]

Can you try out the version I just uploaded? I have changed the eeprom_init() to return success for all EEPROMs.

[addaedans]

Thanks, i uploaded it and it seems to work. I reached the terminal as well, so try out the tutorial you wrote and write what happened. Thanks :)

[addaedans]

Oka i wrote some settings into the eeprom and it seems to work fine. We are at the final stage, and we have another question with the Hall sensors. Are the two sensors on the wheel take the signal simultaniously or in turns?

[wernerdaehn]

Not sure I got your question. But the principle of a quadruple encoder is that the two Hall sensors both measure one magnet and the question is - which one got it first. So in a trivial world you would have two Hall sensors and a single magnet on the wheel and this way you can count the speed and the direction. By adding more magnets the wheel appears to be turning faster to the Hall sensor. This works as long as the magnets are not so tightly packed that the sensors measure the same signal but from different magnet. And to play it safe, you use Hall senors that fire on North pole only and add the magnets north/south alternating to make sure the magnetic field strength falls below the sensor threshold - which it does for sure at the south magnet. Answered?

[addaedans]

So here is the HalSensor picture. My question is, that the blue line is the distance of the two hall sensors. The red line is the distance of 3 magnets(the distance of 2 magnets is too short for sure). So are the 1st and 3rd magnet on the red line fall below the two hall sensors or only one of the hall sensors sense the magnet at a given time. In programming language, if blue == red: print("Two sensors working at the same time") else: print("Only one sensor is working at a time")

:D

[wernerdaehn]

You have it correct. The distance between the two hall sensors is e.g. 13mm and the distance between 1st and 3rd magnet is 16mm. This works, because still one of the Hall sensors will pick up the signal of the north pole slightly before the other does. And with this time-gap the encoder can find out the direction. Only once both distances would be equal, both sensors fire at the same time and the direction information is lost.

[addaedans]

Perfect! Thanks a lot for the help. We are going to make a short footage made with the cablecam, i will send it for you if interested. Thanks again :)

[wernerdaehn]

Absolutely! Looking forward to it.