Unexplained start failure: Here3 on CAN

Here GPS
#1

On two of five tested Cubes with their respective carrier boards, Here3 stops working after the initial blue blinking series.
All tested with current, default parameters + 1Mbit, CAN, Plane/Copter
reducing CAN speed to 100k does not affect the issue.

NOT OK : (blinking blue, then LED’s go off, no CAN devices - if replugged, works fine)
/dev/serial/by-id/usb-Hex_ProfiCNC_CubeBlack_240028000C51363130363134-if00
/dev/serial/by-id/usb-Hex_ProfiCNC_CubeBlack_2C0043000551363037363632-if00

OK (just works)
/dev/serial/by-id/usb-Hex_ProfiCNC_CubeBlack_3D0046000851353430373938-if00
/dev/serial/by-id/usb-Hex_ProfiCNC_CubeBlack_35002B000D51363130363134-if00
/dev/serial/by-id/usb-Hex_ProfiCNC_CubeBlack_230026000D51363130363134-if00

The issue is not affected by using USB power(good cable) or a power module.

Odd things that make it work on “NOT OK” cubes:
1: BRD_BOOT_DELAY 700ms - 500 is too little, at 700ms it works just fine.
2: reconnecting the Here3 CAN cable after boot.
3: I added a CAN analyzer interface to troubleshoot (no extra termination enabled) - just the presence of the CAN<>USB device makes it boot fine every time.
4: Powering the Here3 from a separate +5v

Right now you say “so this is brownout related”
So did I think too, checked voltage drop using oscilloscope but failed to find a real reason for the internal 3v3 components to brownout.

So I rigged a lab PSU to cause brownouts (to the Here3 only), I thought I could reveal poor or missing BOR design, but guess what - regardless of the type of brownout I caused, Here3 always recovered fully, and then got detected by the Cube/ardupilot.

So it remains a mystery why it fails to initialize properly on some boards, and that there are som many ways to work-around the issue.

#2

using the info you have provided make me thing its just to do with bring up time, and things like the cube bring up gyro calibration time etc.

ie you have established that changing the boot delay makes it work ok every time, so the gyro calib time may be longer on those units, and or they where at different temperatures etc.

the blue strobing normally indicates there is no firmware on the unit. you could try your external CAN<>USB adapter but make sure the node allocator is turned off.

#3

You could try BRD_BOOT_DELAY,5000 (5 seconds)

#4

We were having Here 3 boot issues as well. The px4 community suggested we re-compile the firmware and moving one line of code above another. More specifically:

“We connected a Here 3 to a cube orange. A colleague reported that the connection only worked if he connected the here3 after booting. The temporary solution for us was in file “ROMFS/px4fmu_common/init.d/rcS”, to move section “Check if UAVCAN is enabled, default to it for ESCs.” up, before “RC Update”. We don’t fully understand why that fixes our connection problems though”

#5

which firmware are you using? on the here3? and on the cube Orange?

#6

Adding long delays 5s delays is not a good “solution” or workaround, it is likely to effectively destroy the ability to recover from a mid-air-reboot.

#7

Did you see my question? What firmware on the cube and on the here3?

#8

@Here3PX4 I think @philip is asking you. (I don’t have a single orange cube)
(My Here3 had/have the stock firmware there were delivered with, and all five cubes were tested with current ArduCopter/ArduPlane releases of the date - factory defaults + necessary CAN changes only) that is, after the issue has been discovered on 2-3 release old ArduPlane.

#9

Please update to the latest firmware on both the cube black and the Here3

You mentioned PX4? But you said you were on Ardupilot… so that bit is confusing