The chip is an Energy Micro EFM32380f1024 ARM microcontroller and I am using IAR ARM Embedded Workbench. I am aware of the __ramfunc directive however accomplishing initialising and accessing USB completely in RAM (as the flash is going to be completely erased) requires all USB libraries that will be used to be placed in RAM?
This will be used to upgrade the firmware on the microcontroller hence the flash erase. The USB is initialised and used (for normal use by the firmware) for serial communications. I do not wish to use the bootloader for firmware upgrades.
as the flash is going to be completely erased
Not a good idea. In case the update process fails to write the new program completely and the power is lost, your device will be bricked.
Using a bootloader is strongly recommended when you want the flash to be updatable by a user.
Related
I have bought a Gigabyte g1.guerilla motherboard and the NIC is a dedicated freescale chip on the motherboard. It is connected to the PCI bus.
I am running Linux and unfortunately there is no driver for it. I am working to write one, however I am hitting a basic problem: How to communicate and upload code to its dedicated CPU-RAM?
Much help appreciated.
I am running on ubuntu and the chip is a mpc8308vmagd PowerQuicc II pro
I don't know anything about your specific motherboard or the processor, but are you totally sure you need to upload any code to the processor?
Usually, if a peripheral needs any code (firmware), it's already present on a ROM or a flash chip and you only need to touch it if you specifically want to write your own firmware for it. AFAIK the way it usually works is that the peripheral exposes a set of registers on the PCI bus and you interact with it by poking the registers (usually with MMIO). That is, you don't write code for the peripheral, but you write a kernel driver that pokes the registers (ie. the API for the peripheral) when it wants the device to do something.
Now, in general the register descriptions aren't often freely available, which can make writing drivers really hard.
If you really want/need to write your own firmware for the thing, it probably depends on where the code is stored. If it sits in ROM or in an inaccessible flash, you'll probably need to do some soldering. If the firmware is updatable, I'd probably try to reverse-engineer the software they provide for updating the firmware, if one is available. (Unless it allows uploading arbitrary files already, of course)
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.
I am currently working on firmware for a Stellaris ARM microcontroller board and I am running the SYS/BIOS RTOS.
I was wondering if the bootloader is required on the board when I upload my firmware onto it. Can I overwrite the bootloader on the flash with my .bin file, or am I required to offset my start address to preserve the bootloader.
In the general case (i.e. not specific to Stellaris), software is software, the bootloader is software, your application is software, the processor cannot tell the difference so quite evidently a bootloader is not required, the software that runs at reset could as easily be your software.
However the obvious benefit of a bootloader is the ability to apply in-field updates without connecting special equipment; you might regret loosing that capability.
Some chips (again generally, check your data sheet for Stelaris specifics) have a bootloader in mask ROM rather than Flash and you cannot delete or overwrite that, but usually configuration pins can be set to select the boot behaviour in order to by-pass the bootloader for example.
No you can use jtag and dont need running software in order to stop and re-flash the firmware.
I have an evaluation board (Olimex STM32-P103) which supports a SD-card connector. I want to put my program in to a SD memory instead of internal flash of the micro-controler; and run it from there.
I don't know if it is possible to do that according to boot-loader issue!
P.S my goal is running linux on this board and then port my application over it.
To run programs from SD-Card in general you should know that you can't run them "right away". This means, you have to load it in a executable memory somewhere in your address space which is done by a (more or less) simple bootloader. In the simplest instance, the bootloader is capable to read from a SD-Card a specific binary and copy it into the memory.
That being said you should think about this considering you only got 20k of RAM and 128k of Flash on your board. So where should your program go? Or better: Why not flashing the program in the 128k of Flash from the very beginning? Especially you should know that Linux is a bit "hungry" in terms of memory.
If your goal is to run a "normal" Linux on this board, I'm afraid you're screwed. This because from what I know Linux needs a MMU to run and the chip on this board does not provide one (as far as researchable without access to datasheets from ST).
If you're lucky you can go with uCLinux. I'm not sure if a finished port exists for the STM32 but it seems there are some resources based on a short google search for "STM32 uCLinux". But even if you manage to run uCLinux I'm afraid there's not much left in your system for your application, so the result might be a bit disappointing.
Depending on why you are looking for Linux running on this MCU, there are maybe other solutions like a FreeRTOS in combination with a lwIP-stack (if networking is needed) or a FAT library like FullFAT if you are looking for reading SD-Cards and stuff.
Edit: One thing i'd like to add is that booting from the SD-Card is typically something you do with "bigger" (not much but slightly) systems where you have enough RAM to keep the whole image you'd like to run in it and still have some space left for the data you want to process.
You're going to have to have some code in the STM's onboard flash (typically called a "boot loader") that implements this since the "bare metal" very likely can't boot from SD card.
You're going to have to build that code, which figures out how to use the STM's onboard peripherals to talk to the SD card, finds the file you want to run in the file system (which you also have to implement), and loads it.
I wanted to include a link to the STM standard peripheral library, but it seems to be down (being moved). :/
The data on the SD card is not memory mapped, so cannot be executed directly.
It is possible to dynamically load the data from the card into RAM for execution. WindRiver's VxWorks RTOS supports loading and linking object modules dynamically, I know of no other OS that would scale to a Cortex-M that directly supports that but it would be possible to write your own.
However, I would suggest that in the case of the microcontroller you are using the idea is ill-advised; optimal performance on Cortex-M is achieved when the code is in on-chip flash and data in RAM allowing the data and instruction to be fetch to occur simultaneously on the separate buses (Harvard architecture). If you execute the code from RAM the performance will be severely hit since then data and instructions must be fetched sequentially over the same bus.
The board is entirely unsuited to running Linux, with only 128K Bytes Program Flash, and 20K Bytes RAM is is not at all feasible. Even the smallest Linux distribution requires 600Kb RAM plus whatever is needed by application code. uClinux can just about run on higher-end STM32 with external RAM and Flash, but that would suffer from the same bus contention performance hit and Linux without an MMU is rather missing the one major benefit of using Linux at all. The part on your board lacks an external memory interface, so cannot be expanded to support Linux.
If you need an OS consider a RTOS such as uC/OS-II, FreeRTOS, or emBOS for example.
AS other says you cannot directly execute your code directly from the SD CARD.
But like those "linux board", you can load the stored kernel/programm into an external SDRAM that can be mapped and execute it from there.
You'll still need to write that "bootloader" and store it in the internal flash.
That'is a lot work to my opinion, for limited application.
If you want to write your application in a linux environnement then port it suck small target, I would rather design my application using dependency injection, or even use an emulator.
I'm working on a custom Cortex-M3-based device and I need to implement in-application programming (IAP) mechanism so that it will be possible to update the device firmware without JTAG (we'll use TFTP or HTTP instead). While the IAP-related code examples available from ST Microelectronics are clear enough to me, I don't really understand how the re-flashing works.
As far as I understand, the instructions are fetched by the CPU from the Flash through the ICode bus (and the prefetch block, of course). So, here's my pretty silly question: why doesn't the running program get corrupted while it re-flashes itself (i.e. changes the Flash memory from which it is being run)?
A common solution is to have a small reserved area in the flash, where the actual flashing program is stored. When new firmware has been downloaded just make a jump to the code in this area.
Of course, this small area is not overwritten when flashing firmware, it can only be done by other means (like JTAG). So make sure this flashing-program works good to start with. :)
I'm not familiar with STM implementation, but in NXP chips the IAP routines are stored in a separate, reserved ROM area which can't be erased by user code.
If you're implementing the flash writing code yourself by using HW registers directly, you need to either make sure that it doesn't touch the sectors it's running from, or runs from the RAM.
Now a days many micro-controllers supporting IAP, that it is possible to program its flash memory while program execution in the same flash.
For IAP, program memory in the flash may be divided into 2 parts, one executable & other backup parts.
Generally we program the flash memory at a location (say, part-1) through JTAG, whose firmware version is 0.01. For IAP, i.e, program the flash in another part (part-2) while code is executing, corresponding API's should be provide in firmware version 0.01, which helps to program the flash part-2, After completion of programming successfully firmware version will be updated as 0.02. Upon processor restarts, program execution jumps to latest firmware by checking firmware version at initialization.
The part where the firmware is executing is called executable part, and other is back-up. why it is called back-up mean, suppose if there exists any firmware corruption while programming, firmware version will not update & upon restart, program control will automatically jumps back to back-up firmware after checking version number.
Another good way to do it is using custom made bootloader. However STM IAP is not stored in Flash so it can not be overwritten by it self. What generally people do is to spilt the flash in two parts , one is reserved for Custom made Bootloader and Another is for application. Bootloader makes sure that it does not write to its own assigned area. Bootloader can be programmed through JTAG and later application can utilize bootloader to program itself.
As far as I understand, the instructions are fetched by the CPU from the Flash through the ICode bus (and the prefetch block, of course). So, here's my pretty silly question: why doesn't the running program get corrupted while it re-flashes itself (i.e. changes the Flash memory from which it is being run)?
This is because, in general case writing/programming to flash memory is not allowed while you are reading from it(i.e executing code).
Have a look at this for some ideas on implementing IAP.