I am working on controller having architecture of ARM CORTEX M4.
Flash of controller contains 2 different applications Boot loader and Application.
I want allocated RAM section via to store some data which I will share in both boot loader and application.
Problem for me is when I jump from one application to another(Reset vector) my RAM section data from which I want to persist is getting cleared.
As I am new to this kind of implementation, please guide me how can I achieve such implementation where RAM data will persist after soft reset or jump from one application to another.
Thanks in advance.
This will be linker dependant, so look at the manual for your linker to see how to make a memory region not be initialised.
Depending on your microcontroller too, there may be some memory you can use, in the RTC peripheral of STM32s for instance there are some (20 x 32bit) back up registers which wouldn't be initialised and persist in low power states.
Related
I am trying to load 1 GB of data onto DDR3 memory to later use bits of it for on-chip calculations. The data only has to be loaded once and is never altered. I though it might be wasteful(in terms of chip ressources), and definetly complicated for me, to implement a write master interface and a clock crossing bridge for that.
I am hoping there is a way to initialize the DDR3 memory while loading the circuit onto the chip like it is possible with on-chip RAM. I haven't found anything online but I am hoping somebody here can confirm if it's possible or not and possibly how.
I am using Quartus Prime and a Stratix V FPGA.
A chicken-and-egg problem. For DDR3 memory to work properly, you need a working DDR3 memory controller. For that, you'll obviously need your FPGA configuration up and running.
Consequently, you just can't upload your design and the memory contents at configuration time as the DDR3 memory contents would need to be 'parked' somewhere on the FPGA until your memory controller is fully initialized.
You will have to look for some alternative method (e.g loading from an external ROM) after your initial FPGA configuration is finished.
Reading or writing to DDR3 memory requires a DDR-controller because it is not a simple operation like for the onchip-memory.
Quartus has a DDR3 SDRAM controller available in the IP library that can be controlled through the avalon bus but it's definitely not simple.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
How reboot procedure works on ARM SOCs running Linux, e.g do boot loaders reinitialize DDR memory? can anybody please explain me rebooting process in detail.
How reboot procedure works on ARM SOCs running Linux, ... ?
The typical ARM processor in use today is integrated with peripherals on a single IC called a SoC, system on a chip. Typically the reboot procedure is nearly identical to a power-on boot procedure. On a reset the ARM processor typically jumps to address 0.
Main memory, e.g. DRAM, and non-volatile storage, e.g. NAND flash, are typically external to the SoC (that is Linux capable) for maximum design flexibility.
But typically there is a small (perhaps 128KB) embedded ROM (read-only memory) to initialize the minimal system components (e.g. clocks, external memories) to begin bootstrap operations. A processor reset will cause execution of this boot ROM. (This ROM is truly read-only, and cannot be modified. The code is masked into the silicon during chip fabrication.)
The SoC may have a strapping option to instead execute an external boot memory, such as NOR flash or EEPROM, which can be directly executed (i.e. XIP, execute in place).
The salient characteristic of any ROM, flash, and SRAM that the first-stage boot program uses is that these memories must be accessible immediately after a reset.
One of the problems of bootstrapping a system that uses DRAM for main memory is its hardware initialization. The DRAM memory controller has to be initialized with board-specific parameters before code can be loaded into DRAM and executed. So from where does this board-specific initialization code execute, since it can't be in main memory?
Each vendor has their own solution.
Some require memory configuration data to be stored in nonvolatile memory for the boot ROM to access.
Some SoCs have integrated SRAM (which does not require initialization like DRAM) to execute a small second-stage bootstrap program.
Some SoCs use NOR flash to hold a XIP (execute in place) bootstrap program (e.g. the SPL program of U-Boot).
Each SoC vendor has its own bootstrap method to get the OS loaded and executing.
Some use hardware strapping read through GPIO pins to determine the source of the next stage of the bootstrap sequence.
Another vendor may use an ordered list of memories and devices to probe for a bootstrap program.
Another technique, is to branch to firmware in NOR flash, which can be directly executed (i.e. XIP, execute in place).
Once the bootstrap program has initialized the DRAM, then this main memory can be used to load the next stage of booting. That could be a sophisticated boot utility such as U-Boot, or (if the bootstrap program is capable) the Linux kernel. A ROM boot program could do everything to load an ARM Linux kernel (e.g. ETRAX), but more common is that there will be several bootstrap programs or stages that have be performed between processor reset to execution of the OS.
The requirements of booting the Linux ARM kernel are spelled out in the following document: Booting ARM Linux
Older versions of Linux ARM used the ATAGs list to pass basic configuration information to the kernel. Modern versions provide a complete board configuration using a compiled binary of a Device Tree.
... e.g do boot loaders reinitialize DDR memory?
Of the few examples that I have seen, the boot programs unconditionally configure the dynamic RAM controller.
PCs have a BIOS and Power On Self Tests, aka POST. The execution of POST is the primary difference between a power-on reset (aka cold boot) versus a software reset (aka warm boot or reboot). ARM systems typically do not perform POST, so you typically will see minimal to no difference between types of reset.
This is way too broad. It's not only SoC vendor dependent, but also hardware and software dependent.
However, the most typical setup is:
CPU executes first-stage bootloader (FSB).
FSB is located on the chip itself in ROM or EEPROM and is very small (AT91RM9200 FSB is 10kB max, AFAIR). FSB then initializes minimum set of peripherals (clocks, RAM, flash), transfers second-stage bootloader (U-Boot) to RAM, and executes it.
U-Boot starts.
U-Boot initializes some other hardware (serial, ethernet, etc), transfers Linux kernel to RAM, prepares the pointer to kernel input parameters and jumps into it's entry point.
Linux kernel starts.
Magic happens here. The system now able to serve you cookies via SSH console and/or executes whatever needs to be executed.
A bit more in-depth info about warm start:
Warm start is a software reset, while cold start is power-on or hardware reset. Some (most?) SoC's are able to pass the info to FSB/SSB about warm start. This way bootloaders are able to minimize the overall boot time by skipping re-initializion of already initialized peripherals.
Again, this is most typical setup from my 15+ years experience in embedded world.
It varies a lot depending on the SoC. I'll describe something like a "typical" one (Freescale iMX6)...
Typically an on-chip Watchdog Timer is used to reset the SoC cleanly. Sometimes, an external Power Management IC can be provoked to perform a board-wide reset (this method may be better, as it avoids the risk of external chips getting "stuck" in an unexpected state, but not all board designs support it).
Upon reset, the SoC will start its normal boot process: checking option pins, fuse settings and initializing clocks and the boot device (e.g. eMMC). This is typically controlled by CPU code executing from a small on-chip ROM.
Either the internal boot ROM will initialize DDR SDRAM (using settings taken from fuses or read from a file on the boot device), or the bootloader gets loaded into internal RAM then it takes care of DDR initialization (and other things). The U-Boot bootloader can be configured to work either way.
Finally, the kernel and DTB are loaded into memory and started.
note uboot, etc are not required they are GROSS overkill, they are operating systems in their own right. to load and run linux you need memory up and running copy the kernel branch to it with some registers set to point at tables that you setup or copied from flash along with the kernel.
What you do on a cold reset or warm is up to you, same chip and board no reason necessarily why any two solutions have to do the exact same thing unless it is driven by hardware (if you do a wdt reset to start over and that reset wipes out the whole chip including the ddr controller). You just have to put the system in the same state that linux expects.
As I know, CPU can access RAM directly. Device RAM is empty on start and CPU don't know from where to load bootloader into the RAM for executing it. Even it can do nothing because call stack should be empty too as I think.
Yet how is bootloader program copied into the RAM for further execution?
This should happening with embedded devices such as smartphones. On a x86 PCs BIOS is responsible for loading MBR section from disk to RAM as I know.
A bootloader in RAM is a secondary bootloader; invariably there is code in a ROM of some kind containing a primary bootstrap that loads the secondary bootstrap. Often that ROM is mask-ROM on the chip it self.
Typically on an ARM application processor such as a Cortex-A the primary bootstrap will load code to RAM from NAND flash or SD card. ARM Cortex-M often run code directly from ROM in any case.
you have the same problem with an x86. and the same solution in general (as with any other processor as well), you put a rom/flash in the address space where the processor boots and/or where its vector table is.
there are some other solutions like having other logic that reads from some non volatile storage and places it in the boot/vector space, or other logic that provides an interface for some other processor/computer to download into the board/chip and then release reset.
I want study cortex-A inside. but AM335X and S5PV210's inside flash can not be changed, so I want to know if there is there any MCU based on cortex-A who's on-chip mask primary bootloader can be changed?
please recommend some for me, if there has.
please forgive my pool English, thank you!
There is usually no flash in a Cortex-A. The ROM code is usually, well.., in a Read Only Memory. When there is a bug in this code, you need to produce a new wafer mask to fix it, but, as millions of parts are produced, the cost reduction is significant, and ROM avoid data retention issues.
Flash memory is by definition re-writable; the parts you mentioned simply have no on-chip flash.
Parts that have on-chip flash typically execute code directly from it, so because of the relatively low speed of flash memory it is usually used on lower frequency processors sub-200KHz.
Fast "applications" processors do not normally have on-chip flash because it takes up a large amount of die space and and has insufficient capacity to support the for the kind of applications and OS (such as Linux, Android or Windows) typically used on such processors. Instead they often have an on-chip mask ROM primary bootloader than loads a secondary bootloader from external media such as NOR flash, NAND flash, SD card, eMMC etc. The secondary bootloader then boots the OS and/or application code.
Code on such processors is loaded to and executed from SDRAM which is much faster than flash. Also the boot media is not always memory mapped so cannot be executed directly in any case.
I am relatively new to embedded programming and have not been able to find a way to save data to the MCU, so that it persists during reboots.
I have read somewhere that I will need to use PROGMEM to save to the MCU flash. But have not found any further details.
I need to be able to perform the following:-
Save a string (device name) to the MCU.
Retrieve the string (device name) from the MCU when required.
I am developing on a ARM Cortex M4 Microcontroller
EDIT: I have just noticed that the ARM Cortex M4 (TI TM4C123x Series) I am working with has 2k of EEPROM, so I am assuming that is a better option for persisting data. But how?
If the data needs to persist through only a soft reset then you should be able to store the data in RAM. You would need to make sure that the startup code does not initialize the portion of RAM where the persistent data is located. But if you want the data to be persistent while power is removed then you need to store the data in non-volatile memory such as flash or EEPROM.
In order to write data to flash or EEPROM you're going to need driver code that manipulates the control registers as necessary. In order to write the driver you're going to have to read and understand the relevant sections of the data sheet for the device.
TI makes an evaluation board called the Tiva C LaunchPad (EK-TM4C123GXL) which contains a TM4C123G microcontroller. In support of the board they also provide software including example programs and drivers. Their driver software includes example drivers for the on-chip flash and EEPROM. You should download this software and review the flash and EEPROM drivers and other examples. You may be able to use their example driver as-is. Here is a link to the Tiva C LaunchPad resource page where you can download the software.
You need to look at the data sheet for your specific microcontroller or system-on-a-chip.
You can probably write to program flash, but that's a bit "scary" since then you run the risk of external tools overwriting your data for instance when you re-flash the actual software the next time.
If your device has some other non-volatile storage area, use that instead of the program flash.
The exact directions on how to do this are (way) outside of what the C language specifies; you need to figure out which registers to write to and in what exact sequence. Often there are timing requirements too.