another question about specifying library addresses

[ISL_Dave]

Hi,

I am still trying to ensure that the SPI and MMC libraries are located in a specific location but not having much success.

I use the command

Code: Select all

#pragma funcorg MMC_Init 30000

and this locates the MMC_Init function to address 30000 as required but I cannot see how to specify all the dependencies that this function uses.

For example, if you look at the statistics>function tree, for Mmc_Init which I have assigned a start address of 30000, there is then listed the Mmc_DeSelect which it has assigned to address 312 (0x0138) amongst other routines.

I have tried to use

Code: Select all

#pragma funcorg Mmc_DeSelect 30362

and

Code: Select all

void Mmc_DeSelect() org 30362;

but the Mmc_DeSelect routine always gets assigned to address 312.

[janko.kaljevic]

Hello Dave,

Please can you tell me is there a specific reason why you need MMC function on this location, and is this case only with this function.
Also do you need all your functions in code to be on high addresses?
For this you can use

Code: Select all

#pragma orgall 0x30000 

Best regards.

[ISL_Dave]

Hi, I am wanting to create a version of firmware that can be upgraded via an encrypted file on a memory card.

There is a posted solution but I cannot use it as it requires a duplicate of the very large MMC library.

I need to have all the MMC and SPI library routines located in either the top area or bottom area of memory so that I can run them at startup, check for the update file, erase the rest of the memory and decrypt then update the erased memory.

My current firmware code occupies 93% of the available 64K and obviously a good portion of this is the libraries (and library dependancies) that I want to ensure are not in the area that I wish to erase.

I am currently looking at using some other library routines from other providers as I have the source code for them and can specify the memory location they get complied to. It is a big job to implement but due to the lack of answers, may be the only option.

The other requirement is that I only have one HEX file, otherwise I could have created a single project with just the bootloader code and a seperate project with the application but this would mean a duplicate of the library routines which I do not have room for.

[janko.kaljevic]

Hi,
The problem with your current approach is that compiler does not support 'org-ing' of static routines at the moment.
We will add this support in some of the future compiler releases.

Based on your project description, we could suggest the following solution.
You will need two separate projects: bootloader and application.

In Bootloader project you should use orgall directive to place all relevant routines at top of mcu flash.
Then you should record addresses of all routines used in your bootloader code, which you want to reuse in application code.

In Application project you should define function pointers for all routines located in bootloader section you'll need.
Assign them with appropriate addresses you have recorded from Bootloader project.
Access to these routines should be preformed through function pointers within your Application code.

Best regards.

[ISL_Dave]

Thanks Janko,

I had thought of doing this but I am not entirely sure how to do what you suggest.

I can create a bootload application and this works fine but I am stuck with the same problem in that both projects require the same libary routines and I do not know how to assign the routines loaded in the bootloader routine to the main routine to stop the main application from adding the same library commands in to the code. It just adds the libary functions in again so I then have two copies (which I do not have sufficient memory for).

If you could give me an example of how to do it, I would be most appreciative.

I would also ideally like to end up with one HEX file rather than program two in as I want to be able to get my customers to upgrade their units using a single TeaClipper device.

I am in the middle of experimenting with putting the bootloader code at the start of memory and using an ORGALL 0x0000 command. This would only work again if the library commands were always in the lower area of memory and I do not know how the compiler decides on where it places them.
I thought that if the bootloader code never changes, the library files may always get assigned to the same address and this seems to work but is a risk as if the compiler decides in the future to put it in a different address then I would be stuck.

Kind Regards,
Dave