How to use the BOD on 3217 via the Arduino

[coderatchance]

Trying to use the BOD, been reading a bit about it, however, I cannot get it to work, although it seems that it is programmed.

I guess that to set the BOD on any of the tinys that can be programmed with this core is rather the same?

Anyway, in this is case the programming is done via the Arduino, namely jtag2updi, indeed, it works without a problem, however, not programmed with the BOD. For example, the VLM is used on 4.2V, which is according to the 20MHz on the tiny, in practice, no matter, if the voltage level is reduced below the 4.2V, like 3V it does not make the reset as expected when the voltage is set on 5V, but the whole app blocks... and it stays in this way until the voltage is not totally removed, and given back so it resets ...
In this case the board without the Optiboot is used.

Have tried to "burn bootloader", indeed, it works, however, afterwards I cannot flash the chip with the board w/Optiboot. Not sure, if this is the right way to burn the BOD...

After reading the text on how to use the BOD ( [https://github.com//discussions/669] ), it seems this is not simple to understand :) anyway, I am not sure how to use a simple BOD on 4.2V and program via the jtag2updi, if it is even possible?

Thanks in advance and I am looking forward to any comments.

[coderatchance]

Hello all,

it looks that the setting of the BOD via the Arduino IDE pull down menu works yeah ! But "only" if the "boot-loader" or rather the burning fuses is used-programmed before the chip sketch is flashed via the jtag2updi..

Anyway, I am still not happy with how it works. For example, now I am looking at the "early warning" BOD interrupt to clear the peripheral, because some of it hangs in a state that is not desired. So the plan is to catch the early warning BOD interrupt and via the ISR clear the peripheral's state and then clear the interrupt flag. For example, I am not sure, if it cleans it self ...

If someone looks here the follwing vector can be used ? " BOD_VLM_vect "

ISR(BOD_VLM_vect) {
  //ISR code goes here
  //clear display is what is needed 
  display.clearDisplay();

  // remember to clear the interrupt flag that triggered it, if needed. In this case it is: ???

}

Tried only the above code, and it seems it hangs, because the current consumptions increases, in addition it stops working...

Anyway, I am not yet sure how to approach this, for example, I am looking at this example that can be found in the Ref_Interrupts.md.

// Check and clear flags at start of ISR.
ISR(PERIPHERAL_INT_vect) {
  byte flags=PERIPHERAL.INTFLAGS;
  PERIPHERAL.INTFLAGS=flags; // Very common approach
  if (flags & (1 << 0)) {
    doSomething();
    // Only risk with this is that if you disable the interrupt here, it may have happened again and set the INTFLAG again. In which case the interrupt would immediately run again.
  }
  if (flags & (1 << 1)) {
    doSomethingElse();
  }
}

So the following code was made for the second test:

//ISR
// Check and clear flags at start of ISR.
ISR(BOD_VLM_vect) {
  byte flags=BOD.INTFLAGS;
  BOD.INTFLAGS=flags; // Very common approach
  if (flags & (1 << 0)) {
    display.clearDisplay();
    // Only risk with this is that if you disable the interrupt here, it may have happened again and set the INTFLAG again. In which case the interrupt would immediately run again.
  }
  if (flags & (1 << 1)) {
    display.clearDisplay();
  }
} //end of ISR

It does not work. For example, when the voltage is decrease, the "early warning" interrupt should be captured and clear the display, but it does not... wondering what am I doing wrong?

Although this time the current does not increase, apparently, I am not clearing the flags correctly...
Anyone has an idea if I am using the " BOD.INTFLAGS " correctly at all?

Best.

[SpenceKonde]

Yes as explained in the documentation, "unsafe" fuses (BOD and the one that can disable UPDI), because they can brick the chip if set incorrectly, are not set upon upload, only upon "burn bootloader", which is an act users will hopefully think more before doing.

This is to prevent someone from, in the case of BOD, forgetting that they had the BOD voltage set to 4.3v from their 5V project, uploaded their code to their 3.3V project, which consisted of the ATtiny soldered to a circuit board along with some common maximum voltage = 3.6V parts. They have now bricked their board - they can't program it without applying >4.3v, but they must not apply more than 3.6V to avoid damaging the other parts on the board. The unfortunate user must isolate the Vdd rail of the ATTiny from the rest of the board or remove the other components in order to apply the >4.3v needed to take it out of reset and program the correct BOD level. Since the IDE stores settings globally instead of per-sketch, it is just too easy to click upload with the wrong settings. If I have two sketches open in two windows, changing the settings in one may or may not change it in the other window, depending on whether they are part of the same running IDE instance or not. (ie, open IDE, file-> open, file -> open, will result in the two windows sharing settings, but open ide, file -> open, then doubleclick a sketch in explorer will result in the two windows not sharing settings (and the next time the ide is opened, the settings selected will be of the last instance closed).

Similarly, we don't want to accidentally risk putting the chip in UPDI disabled mode, because HV UPDI programmers are scarce and uncommon in hobby circles.

This is consistent with the precedent set by every other core of which I am aware, official and third party; because classic AVRs had 3 fuses, any of which could usually brick the chip, they only set fuses on bootload. On mTC and DxC, For user convenience, we set the fuses that cannot render the chip difficult to reprogram on all uploads; particularly the clock speed one was a major pain point for users when we fully followed precedent and only set any fuses on bootload.

That all said, I think you're using intflags correctly (though I'd probably clear the intflag at the end of the interrupt - you clear it at the beginning if and only if an interrupt that occurs while servicing a previous interrupt is meaningful, here I don't think it is.

How is the rest of BOD peripheral set up? ie, what is VLMCTRLA and INTCTRL set to?

I'm guessing BOD.INTCTRL = 0x01 (enabled when voltage falls below threshold) and VLMCTRLA is set to either 0x00 (5%) or 0x01 (15%), since if running at 5v nominal with 4.2V BOD, you'll never be above the VLM threshold). That's what they should be for the system you describe at least.

For debugging I would set two unused pins output and connect them to LEDs (w/usual resistor and such) and have this have this in the loop that's getting interrupted:

digitalWriteFast(somepin, BOD.STATUS ? HIGH : LOW); //Turn on the LED if the voltage is below the threshold, turn it off if above threshold
digitalWriteFast(otherpin, BOD.INTFLAGS ? HIGH : LOW); //Turn on the other LED if the intflag is set. 

(in both of these cases the register has a single bit only)

You would then want to see the BODSTATUS LED turn on while voltage was below VLM threshold, but the other one to never light up (or if it ever did, only for the briefest instant).
This will confirm that the VLM is detecting the voltage droop, and that the intflag is being cleared in the interrupt. (I think it is - the fact that the initial ISR without clearing the flag and the second one with clearing the flag produce different behavior strongly supports this)

If you have a scope, and you're not sure if it's making it back to the main loop, you can have the scope monitoring a pin set output and every pass through loop, twiddle the bit:

digitalWriteFast(pin, CHANGE); 

Anyway, I suspect these tests will be consistent with correct behavior.

Once this is confirmed (I suspect that it will be successful), your question becomes why doesn't it do the thing it's supposed to?

And to that my question is uhm, what is display an instance of? what does "clearDisplay()" do to clear the display? is it something that makes sense to do and can be done within an interrupt context? Or is it something that requires interrupts enabled to do? Display control is often quite slow, as it has to reach out over SPI (or slower still I2C) and talk to the display. Also if there is any sort of code in that which depends on millis() incrementing or micros() modulo 1000 changing (the latter category includes delay() - but not delayMicroseconds() )

If it is found that you in fact can't clear the display within an ISR context, I would consider these approaches:

1. Do not enable the interrupt, but otherwise, configure VLM. You will need to have a variable to remember if the screen is on to avoid spamming clearDisplay when the voltage drops. When the display is on, in loop, test BOD.STATUS, if true, clear the display and set the variable so it knows the display is off.
2. Enable the interrupt, but don't try to have it . Have it set a global variable, clear the intflag and return. In loop, you test that variable, and if it's set, unset it and clearDisplay.

[coderatchance]

Thanks for all the ideas and other input! Indeed, some progress was made and new code was implemented, so far I guess it works:

BOD VLM setup

//my BOD VLM setup?! ******************** BOD VLM **********************************************
void bodvlm_init(void)
{
  // VLM threshold 15 % or 5 % or 25% above BOD level
  BOD.VLMCTRLA = BOD_VLMLVL_5ABOVE_gc;

  // Voltage level monitor interrupt enabled, interrupt when crossing / below threshold
  BOD.INTCTRL = BOD_VLMIE_bm | BOD_VLMCFG_BELOW_gc;

  // Clear VLM interrupt flag in case it got set when VLM was enabled
  BOD.INTFLAGS = BOD_VLMIF_bm;

  if (BOD.STATUS & BOD_VLMS_bm) {
    Serial.println(" BOD STATUS and BOD_VLMS_bm ");
  }
}
//end of my BOD VLM setup?! ******************** BOD VLM **********************************************

and the ISR

//ISR Turning on / off the display

ISR(BOD_VLM_vect) {
  if (BOD.INTFLAGS & (1 << 0)) {
      //BOD.INTFLAGS |= (1 << 0);
      display.ssd1306_command(SSD1306_DISPLAYOFF);
      Serial.println("ISR: Turning OFF display");   // ????
  }
    if (BOD.INTFLAGS & (1 << 1)) {
      //BOD.INTFLAGS |= (1 << 1);
      display.ssd1306_command(SSD1306_DISPLAYON);  // ????
      Serial.println("ISR: Turning ON display");
    }  
  // Clear interrupt flag
  BOD.INTFLAGS = BOD_VLMIF_bm; 
} //end of ISR

As it can be seen above, I am using the SSD1306 driver for the display and the simple "off" display command is used to turn off the display ... Did not get around the turn ON display... Either way, I have at least two reservations with this approach, how it is functioning.

So far the VLM is 5% above the BOD level, which is 4.2V. If I want this to be operational, the voltage has to drop to 4.2V to trig the BOD reset, otherwise the display is OFF ... indeed, the application, namely tiny is still "running" at 4.5V (without a load),
while the display is turned OFF,
the BOD reset is required to run the setup() and turn on the display again. I guess the fluctuation between the VLM and BOD trigger voltage is hardly going to be a problem in real world, however, wondering how to best set the hysteresis in such a case?

Best

PS : started to look at the BOD.STATUS but not sure how to tackle the whole interrupt thing due to my lack of functions' manual, I guess the best way to get around is to look at your library code as I have done so far .. :) Somehow I could not test the following (put the LEDs on pins PA3 and PA2 respectively) ...

//testing the BOD status and intterupt flags!
  digitalWriteFast(BLUE_led, BOD.STATUS ? HIGH : LOW); //Turn on the LED if the voltage is below the threshold, turn it off if above threshold
  digitalWriteFast(GREEN_led, BOD.INTFLAGS ? HIGH : LOW); //Turn on the other LED if the intflag is set.

otherwise this works:

//analogWrite(BLUE_led, 255);
//analogWrite(GREEN_led, 255);

[coderatchance]

It seems I cannot really find a good way to turn on/off the display via INT.
This seems ok, however, not sure how to get going...

If it is found that you in fact can't clear the display within an ISR context, I would consider these approaches:

Do not enable the interrupt, but otherwise, configure VLM. You will need to have a variable to remember if the screen is on to avoid spamming clearDisplay when the voltage drops. When the display is on, in loop, test BOD.STATUS, if true, clear the display and set the variable so it knows the display is off.
Enable the interrupt, but don't try to have it . Have it set a global variable, clear the intflag and return. In loop, you test that variable, and if it's set, unset it and clearDisplay.