| 
	
	|  |  |  
	
		| View previous topic :: View next topic |  
		| Author | Message |  
		| E_Blue 
 
 
 Joined: 13 Apr 2011
 Posts: 417
 
 
 
			    
 
 | 
			
				| Does #ORG it's only 16bit wide? |  
				|  Posted: Wed Jan 06, 2021 9:19 pm |   |  
				| 
 |  
				| Hello, I'm trying to add an offset to my current program to make space to the bootloader but the #org refuse it to locate space beyond 0xFFFF even when the chip have 128Kbytes; so I don't understand why it refuses to locate the whole memory In the CCSC Help it says:
 
  	  | Quote: |  	  | start - is the first ROM location (word address) to use. | 
 
 So I think that is why it compile when I use
 
 
  	  | Code: |  	  | #org 0x1000,0xFFFF DEFAULT | 
 
 And not when I use
 
 
  	  | Code: |  	  | #org 0x1000,0x1FFF0 DEFAULT | 
 
 If that the case, Is not possible to make a program beyond 0xFFFF?
 
 I performed those test with a smaller program not the current one
 
 The current code is pretty big, it uses about 45Kwords(90KBytes) after being compile it. That's why I need all the remaining space.
 
 The chip is a PIC18F67J50 and CCS compiler is 5.091
 _________________
 Electric Blue
 |  |  
		|  |  
		| Ttelmah 
 
 
 Joined: 11 Mar 2010
 Posts: 19966
 
 
 
			    
 
 | 
			
				|  |  
				|  Posted: Thu Jan 07, 2021 1:06 am |   |  
				| 
 |  
				| A single #ORG only support a 64KB max address range. However you can use a double #ORG to put something beyond this. So you have to use
 up the first segment and then load into the second:
 
  	  | Code: |  	  | #org 0x00008, 0x0FFFF {}
 #org 0x10000, 0x13FFF {}
 #org 0x14000, 0x14FFF
 //Now puts following code at ox14000
 
 | 
 
 Not intuitive at all!...
 |  |  
		|  |  
		| E_Blue 
 
 
 Joined: 13 Apr 2011
 Posts: 417
 
 
 
			    
 
 | 
			
				|  |  
				|  Posted: Thu Jan 07, 2021 1:39 am |   |  
				| 
 |  
				| I was thinking to reserve the first 8K to the bootloader an the rest to the main program. The main program needs more than 64K so I need that the main program starts at 0x04000 and it will cross the 64K line.
 
 If I do this
 
 
  	  | Code: |  	  | #org 0x4000,0xFFFF DEFAULT #org 0x10000,0x1FFF0
 | 
 
 The program compiles but doesn't start at 0x04000, it starts at 0x10000 as I can see in program memory after compile.
 So I'm thinking in to put the bootloader in the last 8K and call it from the main program when the main program starts. but if the chip is empty at 0x00000 the bootloader will have a lot of NOPs before starts.
 Could work?
 _________________
 Electric Blue
 |  |  
		|  |  
		| PCM programmer 
 
 
 Joined: 06 Sep 2003
 Posts: 21708
 
 
 
			    
 
 | 
			
				|  |  
				|  Posted: Thu Jan 07, 2021 1:48 am |   |  
				| 
 |  
				|  	  | E_Blue wrote: |  	  | If I do this
 
 #org 0x4000,0xFFFF DEFAULT
 #org 0x10000,0x1FFF0
 
 The program compiles but doesn't start at 0x04000, it starts at 0x10000 as I can see in program memory after compile.
 
 | 
 If you swap the two lines so the 2nd line comes first, then it puts main() at 0x4000.
 |  |  
		|  |  
		| E_Blue 
 
 
 Joined: 13 Apr 2011
 Posts: 417
 
 
 
			    
 
 | 
			
				|  |  
				|  Posted: Thu Jan 07, 2021 2:10 am |   |  
				| 
 |  
				| It works with a small program so I tested with the real program and get this error 
 *** Error 144 "C:\Program Files (x86)\PICC\drivers\stdlib.h" Line 1305(1,1): No valid assignment made to function pointer  1469  from=??0 0 SCR=11998
 
 On that line I have this
 
 
  	  | Code: |  	  | void qsort(char * qdata, unsigned int qitems, unsigned int qsize, _Cmpfun cmp) { unsigned int m,j,i,l;
 int1 done;
 unsigned int8 t[16];
 
 m = qitems/2;
 while( m > 0 ) {
 for(j=0; j<(qitems-m); ++j) {
 i = j;
 do
 {
 done=1;
 l = i+m;
 if( (*cmp)(qdata+i*qsize, qdata+l*qsize) > 0 ) { //<---LINE 1305
 memcpy(t, qdata+i*qsize, qsize);
 memcpy(qdata+i*qsize, qdata+l*qsize, qsize);
 memcpy(qdata+l*qsize, t, qsize);
 if(m <= i)
 i -= m;
 done = 0;
 }
 } while(!done);
 }
 m = m/2;
 }
 }
 
 
 | 
 The main program compiles Ok without the shifted memory.
 _________________
 Electric Blue
 |  |  
		|  |  
		| Ttelmah 
 
 
 Joined: 11 Mar 2010
 Posts: 19966
 
 
 
			    
 
 | 
			
				|  |  
				|  Posted: Thu Jan 07, 2021 3:48 am |   |  
				| 
 |  
				| That's what you get if the assignment to the comparison function has not been made correctly. So:
 
  	  | Code: |  	  | _Cmpfun compare;
 //compare=comp; //rem this out
 qsort(data, items, maxchars, compare);
 
 | 
 
 If you rem out the line assigning the function, you will get this error.
 
 Have you done your #ORG setups, _before_ loading stdlib.h?.
 |  |  
		|  |  
		| temtronic 
 
 
 Joined: 01 Jul 2010
 Posts: 9588
 Location: Greensville,Ontario
 
 
			    
 
 | 
			
				|  |  
				|  Posted: Thu Jan 07, 2021 8:42 am |   |  
				| 
 |  
				| I was thinking about the 'double ORG' .......OK, 2nd pot of coffee isn't ready.... 
 It may be that the #ORG.... feature has been rock solid since day one, when PICs were less than 64K. When CCS needed to increase it, the code might have been simpler (aka solid) and faster to  do the double ORG instead of a total rewrite. Odds are the original coder didn't get to do the 'upgrade', so new guy did what he could.... a bodge, not a total recode.
 |  |  
		|  |  
		| E_Blue 
 
 
 Joined: 13 Apr 2011
 Posts: 417
 
 
 
			    
 
 | 
			
				|  |  
				|  Posted: Thu Jan 07, 2021 1:18 pm |   |  
				| 
 |  
				|  	  | Ttelmah wrote: |  	  | That's what you get if the assignment to the comparison function has not been made correctly. So:
 
  	  | Code: |  	  | _Cmpfun compare;
 //compare=comp; //rem this out
 qsort(data, items, maxchars, compare);
 
 | 
 
 If you rem out the line assigning the function, you will get this error.
 
 Have you done your #ORG setups, _before_ loading stdlib.h?.
 | 
 
 The function is made by CCS, not me.
 Also I don't call the stdlib.h, but I use USB CDC library, maybe that library call it.
 
 I don't understand your correction; can't find  qsort(data, items, maxchars, compare);   in the stdlib.h
 _________________
 Electric Blue
 |  |  
		|  |  
		| temtronic 
 
 
 Joined: 01 Jul 2010
 Posts: 9588
 Location: Greensville,Ontario
 
 
			    
 
 | 
			
				|  |  
				|  Posted: Thu Jan 07, 2021 2:11 pm |   |  
				| 
 |  
				| Qsort is not in that header file, it's in the examples folder as ex_qsort.c 
 At least on my PC....
 |  |  
		|  |  
		| E_Blue 
 
 
 Joined: 13 Apr 2011
 Posts: 417
 
 
 
			    
 
 | 
			
				|  |  
				|  Posted: Thu Jan 07, 2021 7:04 pm |   |  
				| 
 |  
				| I'm not using ex_qsort.c 
 It seems like the atoi,atol and atoi32 is using stdlib.h
 
 
 
  	  | Quote: |  	  | Have you done your #ORG setups, _before_ loading stdlib.h?. | 
 
 Yes. I have this at the beginning of the main program
 
 
  	  | Code: |  	  | #include <18F67J50.h> 
 #fuses INTRC_PLL,PLL2,NOCPUDIV,NOIESO,NOFCMEN,STVREN,CCP2E7,NOWDT,WDT2048,PROTECT //WDT8Seg. No criytal
 #DEVICE ADC=10
 
 #org 0x10000,0x1FFF0
 #org 0x1000,0xFFFF DEFAULT
 | 
 
 Then the rest of the code.
 _________________
 Electric Blue
 |  |  
		|  |  
		| Ttelmah 
 
 
 Joined: 11 Mar 2010
 Posts: 19966
 
 
 
			    
 
 | 
			
				|  |  
				|  Posted: Fri Jan 08, 2021 1:36 am |   |  
				| 
 |  
				| Qsort, is in stdlib.h 
 The example Jay, just shows how to use it.
 
 Now the error, suggests that something thinks qsort is being used.
 That particular error occurs if the compiler does not find a correct
 pointer being allocated for the comparison function, when it is being used.
 
 Thoughts:
 First it is very common for an odd error like this to occur when an early
 line in the code (before the include file is loaded), has a syntax error,
 which then results in the compiler getting this far 'through' including the
 file before it decides to fail.
 That it is happening when the #ORG lines are being used, suggests that
 it is something in these that is fractionally wrong.
 Commonest things are silly spacing faults that are not documented. For
 example spaces or lack of spaces. I've had issues if you have a missing
 space or an extra space in the #ORG line. Several of the examples
 given in the manual, don't actually work with the spacing they are shown
 with....
 I see you have posted the lines involved.
 What compiler version are you on?.
 
 As a general comment, never use 'protect', till you have running code.
 Using it when developing shortens the life of the chip, requiring a full
 erase is performed for even a one byte change in the code....
   
 Looking at the lines you have posted, they don't actually make sense.
 If you want to place the code to actually run starting at 0x1000, then
 just use #build.
 
 If you build at 0x1000 with your compiler version it is merrily accepted.
 Using #ORG is never going to work, since the compiler needs to have
 somewhere to put the vectors for interrupt handling. With #ORG, these
 are still going to need to be at the bottom of memory, together with the
 jump to the main code, with the result that part of the bootloader will
 be overwritten. It may well be that the error you are getting is simply
 because the compiler cannot work out where it is meant to put these.
 A 'silly' error message then results....
  |  |  
		|  |  
		| E_Blue 
 
 
 Joined: 13 Apr 2011
 Posts: 417
 
 
 
			    
 
 | 
			
				|  |  
				|  Posted: Sun Jan 10, 2021 12:22 pm |   |  
				| 
 |  
				| CCS V5.091 
 I tried to use #build before #org but never work it for me.
 When I compile the code with #build puts a goto @init at the address that I indicated but the CCS code and my code start at 0x0000, so I quit and tried with #org and worked with 'default'.
 
 I tried the following in different configurations with no success.
 
 
 
  	  | Code: |  	  | #build(reset=0x200:0x207, interrupt=0x208:0x2ff) #build(memory=0x2000:0x2FFF)
 
 #build(Bootload)
 
 #build(reset=0x1000:0x1007, interrupt=0x1008:0x1fff)
 | 
 
 Of course not at same time. I just tried with different addresses.
 _________________
 Electric Blue
 |  |  
		|  |  
		| Ttelmah 
 
 
 Joined: 11 Mar 2010
 Posts: 19966
 
 
 
			    
 
 | 
			
				|  |  
				|  Posted: Sun Jan 10, 2021 12:32 pm |   |  
				| 
 |  
				| #build(reset=0x1000, interrupt=0x1008) 
 Read the manual.
 |  |  
		|  |  
		| E_Blue 
 
 
 Joined: 13 Apr 2011
 Posts: 417
 
 
 
			    
 
 | 
			
				|  |  
				|  Posted: Sun Jan 10, 2021 1:07 pm |   |  
				| 
 |  
				| I tried that too, but that only put the reset 0x1000 and interrupts at 0x1008. Ok, that's fine, but also puts a lot of code and string tables BEFORE that address.
 
 
   
 And at 0x0000 there's no code to make the interrupt vector jump to 0x1008
 
 
   
 The manual have a really short explanation.
 
 For example:
 Bootload - produces a bootloader-friendly hex file (in order, full block size).
 I don't even understand what that means, so I'm trying different combination and seeing what happens after compile; but there's a lot to try.
 _________________
 Electric Blue
 |  |  
		|  |  
		| temtronic 
 
 
 Joined: 01 Jul 2010
 Posts: 9588
 Location: Greensville,Ontario
 
 
			    
 
 | 
			
				|  |  
				|  Posted: Sun Jan 10, 2021 1:27 pm |   |  
				| 
 |  
				| Ok.. let's go back to 'square one', the 'beginning' with this... 
 I'm trying to add an offset to my current program to make space to the bootloader
 
 While I haven't used a bootloader for decades... my understanding is that first you 'burn' the bootloader into a PIC, THEN you compile your 'main()' program on the PC.You powerup the 'target' PIC, which will run the 'booloader' program. When the bootloader program sees you 'press a button' (or some other 'flag/request') , the BOOTLOADER then downloads you 'main() ' program from the PC into available memory AND it fills in  the addresses in the 0x0000-0x???? areas to tell the PIC where to start from as well as where the real (main() ) vectors will be.
 
 CCS does provide an example of how to use their bootloader, in the EXAMPLES folder.
 
 Maybe I'm wrong but I get the idea you're trying to do it the other way round. If so there's a problem in that main() doesn't KNOW how big the bootloader is and a few other 'details'...
 |  |  
		|  |  
		|  |  
  
	| 
 
 | You cannot post new topics in this forum You cannot reply to topics in this forum
 You cannot edit your posts in this forum
 You cannot delete your posts in this forum
 You cannot vote in polls in this forum
 
 |  
 Powered by phpBB © 2001, 2005 phpBB Group
 
 |