I'm using LPC845 Cortext M0+ chip. I'm able to jump from bootloader to application and application to bootloader. Once the microcontroller is power on first time it check whether application is present or not, if application is present is jump to application. When I would like to jump back to bootloader i'm using the same logic to jump to bootloader and it works well.
Now I would like to perform some specific task if bootloader is execute from application.
Is there any best way to check whether bootloader execution start from application or it is normal power on execution?
I may use the same technique to multiple controller so kindly suggest best way to perform above task
Related
I'm aware that on some STM32 boards, they come with a built in bootloader in their ROM. Quoting from STM32 Application Note
The bootloader is stored in the internal boot ROM (system memory) of STM32 devices, and is
programmed by ST during production. Its main task is to download the application program to the
internal Flash memory through one of the available serial peripherals (such as USART, CAN,
USB, I2C, SPI).
However the ability to reflash at any time, i.e. trigger a reflash when your board is a running a program confuses me. My understanding is that a bootloader is the first piece of code to execute and then launches your user program. However, to facilitate this flashing at any time, won't the bootloader have to constantly poll for a request to reflash?
The bootloader only polls for an update on start-up/reset. So not "anytime" in the sense of "spontaneously" - you do have to trigger it. If the programmer has access to the reset pin or control of power, it can of course invoke a restart.
Moreover the ROM bootloader only runs at all if the BOOT pins are set appropriatlely. The boot modes are Flash, SRAM or ROM.
Your understanding is right. Almost.
In case of STM32, you need to set up the chip to run the bootloader, typically using BOOT pins. When the bootloader runs, it checks if the programming is necessary by monitoring the specific peripherals. If the programming is not triggered, it jumps to the user program.
Therefore, you cannot reprogram at any time, only at boot time.
Here is an example bootloader flowchart for programming over UART or I2C.
See this application note on STM32 bootloader for more details.
I'm currently working on an IoT project and I want to log the execution of my software and hardware.
I want to log them then send them to some DB in case I need to have a look at my device remotely.
The wip IoT device will have to be as minimal as possible so the act of having to write very often inside a flash memory module seems weird to me.
I know that it will run the RTOS OS Nucleus on an Cortex-M4 with some modules connected through SPI.
Can someone with more expertise enlighten me ?
Thanks.
You will have to estimate your hourly/daily/whatever data volume that needs to go into the log and extrapolate to the expected lifetime of your product. Microcontroller flash usually isn't made for logging and thus it features neither enduring flash cells (some 10K-100K write cycles usually compared to 1M or more for dedicated data chips - look it up in the uC spec sheet) nor wear leveling. Wear leveling is any method which prevents software from writing to the same physical cell too frequently (which would e.g. be the directory for a simple file system).
For your log you will have to create a quite clever or complex method to circumvent any flash lifetime problems.
But the problems don't stop there: usually the MCU isn't able to read from Flash memory when writing to it where "writing" means a prolonged (several microseconds up to milliseconds depending on the chip) sequence of instructions controlling the internal Flash statemachine (programming voltage, saturation times, etc.) until the new values have reliably settled in the memory. And, maybe you guessed it, "reading" in this context also means reading instructions, that is you have to make sure that whichever code and interrupts that may occur during the Flash write are only executing code in RAM, cache or other memories and not in the normal instruction memory. It is doable but the more complex the SW system that you are running above the HW layer, the less likely it will work reliably.
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've started writing a boot loader for my z80 system.
So far the program can accept hex via serial and load it to a location in the memory.
The problem I have though is the boot loader is at the start of memory and uses the interrupts,
How can I load a new program with out overwriting the boot loader?
(Also a loaded program might want to use the interrupts as well)
The best and most widely used approach is to split your app into a stable boot loader that is never updated, and the application that you can replace from time to time.
AFAIK, in Z80 there are just interrupt vectors and there no support for replacing them in the CPU itself. You need to have something in your hardware that will replace your memory blocks.
Othewise you need to have feature that bootloaders is not using anything in the app part during the download and block any interrupts that can call anything in the app.
W.r.t. locations, you may place the bootloader at the top of the address space and load a program at the beginning of the address space.
You can also include the location and size of the program in the protocol so the bootloader would be able to check whether the pair of values is compatible with the bootloader location and size (IOW, whether or not the program would overwrite the bootloader if loaded).
Another option is to include relocation information in the program and a simple relocator in the bootloader. That way you'd be able to load the program at any location if there's enough free memory. This is what many OSes do when they load programs.
As for the interrupts, I don't see a problem. Who or what is there not to allow the program to use interrupts? Or do you want the bootloader to say resident and either continue to do something in the background or be able to return to it from the program? If you don't need any of these, just let the program use the interrupts (you probably don't even need to do anything to allow that).
If, OTOH, you do want the bootloader to remain functional you can introduce an extra layer of indirection by maintaining an additional interrupt vector table. The primary ISRs would extract the secondary ISRs from this interrupt vector table and jump there. Your bootloader and program would then need to do this in order to add a new or override an existing ISR:
disable interrupts
get the old ISR address from the additional interrupt vector table
put the new ISR address into the table
enable interrupts
Removing an ISR is obvious and similar to the above.
The new ISR can then:
before doing its work call the old ISR (the address is preserved at step 2 above)
after doing its work call the old ISR
just do its work without calling the old ISR
You need to require that the programs and bootloader use this table and restore it when they no longer need to have their own ISRs in it.
I don't know what issues you may need to solve if you chain ISRs by executing the old ones before/after the new ones. But in some systems that's a possible design. Many x86 PC programs and drivers did that in MSDOS.
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.