I'm running on Primer2 with a *slight modification* of CircleOS3.7 that allows USART2 to USB (as virtual COM) bridging by default, in order to serve some of our specific applications. We never had problems to build/run a single application on top of our custom Circle3.7, our purpose is now to upload more that on application on Circle. We tried circle manager and the utilities in batch files that you provided but we realized that these run correctly on the original Circle3.7Os only (not on our modification)...
*So we decided to generate our own FAT.elf files to fix the problem*
the starting point were the FAT_Startup.c and related link(ld) file provided on the e-mail you received by repzac on 2009-02-23 14:17:16 with subject "Call application function from another application". Before generating a FAT.elf in order to upload 2 applications I first tested the (thrivial) single application case from the souce you provided but doesn't seem to work, I reported the FAT_Startup.c code below, I'm I missing something?
/* Exported constants --------------------------------------------------------*/ extern unsigned long _etext; extern unsigned long _sidata; /* start address for the initialization values of the .data section. defined in linker script */ extern unsigned long _sdata; /* start address for the .data section. defined in linker script */ extern unsigned long _edata; /* end address for the .data section. defined in linker script */
extern unsigned long _sbss; /* start address for the .bss section. defined in linker script */ extern unsigned long _ebss; /* end address for the .bss section. defined in linker script */
extern void _estack; /* init value for the stack pointer. defined in linker script */
__attribute__ ((section(".isr_vector")))
long unsigned table [ 1 ] = {0x08006000};
//two apps case not tested yet... //long unsigned table [ 2 ] = {0x08006000, 0x0800871c};
Here are some more questions that might help us understand the issue.
Did you get any confirmation that the Circle manager could work only with our CircleOS?
About the FAT.elf can you precise to whom the email from repzac was sent.
when you say :
Before generating a FAT.elf in order to upload 2 applications I first tested the (thrivial) single application case from the souce you provided but doesn't seem to work, I reported the FAT_Startup.c code below, I'm I missing something?
Can you precise what file did you try and what failed?
PS Is there any particular reason you are not using CircleOS version 3.8? And what is your software version?
1)Yes, I'm able to run the Circle manager on your (original) CircleOS3.7 but not on our upgraded circleOs 3.7.
2)The e-mail I'm talking about was sent to your support and Francis took the issue; (You can search by subject "Call application function from another application" on 2009-02-23 ).
3)I basically took the FAT_Startup.c with the link file you provided (*.ld) and compiled it to obtain a FAT.elf to include in my application's project replacing the default FAT.elf. After this I build and upload the application in the primer 2 but the application doesn't startup after entering Circle. When I will be able to make this work the next step will be to generate a FAT.elf with the pointers to two applications rather than one, in other words I'm trying to learn how to generate FATs.
4)My software version is 3.7 with some added upgrades; The reason I'm not using circleOs 3.8 is related to the fact that we started from 3.7 and from this we derived a custom version that provides additional features for interfacing towards an application running on an external processor on an extension board. Now we are in the process of delivering some demos and we don't have time to ugrade to 3.8 (given the amount of work we have I don't even know if we will ever have time to do so).
Do you have a different size for your custom CircleOS ? Did you change the address of the FAT ? Take care the the FAT is growing DOWN...
At the moment, Circle_mgr.exe works in the following way: it reads the FLASH vector table where the address of the end of the FAT is located (see CircleStartup.c, line 140). When the address of the FLASH is known, it can read (and modify) it.
A possible cause could be that you change the FAT address... or that your application is too big, and there is no room for the fat (that grows in the down direction).
There was a little progress since last time, but let me first answer your questions:
Circle didn't grow (I'm at 591k) and looking at the address of the FAT table I have:
#define FA_TABLE 0x8006000
and my first application running on primer's2 Circle is 8k.
By the way the address below is the same value I have within FAT_Startup.c:
long unsigned table [ 1 ] = {0x08006000};
The interesting thing is that now ***I can successfully*** generate the FAT.elf file from FAT_Startup.c with the"one element table" above but as soon as I upgrade the table to accomodate two applications there are problems. In fact if in FAT_Startup.c I set the table array in the following way:
long unsigned table [ 2 ] = {0x08006000, 0x08008000}; //0x08008000 will be start address of the second application
There are two problems:
1) if I rebuild the same application on the FAT.elf generated with the 2 element table above,it, I get a weird behavior of circle (it expands the main menu oversize and the name of the first application doesn't appear within the menu , however the good news is that at least the application starts).
2) After this problem I should also learn how to place the second app exactly at address 0x08008000 while circle and the first application are standing in there respective memory areas.
I feel like I'm getting closer to the goal of setting the FAT for more applications, but I still need these few answers. The whole process involving circle manager was not pursued because when I runnit on my custom Circle it gets stuck in an endless "erase page" loop leading to no success, right after reading the FAT table.
What do you mean by 591k ? (there are only 512KB of FLASH in this STM32). If your custom CircleOS is bigger than 0x6000 (24KB) you MUST move the FAT. This must be done by modifying the LD file of the FAT project. For example if your application is just smaller than 256KB, you could locate your FAT at the border 256K. Note that, because the FAT is growing down, you have to put it at the border minus 4 (0x0803FFFC in the case of 256KB). Note also that you need the FAT.elf only for debugging. If you want to load applications using Circle_Mgr.exe, you just need to modify the address of the FAT into CircleStartup.c). Hope it helps.
forgive me, 591k were referring to the CircleOs elf file size. The application size is 23.66KB (given the text section ending at 0x08005EA4), so if my calculations are correct **size is not the real issue here**.
I'm not sure I understand when you say:
"If you want to load applications using Circle_Mgr.exe, you just need to modify the address of the FAT into CircleStartup.c)."
My purpose was just to initialize the FAT table and given that I don't have size issues I was assuming that the FAT base address(FA_TABLE) should remain 0x8006000;
QUESTIONS:
1)Do you mean that in circle CircleStartup.c I should go ahead and write at FA_TABLE-4, FA_TABLE-8, FA_TABLE-12, .............,FA_TABLE-(4*N) the addresses of the applications I want to point (upto application number N) and that's all?
2)I thought that FAT.elf file was there to perform FAT initialization automatically at upload through Raisonance, that's why I was persisting in learn how to generate it....
Waiting for some lights over the shadows... Thanks for you patience, Adalberto
...following the previous e-mail... just to avoid further misunderstanding, 23.66KB is the size of my own modified Circle3.7 version (by mistake I wrote that was pertaining to the application in the previous e-mail).
The application size is 23.66KB (given the text section ending at 0x08005EA4), so if my calculations are correct **size is not the real issue here**.
Yes, this size is correct to keep the FAT in its original location (0x08006000 is ok for you).
)Do you mean that in circle CircleStartup.c I should go ahead and write at FA_TABLE-4, FA_TABLE-8, FA_TABLE-12, .............,FA_TABLE-(4*N) the addresses of the applications I want to point (upto application number N) and that's all?
Yes, that's all... FAT is a big name for this table.
2)I thought that FAT.elf file was there to perform FAT initialization automatically at upload through Raisonance, that's why I was persisting in learn how to generate it....
FAT.elf is used ONLY by the debug environment (we need to program the Application to be debugged, but also CircleOS, and a very simple FAT that contains only one word (value = 0x08006000) that will be programmed at the address 0x8005FFC.
Now, I don't understand where the problem is: do you have some problems when using Circle_Mgr.exe, or do you want to debug two applications in a single debug session ?
...basically the all story begun from not being able to use Circle_Mgr.exe to load more than one application on Circle.
I'm able to do it on the official 3.7 "factory release" but if I use it on my modified version ithe manager just enter in an erase-page loop process and at the end doesn't do the job, (e.g. I don't get any applications loaded on the primer).
That's way I was seeking for alternative ways towards the same goal.
*By the way are there circle manager issues when for applications above 8KB?* (I relized the first application I upload on circle is 8.88KB, not 8KB as circle_mgr was prompting during it's operation).
I don't know which version you have: some bugs had been fixed in Circle_Mgr.exe if you have an old version of RIDE (for example the version from the CD). But on the principle, it sounds strange that it depends on CircleOS. And I don't think that we fixed any bug causiing this effect... I would say that the problem is not with Circle_Mgr, but with CircleOS. It could be that the size is not what you believe (bigger than 0x5FF8). It could be also that you broke the FAT address into the vector table (did you change anything in CircleStartup.c ?).
1)I doubt it is an issue with Circle_Mgr.exe version because the same version works well after I uploaded the "factory Circle Os3.7" with it's default applications; trying to add an application at this point leads to success.
2)Not sure what you mean with 0x5FF8 specified as size... sounds more like the second FAT entry offset (?)
3)I didn't touch CircleStartup.c;
I wish I could attach images, because I saved snapshots of some runs showing the Circle_Mgr.exe messages in the case when it tries to add an application on the "factory CircleOs" (success case) versus the case with "custom CircleOs" (failure); Can anyone tell me how to manage attachments?
In the meanwhile I'm just trying to set the a Circle_App.ld in such a way that I can compile and link a second application starting at 0x8008800 (to avoid overlap with the first one) and within the application itself I will add the following statements:
1)I doubt it is an issue with Circle_Mgr.exe version because the same version works well after I uploaded the "factory Circle Os3.7" with it's default applications;
I agree
Not sure what you mean with 0x5FF8 specified as size...
Just want to say that, if you need 8 bytes for two entries in the FAT, your application must be less than 0x6000 - 8 = 0x5FF8.
3)I didn't touch CircleStartup.c;
Thus if your application is smaller than 0x5FF8, it should work...
If you want, send me by email your modified CircleOS and I will try.
I finally got things to work, was just a matter of doing things in different order.
If I upload my first application together with the Primer2_Cirdle.elf and FAT.elf all three imported to the same Ride project (by pressing the Debug->start command of Ride) and then later I invoke the circle manager (through add_to_Circle.bat) to upload a second application things are not working.
BUT if I first upload only my modified version of Primer2_Circle from it's *standalone* Ride project and then I use the circle manager to add applications thing work.
I'm not fully sure I understood the reason of this behavior however things finally work...
It was good to know all the details you provided me, Thanks, Adalberto
Thanks for the information. I didn't understand that you loaded the first application from RIDE (I thought all were loaded with CircleMgr). . I will check, but I believe that we don't need to know the size of the application when debgging. But this information is mandatory when adding multiple application to the FAT.
