| View previous topic :: View next topic | 
	
	
		| Author | Message | 
	
		| dluu13 
 
 
 Joined: 28 Sep 2018
 Posts: 395
 Location: Toronto, ON
 
 
			      
 
 | 
			
				| PCD 5.103 ADC VREF bug |  
				|  Posted: Fri Apr 16, 2021 8:26 pm |   |  
				| 
 |  
				| I've already solved the issue myself a couple of weeks ago, but I figured I might post this here in case somebody else has a similar problem.
 
 I'm using PCD 5.103 with PIC24FJ256GL408. I'm not too surprised, since
 it's a new compiler with a new PIC (released in 2019, if I recall correctly).
 
 Basically, if I set up ADC like this, the compiler does not correctly set the
 positive ADC reference to VREF:
 
  	  | Code: |  	  | setup_adc(ADC_CLOCK_DIV_256); setup_adc_ports(AN_DVOLT | AN_CVOLT | AN_WIP_VOLT_SNS |
 AN_WIP_CURR_SNS | AN_RPUMPCURR | AN_DPUMPCURR,
 VSS_VREF);
 
 | 
 
 Instead, I get around it by setting the bits manually:
 
  	  | Code: |  	  | #bit PVCFG0 = getenv("BIT:PVCFG0") #bit PVCFG1 = getenv("BIT:PVCFG1")
 #bit NVCFG0 = getenv("BIT:NVCFG0")
 
 setup_adc(ADC_CLOCK_DIV_256);
 setup_adc_ports(AN_DVOLT | AN_CVOLT | AN_WIP_VOLT_SNS |
 AN_WIP_CURR_SNS | AN_RPUMPCURR | AN_DPUMPCURR);
 
 PVCFG0 = 1;
 PVCFG1 = 0;
 NVCFG0 = 1;
 
 | 
 
 I emailed this to CCS support a couple of weeks ago but they never
 replied, which is unusual. Hopefully they are working on a fix...
 |  | 
	
		|  | 
	
		| Ttelmah 
 
 
 Joined: 11 Mar 2010
 Posts: 19966
 
 
 
			    
 
 | 
			
				|  |  
				|  Posted: Sat Apr 17, 2021 12:48 am |   |  
				| 
 |  
				| It's just an error with the defines in the .h file. If you look:
 
  	  | Code: |  	  | // Optional Second argument:
 #define VSS_VDD            0x0000 // Range 0-Vdd
 #define VREF_VREF          0x6000 // Range VrefL-VrefH
 #define VREF_VDD           0x4000 // Range VrefL-Vdd
 #define VSS_VREF           0x2000 // Range 0-VrefH
 
 | 
 
 These are the values to be put into the AD1CON2 register. VSS_VREF
 actually needs to be 0x4000. According to the data sheet the NVCFG0
 bit, doesn't actually work (the data sheet says the value used is the same
 whether it is 1 or 0...). The chip doesn't actually show a Vref- pin (only
 CVref-).
 So the values actually useable are:
 
  	  | Code: |  	  | // Optional Second argument:
 #define VSS_VDD            0x0000 // Range 0-Vdd
 #define VSS_VREF           0x4000 // Range 0-VrefH
 
 | 
 
 Substitute these and you should find it'll work. I just tried compiling with
 this done, and it merrily puts the right value into the register.
 It looks as if they must have 'meant' to have a Vref- pin, so included the
 bit in the register, and then not actually implemented it!...
 When CCS were setting it up, because of this oddity they miscounted the
 bit number.
 |  | 
	
		|  | 
	
		| dluu13 
 
 
 Joined: 28 Sep 2018
 Posts: 395
 Location: Toronto, ON
 
 
			      
 
 | 
			
				|  |  
				|  Posted: Sat Apr 17, 2021 6:33 am |   |  
				| 
 |  
				| Thanks! 
 Though I'll just put a comment in my code about that. I don't want to be putting "magic numbers" in the code, nor do I want to be modifying their header files.
 
 There are actually a ton of neat features on this chip that aren't really supported in CCS right now and I'd have to do it manually.
 For example this chip can be configured to have a dual partition on its program memory, and you can select which partition to "boot" from.
 
 Maybe one day I'll have some time to try that out.
 |  | 
	
		|  | 
	
		| Ttelmah 
 
 
 Joined: 11 Mar 2010
 Posts: 19966
 
 
 
			    
 
 | 
			
				|  |  
				|  Posted: Sun Apr 18, 2021 9:54 am |   |  
				| 
 |  
				| Just make your own 0x4000 define with your own name. Make a remark on 'why'. The dual partition boot exists on quite a few chips and is
 supported quite well.
 |  | 
	
		|  | 
	
		| dluu13 
 
 
 Joined: 28 Sep 2018
 Posts: 395
 Location: Toronto, ON
 
 
			      
 
 | 
			
				|  |  
				|  Posted: Sun Apr 18, 2021 10:03 am |   |  
				| 
 |  
				| That's a good idea... I'll do that instead. 
 Re: dual partition boot, do you have any hints on where to start exploring first? I didn't see any particular fuses for that. Either that or I missed them entirely.
 |  | 
	
		|  | 
	
		| Ttelmah 
 
 
 Joined: 11 Mar 2010
 Posts: 19966
 
 
 
			    
 
 | 
			
				|  |  
				|  Posted: Mon Apr 19, 2021 1:45 am |   |  
				| 
 |  
				| Have you looked at the dual partition bootloader example?. 
 ex_bootloader_dp.c (and the include files this loads).
 |  | 
	
		|  | 
	
		| dluu13 
 
 
 Joined: 28 Sep 2018
 Posts: 395
 Location: Toronto, ON
 
 
			      
 
 | 
			
				|  |  
				|  Posted: Mon Apr 19, 2021 6:49 am |   |  
				| 
 |  
				| Hmm, it looks it just loads it into the first partition and the bootloader will manually stick the application into the second partition. 
 I guess if you want to get back into the bootloader you have to write something in your application that runs the bootswp instruction?
 
 Is there even a way to choose which partition you flash into when you're using ICSP?
 
 I also noticed that the help file provided with the compiler is not up to date, as it differs from the PDF version found on the CCS website...
 |  | 
	
		|  | 
	
		|  |