• State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 21 subscribers
  • Views 3299 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Cody copy to RAM on startup?

Jonathan Downey

I am trying to get a custom bootloader to run from RAM only and so we modified our scatter file to be as follows:

LR_IROM1 0x00000000 0x00007FC8  {    ; load region size_region
  ER_IROM1 0x00000000 0x00007FC8  {  ; load address = execution address
   *.o (RESET, +First)
   *(InRoot$$Sections)
  }
  RW_IRAM1 0x1FFF0000 0x00010000  {  ; RW data
    *(+RO)
  }
  RW_IRAM2 0x20000000 0x00010000  {  ; RW data
    *(+RW, +ZI)
  }
}

This appears to work when using the debugger, but not when flashed and run without the debugger. Is it possible that the debugger is copying the code from ROM to RAM? Shouldn't the C Startup library in __main be doing this? Do I need to specify something for this copy to take place?

Thanks,
JD

Parents
  • 0 in reply to Jonathan Downey

    You make the boot loader so trivially simple that it doesn't need to be updated.

    You need fancy communication etc? You make a secondary boot loader that do the fancy stuff.

    Then this secondary boot loader can download a new application or a new secondary boot loader.

    The minimal boot loader can either have a backup serial interface in case reprogramming fails. Or you can have two alternative copies of the more advanced boot loader so you program version 2 and can do rollback to version 1 if needed.

    But you do really not want a system that clears the flash and bricks the unit. In real life, units will brick if you leave a security hole like that.

Reply
  • 0 in reply to Jonathan Downey

    You make the boot loader so trivially simple that it doesn't need to be updated.

    You need fancy communication etc? You make a secondary boot loader that do the fancy stuff.

    Then this secondary boot loader can download a new application or a new secondary boot loader.

    The minimal boot loader can either have a backup serial interface in case reprogramming fails. Or you can have two alternative copies of the more advanced boot loader so you program version 2 and can do rollback to version 1 if needed.

    But you do really not want a system that clears the flash and bricks the unit. In real life, units will brick if you leave a security hole like that.

Children
No data