• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 79 subscribers
  • Views 897 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Separate RAM organization for bootloader

Maximilian Gauger
Intellectual 320 points
Other Parts Discussed in Thread: MSP430F5310

Hello all,

my MSP430 project (MSP430F5310, CCSv6) will have the feature to be reprogrammed via a bus line which it is connected to. I have written some code to compress and encrypt the data, using the .txt file as an input.

Uncompressing the data requires a certain buffer in RAM[1] (configurable, 4 kB would be a good size). During the decompression, no other function (except I2C access) is running. Simply declaring a 4kB buffer will not fit into RAM (even when declared static).

So, I need some way to detect a space in RAM which I can use for my buffer while the decompression routine is running. Accessing an arbitrary memory location is not an issue, finding the right one is the harder part. I can of course manually check the map file and try to find my way around .bss and .data, then hard-code the address into the routine. I would however prefer a way which involves less manual (i.e. error-prone) interaction.

I am also not sure which memory locations (except for the stack) I should better avoid in order not to mess with rts430x_lc_sd_eabi.lib and the like.

Any good ideas?

Max

[1] I am using a slightly modified LZ77, which uses the already decompressed data as its dictionary. I could also use the data which has already been written to flash, but this is difficult as my routines support non-continuous data in the .txt file.

  • 0
    Guru 58965 points

    F5310 has 6kB RAM. If you need more than 2kB for other variables, stack, etc., then you do not have 4kB for your buffer.

    Try ask for smaller buffer and look at the Link Map to see what are left unused.

    RAM is at address 0x1C00 to 0x33FF.

  • 0 in reply to old_cow_yellow
    Intellectual 320 points

    Maybe I did not get across what I wanted to say.

    During normal operation, I need > 2kB of RAM. During reflashing, I could re-use most of this RAM as no functionality except reflashing and I2C are active.My post was asking how I can achieve this re-use.

    Max

  • 0 in reply to Maximilian Gauger
    Guru 58965 points

    I think one way to do this is to have two separate "projects". In one "project", you use part of the Flash and all the RAM. In the other "project", you use the remaining part of the Flash and all the RAM again. This way you could load both projects into the Flash, but you should not allow the two projects to mingle during execution.

    Another way is to use "union" to allow the same RAM to be used in different ways. But again, you have to make sure that there is no conflict during (and after) execution.

  • 0
    Guru 227245 points

    Once your bootloader has started decompressing and replacing the application, the application and therefore its ram area is void. Next time it will be the new application and it will initialize its variables.

    So you can simply access the ram without caring for its content (except for its top area, where the stack is, including the local variables of your bootloader).

    Your bootloader should collect all required data in local variables (on the stack) and then just use a pointer to the beginning of ram to use the ram as a big array.
    Like this:
    unsigned char * data = 0x2000;

    Then data[0] accesses address 0x2000, data[1] accesses 0x2001 etc.
    Of course this will overwrite all global and static variables in this area, but who cares? The new application will initialize their ram anyway, once the bootloader is done.

  • 0 in reply to Jens-Michael Gross
    Intellectual 320 points

    Jens-Michael and all others,

    thank you. After diving a bit deeper into the documentation, I figured that what I really wanted and needed was a custom BSL, which is effectively a project of its own. So I have started writing one.

    I will however keep in mind the idea of putting all data in local variables to keep the heap empty. Don´t need it this time, but might be helpful some time in the future.

    Sorry about not having being more precise - even after two years with the MSPs, they still have surprises to offer.

    Max

**Attention** This is a public forum