Currently I'm making the step to upgrade my spare-time projects to the use of an ARM instead of the 8bit micros from Microchip.
But unfortunately I ran into some problems:
I do not really understand the differences in ways of programming:
- programming into ROM
- programming into RAM (which is only 32K in my case)
I already did some "hello world" tests with the IAR IDE where the compiling/programming was done with a given configuration I didn't worry about. But I didn't like the IAR IDE and the 32K limit of the IAR compiler so I decided to set up a new environment (see configuration below).
After setting up the Eclipse environment, using the examples provided by IAR I managed to program the ARM into RAM. But when I wanted to program the ARM to ROM the program doesn't seem to do anything. I used example makefiles which I believe did some sort of mapping to ROM or RAM, I only had to define one of them each time.
I know that ROM is read-only memory and wont be empty after the power has been disconnected and RAM is faster but requires the program to be downloaded to the ARM each time.
Do I need to devide my program into parts of ROM and RAM, or can I program everything to ROM in a way that the ARM will remap the code to RAM when it is powered up?
Currently I am using the following configuration:
Codesourcery GCC
Eclipse C/C++
Segger Jlink programmer (GDB server)
CMSIS or LPCOpen library (not completely working yet)
NXP LPC1766 Cortex M3
Windows 8 64-bit
IAR examples for LPC1768 and CMSIS
examples from NXP: lpc17xx.cmsis.driver.library
Could someone please help me understand the different uses of ROM and RAM and how I should set up my compiler/makefiles to make use of the ROM and RAM memory.
In the end I want to be able to program the ARM (I think) into ROM in a way that I can power-off the ARM without having to reprogram it each time.
I think you need to look at the linker map files provided with the examples. These files will have a .ld extension and often you will see the letters RAM or ROM or Flash in the file name. The linker file is just a text file so you can examine it in the Eclipse editor. The important part is that the .text section is located in the ROM.
The launcher for the GDB will also have a startup script associated with it. You can edit this using the Configure... choice under the same Eclipse menu item that starts GDB. The script needs to end with lines like
monitor flash device = LPC1343
monitor flash download = 1
The monitor command in GDB sends the rest of the line to the GDB server. The flash commands are explained in the JLink GDB server manual.
EDIT: The .text section is the default section used by the linker for executable code. In my gcc_arm.ld file I have this:
SECTIONS
{
.text :
{
KEEP(*(.isr_vector))
*(.text*)
} > FLASH
I put the reset and interrupt vectors in their own section and force the linker to put those at the very beginning of the executable code.
Related
I searched a lot a bout this question and I did not find any clear answer yet.
As you know, AVR microcontrollers e.g. Atmega128 have a Flash memory which can be divided into Bootloader and Application memory. I've adjusted the parameters of each one and loaded my boot and application load. Is there any way (using code or from terminal) to know the exact size of each memory and the available bytes????
Some people may be mention avr-size command. This command give me the size of the whole flash memory. I want to distinguish between boot and application memory.
Thanks in Advance
You have two firmwares, the bootloader and application, each will have its own size.
For each build, add the linker flag to your linking command line -print-memory-usage to make it print how much flash and RAM is used.
(This flag is not supported by every tool-chain, but AVR might support it)
More info: https://stackoverflow.com/a/41389481/2002198
Or, you can get the memory usage with avr-size:
avr-size -C --mcu=atmega168 project.elf
Reference: http://www.avrfreaks.net/forum/know-code-size-and-data-size
There's other detail you have to be aware: Depending the way you are loading your application (flash writing vs bootload loading) you will align the application with FLASH blocks (usually 2 kibs). Depending the way you are doing you will have smaller available flash memory to the application.
Just read the manual:
The actual address of the start of the Boot Flash section is deter-
mined by the BOOTSZ fuses
and you will find your answer.
If you have already built your bootloader then you should be able to tell how big it is either by looking carefully at the steps you performed to build it, or by examining the HEX file for the bootloader. The HEX file says exactly what addresses the code in it are written to.
I'm using Arm DS-5 and Xilinx SDK for developing programs on Zynq board.
I'm trying to boot Zynq 702 board from Qspi Flash.
What I've done so far is generating FSBL project from Xilinx SDK, and combining it with my application using Bootgen tool in SDK, then program it into the flash.
There are several questions in my mind.
DS-5 produces an .axf file, Bootgen requires an .elf file. Can I use
the .axf file by just changing its extension to .elf or do I require
some more steps?
Is there a tool that shows the inner structure of an .axf file?
Showing what is where?
And how can I debug if I managed to boot from QSPI. For example I want to debug my application from the beginning of FSBL, is it possible? Because in Qspi Boot, When I power on the board, my application would start running and when I connect with JTAG, it would be in somewhere in my application.
An AXF might have some extra ARM-toolchain magic in it (I'm not sure off-hand), but at heart it's an ELF file - the ARM toolchain provides fromelf for poking around inside them, but other tools like readelf and objdump also work.
I'm not familiar with the Zynq platform so I don't know any specific debugger tricks, but a general one is just to put an infinite loop at the start of your code (possibly using volatile or inline asm trickery if necessary to prevent optimisation) - once the debugger's connected and broken into it, you just move the PC past the loop and continue.
You can totally halt QSPI-booted Zynq via JTAG and do whatever you want with it. However, there are some quirks. Sometimes Zynq goes into some kind of lockup, and JTAG doesn't work at all, and you need to power-cycle before retrying. Some not-so-well-written peripherial might die after starting software over JTAG, so you might need to re-load bitstream first. And there are some Vivado-related bugs (like the one where you cannot re-flash the board unless you downgrade to 2017.2 or change MIO2-6 pulls or patch the FSBL) but i'm not sure if they apply in your case.
I'm new on OpenOCD, has anyone attempted to use Olimex OpenOCD to actually flash program hex file (from Kiel say) into ARM CORTEX M0 (generic).
What do I need to setup script file to take each word of the hex file to performs mww (memory write word) within the MCU flash?, can anyone provide an example. I use python.
I open for suggestion.
I use Window PC.
All Cortex M0 that I know of have no JTAG, but only SWD support. SWD is not yet available in OpenOCD - it is still in development.
Another note: The method for writing the flash memory is specific for each vendor/chip.
Sure, what platform in particular? some googling will find the exact sequence. flash unlock, erase, program, etc.
Section 6 of this page for example.
http://pygmy.utoh.org/riscy/cortex/led-lpc17xx.html
I am trying to figure out what board I did it on but those were pretty much the commands I followed and it worked just fine. It may have been the leaflabs maple mini. The steps are the same. To avoid the steps or scripting it, etc. what I ended up doing was writing a few lines of bootloader that said if ram+0 = 0x12345678, and ram+4 = 0x87654321 then branch to ram+8 else infinite loop. then it was trivial to use the jtag to load a program into ram with the two words and an entry point at 0x08 bytes into ram, press reset and run the program. On a cold power up it just hits the infinite loop. I spend my day on a bigger arm based system loading everything into ram using jtag so it made it quite comfortable. You could just script it in openocd and simply type the openocd command have the flash load happen.
Update for people stopping by...
You do not have to use mww, if you're just trying to flash-program (eg. upload your own code) to your microcontroller.
Some time ago, OpenOCD got a ("built-in") convenience-script, that you can use for programming, this "command" is called "program".
Here's an example from the documentation on the "program" command:
openocd -f interface/ftdi/jtag-lock-pick_tiny_2.cfg -f board/stm32f3discovery.cfg -c "program filename.elf verify reset"
-Replace "stm32f3discovery" by your board. If you use a different adapter, replace the interface with the appropriate configuration file.
I am currently working with some µC systems and I'd like to go deeper into detail to understand what is going on beneath.
I am currently working with a Motorola Coldfire and an ARM 9. For both I am using the GCC toolchain as a cross compiler!
ELF files contain more information than needed to get the application run! A BIN file would be enough though! I know the ELF format keeps some extra information. it concatenates symbols and their addresses in memory, right? Are the extra information for the software debugger (e.g. GDB) only or are some of theses information transfered to the target device as well? So if there is a breakpoint hit, the on-chip debugger tells the host the regarding address and the software debugger can show me the relevant code section instead of the boring memory address only?
Can I debug using a BIN file only (Ok this would be stupid, but basically?)?
Some enlightenment regarding this topic is appreciated!
thynk you
You are right that ELF files contain extra information, such as symbols used for debugging. Typically in a µC environment, you will use the BIN file to execute on the processor (usually loaded into flash) and then you would pass the ELF file to GDB for debugging. When running the cross-compiled GDB on your development PC, it will use the ELF file for reference (so it knows code line numbers, variable names, etc.) but it will communicate with the on-chip debugger to read memory locations, set breakpoints, etc. To get GDB to communicate with the on-chip debugger, you use the target remote command in GDB, passing it whatever parameter is necessary (often a serial port of network address & port).
Please list some software/s and links which can help me build firmware for Atmel 89C2051 micro-controller. Thanks.
The Atmel AT89C2051 is a 20 pin version of the popular 8051 microcontroller. The program memory (Flash) is limited to 2K and all the instructions related to jumping or branching should be restricted such that the destination address falls within the physical program memory space of the device. The Atmel AT89C2051 also has all of the normal 128 bytes of RAM as well as the built-in UART.
The datasheet (PDF link) is often a good place to start when developing firmware for a microcontroller.
Since the Atmel AT89C2051 is fully compatible with the MCS-51 architecture, and can be programmed using the MCS-51 instruction set, http://www.8052.com should be a good resource.
http://www.google.com/search?q=89C2051+site:www.8052.com
The open source Small Device C Compiler (SDCC) toolchain can be used to produce the necessary firmware files for programming the Atmel chip.
The Atmel C51ASM assembler is a two-pass macro assembler for the Atmel AT89 Family of 8051 microcontrollers and, according to the documentation, supports the AT89C2051.
The Stack Overflow questions tagged 8051 may also be of use.
I used Keil µVision for developing firmware for microcontrollers with MCS51 instruction set. It was convenient, but it was not free and trial version had some limitations on size of firmware.
You need 2 or 3 things:
Develop the firmware: Depending on what programming language you are good at, you may use assembly language [a51 & asem51 are good assemblers], c cross-compiler [keil c51 free trial version should be sufficient] or even basic [you can find a basic compiler for 8051 on the net].
The firmware should be in Intel hex format; if your assembler/compiler output is binary code, you need a bin2hex utility to convert the binary code to hex format. You can find freeware bin2hex utilities on the web.
A programmer [this is hardware] for loading the firmware into the microcontroller's program memory.