I wouldn’t have an issue with this if there was clear path to fixing it or clearly a way to download the px4io-v3.bin (assuming this is what is needed for the fix as it was on the original pixhawk where you would fix it with px4io-v2.bin).
After hours of googling I can not find anything. Since it is named a Pixhawk 2.1, all the pixhacks calling themselves 2.1’s come up. Cube is no help either. The firmware section of AP is vast and I see no IO bin files matching the v3 device. Does it even take a BIN on the SD? Is it another file. I wish the PH2.1 had a different name like the Profi-Hex Controller or something unique since it would make googling much simpler.
I would love to get rid of the red ring of death if only I could find what file to put on the SD card and boot with the reset button pushed. Mission Planner’s “force boot loader” option doesn’t appear to help.
Any suggestions would be greatly appreciated.
A brief rant - Sorry - I have to:
I want to note that I often get slammed for the way I word things but I just can’t help it. The PH2.1 is NOT a reliable unit but it is necessary for small builders like me who compete against DJI and others in regards to features. I have tried to love the PH2.1 and have written many a post about it. Here we are and Yet another NEW PH2.1 and out of the box a boot loader issue. Why? Why are so many units dysfunctional out of the box? My 1 in 4 bad units I posted about last year still stands and I am well over 100 purchases so far so the evidence is far from anecdotal. Support is difficult or nonexistent depending on the source of the units so we are often on our own with a unit that has a 75% reliability. I bring this up not to offend but to hope someone in dev listens because there are issues and they are significant - at 230.00 USD per unit, having vendor that will not honor returns and support being left to hoping someone answers on a forum eventually is a difficult pill to swallow. When one spends 200 bucks on something it should work when plugged in 99.9% of the time; not 75.
I genuinely appreciate everyone on the forums by the way. Without them this product would be far less useful.
The io firmware is cargo in the main firmware. If it isn’t updating automatically, hold down the safety switch as you power on the Cube. This will force an IO fw update.
Re problems with suppliers, perhaps get in touch with @proficnc
James. Thank you SO much. I have tried this and it refuses to do any further than the red ring flashing. Left it for an hour and no difference. bad unit? I SO hope not. This is for a customer who needs it ASAP.
I agree on the supplier thing. I have indicted many missives to Profi, suppliers and even resorted to buying from Amazon since they can compel a return but this is more time consuming.
Something in the stack is failing to start. Old PH1’s could be fixed by getting the px4io-v2.bin, placing it on the SD card and booting with the safety switch. This is not the case thus far with the PH2.1 - the boot loader is failing to initialize the IO indicating the boot loader is somehow corrupt.
I have tried downgrading, upgrading, using Mission Planner, APM Planner and NOTHIG works. Tones out at boot indicating the error. This is not a setup issue. I need to find a way to force the boot loader via SD card and this is NOT easy to find the file to do so as it is probably buried in the px4 file itself (since beta versions show “with BL”.
I believe the button trick only works when there is the proper file on the SD card.
I build about 15 UAV’s a month - most for mission critical applications. I am leaning toward this being one of the 25% bad out of box units I get but since I can interact with it I am hoping there is some force fix to get it running. My project is due sooner than I could receive another unit.
Ok.
Some incorrect assumptions and assertions there, but anyway.
What firmware are you trying to load?
Have you disassembled/reassembled the Cube in any way?
Can you connect to Console and copy the boot messages?
I have tried the current which is 3.5.7 Quad, tried the 3.6??? beta, 3.4 and tried going to like rover than plane and back. Each fails on the IO.
No disassembly at all. We have a coated PCB made for us that has all the distribution built-in - think Matice 100 style board. The PH2.1 and carrier board screws directly to it. There is ZERO chance of error. All the connectors can only go one way and no power is applied until assembled. We have the assembly thing down. We CNC our own frames from CF sheets, place the custom distribution board, place the jumpers, put the top on, and copy the configs. We even have a GPS jig so everything is EXACTLY the same from one to the other with the exception of options like FLIR, zoom cameras and so on.
It happens with either power source. I am sure it is NuttX as I don’t believe ChibiOS is currently available as a stable release in copter at the moment.
When trying to install ChibiOS on the beta it failed by the way.
Very confused about this issue. Wish I could find px4io-v2.bin (after some research I believe v3 is wrapped in V2 now since both show V9 board info) for 3.5.7 so I could try the force method. I don’t have time to setup an environment to build the sources just to get the file…
The io binary is built into the main firmware. You don’t need a separate file, and because it’s crc checked if you try that it will fail unless the fmu and io fw versions match.
Try removing the sd card and opening an nsh shell, then force the update “px4io forceupdate” (you might need to check that command).
Tried QGroundControl on Linux, even in a VM? Others have mentioned they’ve been able to resurrect units with that where Mission Planner has not worked.
I found the issue. I finally decided to break it down and look under a microscope. After over 2 hours I discovered there is a microscopic pit in the STM32F100C8T6B chip This is the chip that handles the I/O. It is microscopic but a defect nonetheless. SO this was a physical issue. Again this was new out of the box, powered properly and had the issue from the moment we put it on the bench. Factory defect? Appears so.
I ordered a couple from SMT. I may see what happens if I reflow one on.
@cda725, are you on the Cube support page? On Facebook? Most people do not struggle to get in contact with me! Any issue that appears to be a DOA unit will be honoured for an RMA, if this is not your experience, feel free to contact me directly and cc me on your corespondence with your distributor.
Regarding the issues you are having. Each unit goes through a full motion test jig to verify each and every sensor and physically verify all the IO channels.
Only after this has passed, can the system allow the cube to the next stage in production. Failed units get disassembled for QC analysis.
It appears that your unit has had a significant high voltage event into the IO. This could be from Static electricity, or from a high voltage getting into a PWM line or similar.
Unfortunately by pulling it to bits, you reduce our ability to do an investigation on the unit if we were to RMA it. That’s the point of an RMA, to give you a good experience, by allowing us to find our where in the process this could have happened.
So please actually contact us next time you have an issue. I’m sorry that you appear to have had a few.
Thank you for your response. I have indeed had issues and it is good to have a direct contact. We have a pretty standard setup regarding our build station and have discharge paths for static. This issue has appeared before plugging anything in other than the supplied power module so I am not sure where HV could possibly be introduced.
I will investigate the static issue further. I recall a friend in the PC business stating that one of his employees had issues where RAM would constantly go bad on him. He always used a static strap. It appears, although correlation is not causation, that his shoes may have been the culprit. The point is that just because we have precautions against static does not mean they are through enough.
EDIT: The reflow was a success. I will not use it on a customer model but after replacement I flew with it in our test rig. Whatever caused the initial issue did not reappear after replacing the chip.
I have same issue with my pixhawk v1, getting the error messege “Check BRD_TYPE px4io failed to start”.
Tried to turning on by pressing & holding the arming switch, but NO Result.
Tried different firmwares (new + old), different Softwares (Mission Planner, QGC, APM Planner2), No result.
