CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Does #ORG it's only 16bit wide?
Goto page 1, 2  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
E_Blue



Joined: 13 Apr 2011
Posts: 405

View user's profile Send private message

Does #ORG it's only 16bit wide?
PostPosted: Wed Jan 06, 2021 9:19 pm     Reply with quote

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: 19215

View user's profile Send private message

PostPosted: Thu Jan 07, 2021 1:06 am     Reply with quote

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: 405

View user's profile Send private message

PostPosted: Thu Jan 07, 2021 1:39 am     Reply with quote

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

View user's profile Send private message

PostPosted: Thu Jan 07, 2021 1:48 am     Reply with quote

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: 405

View user's profile Send private message

PostPosted: Thu Jan 07, 2021 2:10 am     Reply with quote

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: 19215

View user's profile Send private message

PostPosted: Thu Jan 07, 2021 3:48 am     Reply with quote

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: 9097
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Thu Jan 07, 2021 8:42 am     Reply with quote

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: 405

View user's profile Send private message

PostPosted: Thu Jan 07, 2021 1:18 pm     Reply with quote

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: 9097
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Thu Jan 07, 2021 2:11 pm     Reply with quote

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: 405

View user's profile Send private message

PostPosted: Thu Jan 07, 2021 7:04 pm     Reply with quote

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: 19215

View user's profile Send private message

PostPosted: Fri Jan 08, 2021 1:36 am     Reply with quote

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.... Sad

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.... Sad
E_Blue



Joined: 13 Apr 2011
Posts: 405

View user's profile Send private message

PostPosted: Sun Jan 10, 2021 12:22 pm     Reply with quote

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: 19215

View user's profile Send private message

PostPosted: Sun Jan 10, 2021 12:32 pm     Reply with quote

#build(reset=0x1000, interrupt=0x1008)

Read the manual.
E_Blue



Joined: 13 Apr 2011
Posts: 405

View user's profile Send private message

PostPosted: Sun Jan 10, 2021 1:07 pm     Reply with quote

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: 9097
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sun Jan 10, 2021 1:27 pm     Reply with quote

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'...
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
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