Duly noted.!!

 

It seems that the FVR's gain must be set prior to activating it, and once set, it cannot be changed unless it's deactivated and then set up again ... I hate this sort of quirks ... took a few hours of my life. I hope this post helps to save hours of other people in the future.

You can see this in many different MCU cores and peripherials. To be sure the peripherial module activates as intended i use mostly this pattern: deactivate module -> setup module -> activate module. As i get older i forgot it sometimes and then frequently some anomalies can happen

 

Just thought I'd document this here.

When setting up the Fixed Voltage Reference (FVR) of the PIC16LF15323 the following code DOES NOT work:

   banksel FVRCON       ;bank 18
   bsf FVRCON, FVREN    ;enable internal Fixed Voltage Reference
   bcf FVRCON, ADFVR1
   bsf FVRCON, ADFVR0   ;these two bits define ADC FVR Buffer Gain as 1x, (1.024V)

This is the code that works:

   banksel FVRCON       ;bank 18
   bcf FVRCON, ADFVR1
   bsf FVRCON, ADFVR0   ;these two bits define ADC FVR Buffer Gain as 1x, (1.024V)
   bsf FVRCON, FVREN    ;enable internal Fixed Voltage Reference

It seems that the FVR's gain must be set prior to activating it, and once set, it cannot be changed unless it's deactivated and then set up again ... I hate this sort of quirks ... took a few hours of my life. I hope this post helps to save hours of other people in the future.

Not a quirk, it's a code safety feature for most modules.

 

Not a quirk, it's a code safety feature for most modules.

Interesting. How is it supposed to make things safer? ... also, nowhere in the datasheet does it mention that one can't change the FVR on the fly

 

Interesting. How is it supposed to make things safer? ... also, nowhere in the datasheet does it mention that one can't change the FVR on the fly

It makes random memory corruption write errors less likely to reconfigure critical hardware because there is a sequence needed for modifications. Some devices have locks that allow for one config per boot, others require a specific unlock sequence using 'magic' numbers.

https://onlinedocs.microchip.com/ox...UID-5B2102CA-3255-43DC-B4BA-610CE1880E7D.html

 

It makes random memory corruption write errors less likely to reconfigure critical hardware because there is a sequence needed for modifications. Some devices have locks that allow for one config per boot, others require a specific unlock sequence using 'magic' numbers.

https://onlinedocs.microchip.com/ox...UID-5B2102CA-3255-43DC-B4BA-610CE1880E7D.html

Wow ... that's what I call a significant contribution. Many thanks!