Hi all,
I now think I don't understand how the C Tools from ADI work and I thought if I write down my understandings maybe somebody can pin point where is my simple model wrong (quoted test below is from "C Tools Manual").
The C tools from ADI are a set of three elements:
Let's forget about the CBUG and just look at the first two. The G21k is a GCC port to the ADSP21xxx architecture and is essentially a utility to call various other parts (compiler, assembler, linker, ...).
The Runtime Library is a set of functions that allow signal handling and floating point operations.
Now, when the g21k is invoked it will need the "runtime header" and the "architecture file":
and the whole compilation procedure is broken in several stages:
I don't see how the architecture file is used here. But maybe the header can be used if there are macros to be expanded and/or conditional compilation flags.
No use of the architecture file.
Again no use of the architecture file (at least I don't see how it can be used here).
Here the objects are COFF objects and if cdump21k (similar to objdump on a GNU/Linux system) is used at this point we can see how the program memory instructions are stored in a section called seg_pmco, while the data is stored in a section called seg_dmda.
Unless otherwise instructed (option -mpmcode) the g21k will put code in seg_pmco and data in seg_dmda. There is the possibility that data is stored in program memory if C language extensions are used in the code. We can ignore this for the sake of this discussion.
seg_pmco and seg_dmda are directives defined in the architecture files, but at this point all objects are living in a 'limbo' waiting for being linked together and be part of the executable. Since the object code will be "relocated" by the linker (this is just my guess), it is necessary to know in which segment it should reside, therefore I think the architecture file is used in this step.
In stage 5. the directives of the architecture file will be followed to place all the previously defined section of seg_pmco and seg_dmda together, plus the seg_rth (defined in the runtime header) and the seg_init.
Here the Manual is referring to ___lib_setup_hardware, ___lib_setup_processor, ___lib_setup_environment, which are used on reset and they make use of data residing in seg_init.
Here there's something I completely failed to understand so far: in the runtime header there are instructions which are delayed branch jumps to ___lib_int_table that I am naively assuming it will "map" my interrupt service routines which are residing (I think) in the seg_pmco segment, so that when an interrupt is latched, if the interrupt is not masked, the program execution is interrupted and instruction are fetched from the interrupt vector table which will eventually jump to my interrupt service routine (plus some stack push operations).
But where is the ___lib_int_table residing? how does it know where are my interrupt handlers? The reason for these questions is that on the hardware I am working on the seg_init and seg_rth are located in a protected area of the flash, which does not correspond to my current program, nevertheless I believe that my interrupt service routines are still mapped correctly, so I was wondering how is this possible.
That looks pretty simple, I have my code and it will end up in seg_pmco in the location I asked for in the architecture file, the heap and the stack will be used only in a specific area of the DM and everybody is happy.
Now, I'm compiling with the before mentioned option -mpmcode=pm_main because the seg_pmco of my architecture file is pointing to a protected area of the flash and I need my code to end up somewhere else, but when I do this the code looks like "broken" in two segments, one in the seg_pmco and the other in the pm_main. This is quite a surprise to me because I had the naive idea that everything would have ended up in the pm_main. But now that I'm thinking, the whole library has been compiled with seg_pmco as the default segment and I'm assuming that every library function would end up in my seg_pmco segment. So what the heck is left in my pm_main segment then?
Since I have to load the program into the dsp through a lengthy chain of protocols (TCP/IP, NASA-CDP, CCSDS, 1553, CANbus, RS232...bingo!) and through a custom built boot loader which is capable to receive telecommands, I need to know how to stitch together all these segments and write them to the PM/DM in the proper location. I am assuming that the "proper location" would be the one that it is specified in the architecture file and/or the coff dump, so I can get all my segments of pm and dm and write them accordingly.
Someone may suggest to change the architecture file such that I can throw away the need of an -mpmcode switch, to start with. But I fear that doing so I will screw up badly since the boot loader has been created with the current architecture file and I'm not convinced I can move segments around that easily.
Another culprit is that the folks who did the boot loader implemented it such that there's no way to jump to a pm location, therefore the procedure to upload a new software would be to copy it in the pm and then let the boot loader copy it into the flash. At this point the command to boot the sector just written will copy it to pm and then jump to the correspondent pm address. I still haven't understood what happen to the data memory at this point, given that the seg_dmda is supposed to hold
but the boot loader does not care about initializing the data memory. So what about the newly loaded program? It is evident in the coff dump that seg_dmda is full of stuff. The previous team that was working on the software used to do the pm dump from the program loaded with a jtag and then uploaded onboard with the boot loader. But they never took care about the data memory. Well, I must say the previous team was dismissed because the software does not work "as expected"... (ouch).
Ok, I'm sorry about the lengthiness of this post but at least while writing it I sorted out many details going through the Manual. Hope somebody else would find the time to straighten my thoughts in case their too far off the road.
Al