3
\$\begingroup\$

I have an application for my ARM7 which is usually burned to FLASH, and then on execution it is copied to RAM (to run a little faster). But I remember that my professor once said that I should run my program from RAM because you can only burn the FLASH that many times. So my question is - is there some special way of burning the program so it can be executed directly from RAM (not by copying from FLASH)? I know I could use some custom bootloader, but that's not an option. I can use SAM-BA loader but to my understanding it is used for flashing the device, it cannot be used to execute any code from RAM, and if it could, is writing directly to RAM possible?

\$\endgroup\$
5
  • \$\begingroup\$ SAM-BA can be used to write your application code directly to RAM, but it must be compiled with the correct base address. You will also need the bootloader to know to look in RAM to start execution. The SAM boot loader (burned on the chip) automatically looks at several locations to find a suitable boot vector, if it finds none it drops you to the debug shell and you can burn ram and do a soft reset. Once you've programmed to flash the bootloader merely copies it to ram for execution, it typically does not write back so you only excercise the flash when downloading your binary \$\endgroup\$ – crasic Aug 20 '15 at 21:04
  • \$\begingroup\$ OK, the Datasheet says that SAM-BA uses some portion of RAM for internal operations, so the user space starts at 0x202000, whereas the RAM starts at 0x200000 (and FLASH at 0x100000). I assume that the vector table must start at 0x202000 at the beginning of the user space. Is that the address (assuming the linking process is done right) where I should "burn" the binary to? So how's that different from writing to flash? \$\endgroup\$ – Bart Aug 20 '15 at 21:17
  • \$\begingroup\$ If you are running bare metal then you would use the entire RAM, SAM-BA lives in ROM and tries to move code from your flash to the first few blocks of RAM and then hooks into your OS or secondary bootloader, you are trying to use it to start a baremetal application, the simplest case is to burn it to the entire ram and execute a jump to 0x2000 0000, but if you want the SAM bootloader to do so automatically then you will need to trudge the docs to figure out what it looks for to decide where to start executing. This will require tinkering, but generally is doable. \$\endgroup\$ – crasic Aug 20 '15 at 21:28
  • \$\begingroup\$ You should be able to program the RAM via the JTAG/SWD interface. \$\endgroup\$ – kkrambo Aug 20 '15 at 21:53
  • \$\begingroup\$ OK, I figured it out. I used SAM-BA to send the .bin (properly linked) to the start of the user space, just after SAM-BA internal stack, and then used 'go 0x202000' to start the execution from this address. I found the command on some old site, now I'm trying to find it in the official docs. Thanks for the provided information anyways! \$\endgroup\$ – Bart Aug 20 '15 at 22:02
1
\$\begingroup\$

SAM-BA is a boot loader, so if you have samba you really dont need to re-invent another one. Just use it. Jtag usually works as well for being able to load programs into ram and running them. Eventually though I assume your application will need to be run from flash once you turn this into a project/gadget or whatever. not required but assumed. you could wrap your ram version with a small copy to ram program.

I recommend you use sam-ba or whatever to wipe the user flash so that samba doesnt try to load that and to insure the chip is in a known state. Not sure about samba but it is possible that once the bootloader fails to detect a program in flash it might up the clocks or setup peripherals (uart) that it might not have if it had copied flash, so you may still end up in a situation that your tested in ram program works but once you copy it from a flash based program or run it from flash it may not work. some flash cycles may be required to finish testing. or you can make your own bootloader that samba runs and then you are in a known state. My preference is a dumb xmodem thing, bootloader does just enough to setup the uart and start waiting for an xmodem download, then downloads to a known address in ram. then replace the xmodem downloader with the copy to ram and run. that way there are no surprises.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.