Search the Community
Showing results for tags 'bug report'.
Found 3 results
bug report ADC is giving incorrect warning that pin is outputI am trying to do a simple test to measure the output of the DAC using the ADC. The datasheet for the DAC states very clearly that if you have enabled the DAC output pin this will override any pin output functions including the digital output (TRIS) the weak pull-ups and the digital input threshold circuit (so ANSEL behaves like it is set to 1): But MCC is generating a warning saying that my setup is incorrect. Since the output settings are overriden when the pin is a DAC output this warning should not be created when the pin is a DAC output which makes it behave as needed. Besides there should not be any problem measuring an output pin using the ADC when it is an output anyway? I do not understand why the warning is claiming that it "requires" this pin to be set as input. Perhaps it would be better if the warning said "this pin is being driven by the device, if you are trying to measure an external voltage this will interfere with your readings, you can avoid this by disabling the pin output drivers by making the pin an input" or something to that extent? Required Boilerplate: Component Version Device PIC18F74K40 MCC 3.75 MPLAB-X 5.10 Foundation Services 0.1.31 PIC18 Lib 1.76.0
bug report Using MCC to configure DAC on 47K40I am trying to configure the DAC on the 47K40 Xpress Evaluation board using MCC and I am confused about what I see. The screen I see is to the right -> I can understand that the Vref+ and Vref- fields are necessary when you are using the input pins for a reference but it is really confusing when the Vref+ is shown and it is read-only AND it shows an incorrect value as it does here. I would have expected that if I select Vdd as the reference the Vref+ value would either be hidden, or that it would have the same value as Vdd. I also do not understand why the Output of the DAC is referred to as "Required ref", this talk of "Ref" all over the place is very confusing to the unsuspecting user. You should call the DAC out Value the Required DAC out Value above the line you show the result of the calculation, and when the references are set to Vdd or Vss then Vdd should match Vref+ and Vref- should be 0 even if those are read-only - even better just hide them if they should not be used! It turns out that Vref+ and Vref- are ignored if you have selected Vdd and Vss, and that Required Ref actually means the output that you desire to get from the DAC, for those as confused as I was. When you select the Vref+ pin as the reference then Vdd field is ignored. It also seems that the Vdd and Vref+ fields allow you to enter values way outside the electrical specs of the device, it does create a note that this is the case, but I would have expected a proper warning for something dangerous like this, at first I did not even notice this as it was green and just a note. Lastly when I select to use the FVR _buf2 as the positive reference for the DAC the screen no longer makes any sense. Now I can only edit Vdd (which is 5v) but my Vref is set to 2.048V via the 2x buffer on the FVR, but the Vref+ field is read-only so I cannot update it. MCC is however using the correct input reference of 2.048 as can be seen by the output being limited to 1.984V even when I require 3V. Required Boilerplate: Component Version Device PIC18F74K40 MCC 3.75 MPLAB-X 5.10 Foundation Services 0.1.31 PIC18 Lib 1.76.0
bug report RTCOUNTER example - (solved) Caused by Silicon ErrataHello, I have run into a strange (for me) issue with the rtcounter module as provided by MCC and shown by the example program in the blog area of this site. I am using MPLabX and XC8, both up-to-date versions and I am trying the example on a pic18F47k40 xpress board. The issue is I set an output (RA4) in main after initializing the pic and then enter the while(1) loop where the rtcount_callNextCallback(); is called. The output now is turning on and off. The off duration is typically ~60u seconds, and on time can be varied with changes to the timer interrupt settings (I use a 1mS timer0 in 16 bit mode) and the number sent to the callback. Approximately every 3mS, the off time increases such that that cycle (only) is approx 50% duty cycle. Turning the output on or off in the callback routine has no effect - I initially wanted to toggle on and off at a speed visible to the eye. Commenting out the callback in the main loop stops the output from going low. I have checked errata and used the data sheet to confirm register settings, I tried moving the current-limited LED from RA4 to RA2, and I have studied the example program looking for obvious differences that may cause this behaviour. I would appreciate thoughts and/or suggestions. Keith