Navitop Controller - bad_fuses

[Embla]

I finally got my system up and running on a test bench.  Running RPI5; MacArthur Hat -> Navitop Controller on UART4, but I see a message "Sync"; "Engaged"; "Bad_Fuses"; "Drive".  I checked an old 2018 post and it seems to have been related to code on the arduino.

I also see this note in the original pypilot manual:" BAD_FUSES - the motor controller fuses are not programmed correctly ".  

I had assumed that the Navitop would have the correct code installed?  

Do I need to worry about this or what can I do to remedy it?  What are the risks of running with "bad_fuses".  

Thank you for your support and assistance.

[seandepagnier]

This is because without the right fuses set the brownout detector data corruption can occur (I have managed to cause it in under a minute reliably by tapping power wires repeatedly to power source) but it never occurs with the brownout detector set correctly.

If you flip the power on and off cleanly it probably wont happen easily, but in any case it is potentially a serious issue and this is the reason why this BAD_FUSES warning is displayed.

[Embla]

This is because without the right fuses set the brownout detector data corruption can occur (I have managed to cause it in under a minute reliably by tapping power wires repeatedly to power source) but it never occurs with the brownout detector set correctly.
If you flip the power on and off cleanly it probably wont happen easily, but in any case it is potentially a serious issue and this is the reason why this BAD_FUSES warning is displayed.

Sean, Thank you for taking time to reply.  I'm still confused!

Are you saying that the bad_fuse error can occur by an intermittant flakey power supply to the Navitop controller?  I thought that bad_fuses are due to incorrect fuse settings in the controller's arduino code. (as specific in your user manual Section 5  Appendix  A)  

My test bench power supply is a 12v motorcycle AGM battery with trickle charger.  It's powering both rpi (through onboard Pololu regulator on MacArthur hat, with safe power down management) and directly to the Navitop Controller.  I don't see any evidence of poor connections.

How can I fix the bad_fuse or should I return the Navitop Controller to OpenMarine store to be exchanged?  Many thanks, Paul

[Jean-Marc Douroux]

I've done a lot of testing with controllers that work perfectly without paying attention to this message that another user reported to me in the last few days.

I'll explain why there's actually no error.

Sean explained above that the processor reset voltage should be set to 4.3V with the first three bits of the efuse byte set to 100. This is important in cases of very low supply voltage to protect the power stage's security.

But this efuse byte contains 8 bits, even though only the first 3 are used for processor configuration. Programming these parameter bytes is unusual because the bits are set to 1 by default and are only written when they need to change from 1 to 0.

The problem is that there are two ways to set the first 3 bits to 100 for an identical 4.3V setting:

• With the Arduino IDE, which configures this byte to 0xFC, or 11111100
  
• or as Sean does with avrdude and 0x4 (100), or 00000100
  

This is why this error isn't an error because, while the efuse bytes are different, the 3 low bits are identical. Pypilot's operation and protections are not affected in any way. 

I don't think it's possible with the Arduino IDE to change this efuse byte to 00000100 (0x4) because the IDE only offers to choose the reset voltage to configure the efuse byte.

If pypilot isn't modified to check only the first 3 bits, to avoid this false message, you need to rewrite this efuse byte with the hexadecimal value 100 (0x4). 
It's not certain that there is a simpler solution than using avrdude.

Note: To prevent the 5V voltage from dropping, I modified the 5V converter and added a polyfuse so that a short circuit on the 5V supply to the limit switches and the rudder angle sensor does not disrupt the power supply to the Atmega328P, which has been tested.

[seandepagnier]

no, bad fuse message is not caused by an intermittent supply, it indicates that an intermittent supply could potentially corrupt the motor controller requiring it to be reflashed possibly through the ISP port (or maybe the bootloader)

I do configure the byte as 0xfd not 0xfc, but the software should allow either 100 or 101, either setting should be acceptable, since it ands with 110 mask checking for 100. See motor.ino line 365.

Now, it is maybe not an issue too, I cannot tell without more information, I am still not clear what the setting actually is but it should be one of these two, or maybe one of the other fuses (high or low) is different too, and without checking the fuse settings I dont know if the fuses are right or not, there are potentially other allowed values but I never considered using them as I set the fuses when programming the devices to known working ones.

A short circuit was never a problem because of a limiting device the lm317 on my controllers, a polyfuse would also work there, but this will not prevent the issue of memory corruption if the power supplying the controller was constantly all over the place, which is a real concern because as i mentioned it can fairly easily corrupt the flash making it not work.

[Jean-Marc Douroux]

I agree with you on everything. The efuse is not the problem.

A closer look with avrdude reveals that the problem comes from the lowfuse (lfuse), which the Arduino IDE sets to 0xF7 for "external crystal 8MHz," and the highfuse (hfuse), which the IDE sometimes sets to 0xDF. The difference is that bit 3 of the lfuse (CKSEL3) is set to 0 by the IDE instead of 1 with your 0x7F code, and bit 2 of the hfuse (BOOTSZ1) is set to 1 instead of 0 with your 0xDA code.

To analyze the fuses and modify them, I used avrduddess (Windows) with an Arduino programmer as ISP. It's simple, and there's no need to re-download motor.ino after correcting the fuses.

L : 0x7F
H : 0xDA
R : 0xFC
LB : 0xFF (unchanged)

Before writing the fuses, you need to specify the programmer used (Arduino as ISP for me) and the MCU, i.e., ATmega328P.
After entering the correct fuse values, as shown in the attached image, click on the highlighted Write button.

[Embla]

Thank you both for digging into this issue and proposing a resolution.

Jean-Marc - I have never programmed a non dev microcontroller before, nor have I used ISP connections, so I would be grateful for some assistance. I've installed the AVRDUDESS - same version as in your image and set the fuses as per the values in your image.
I've read that this can be a critical process and mistakes can "brick" the chip!! So, can you clarify for me:
1) Do I select the Set Fuses checkbox in AVRDUDESS? (not checked in your image)
2) Do I power the Navitop with 12v dc in the main power at the WAGO power in terminal
3) What are the pinout connections to the ISP pins on the Navitop - what way are the pins identified?
4) Do I need a 10 µF capacitor between RESET and GND on the Arduino (negative to GND). I've read that this disables auto-reset and makes ISP programming more stable.
5) Do I need to attach a crystal to the wiring?
6) Anything elese I need to know before writing the updates?

Many thanks!

Paul

[seandepagnier]

So the difference is full swing vs low power crystal and either should work fine.

The other difference is bootloader I am assuming the navitop controller has no bootloader then?

It is probably true the bad fuses warning can be ignored, there is no reason to reprogram, but I suggest in the future modify motor.ino to support the allowed fuse settings, or program the fuses correctly.

Mostly the warning was in place for people programming their own arduinos to give a clue as certain fuse settings really are important.

[Jean-Marc Douroux]

Don't rush to avoid making a mistake. I have a regatta today. I'll post the link to a tutorial by tomorrow evening.
It will be easy to do. There's no need to power the controller with 12V.

Using an Arduino Nano as an ISP programmer is simple and effective. You do need a 10uF capacitor.

Otherwise, be careful not to use a 3.3V-only programmer. You can find some that operate at 3.3V or 5V with a jumper. But the Arduino Nano has the advantage of working very well with AVRDUDESS without any drivers.

[Jean-Marc Douroux]

For those who absolutely want to remove the "Bad_Fuses" message which can be ignored, I have made a tutorial accessible with the link below

https://navitop.fr/about-bad-fuses-message