I am using OMAP3515 processor (Generic CortexA8 Device) for my project and want to boot the system form UART3.
The boot loader code which I am using is working fine when using emulator i.e it is able to write the image into FLASH.
The same boot loader code when I am sending through UART it is executing in RAM but unable to write the image into FLASH.
You may need to unlock the flash. Some systems provide a option to lock and unlock flash.
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 have an application which requires connecting two F&S boards with their default Uboot consoles connected to each other externally. This prevents them from loading the kernel since both of them locks each other by sending characters, since each uboot is waiting with "Hit any key to skip the autoboot".
I don't want to recompile the uboot to change the default console or silent the console. Is there any other solution so that once the uboot has been prevented from auto booting can reenter into the kernel boot state, for instance like booting after a predefined time?
My STM32F401VB MCU has 128KB flash #0x08000000. I have defined a section # 0x09000000 to keep static color images, so the compiled executable has:
- 128KB # 0x08000000 (embedded flash)
- 16MB # 0x09000000 (SPI flash N25Q)
A custom loader running in a computer sends this executable hex image to the MCU, and my custom bootloader running in MCU flashes data:
- # 0x08000000 in embedded flash
- # 0x09000000 in SPI flash
My application checks every image address and it reads from embedded flash or SPI flash accordingly.
The problem is debugging, when I start debugging IAR IDE programs embedded flash #0x08000000 and SPI flash contents # 0x09000000, but MCU has nothing in this address, I don't know how to program the embedded flash and ignore the data outside embedded flash (or program both memories, embedded and SPI).
Removing images is not an option because the application needs to know image addresses to read them from SPI flash. Images won't be modified but application is modified many times every day and I need to debug as easy as possible.
What is the best approach to debug an application using images in SPI flash?.
Best regards and thank you in advance.
I have an application that needs to rewrite my bootloader on a PIC32 device. After I disable interrupts, I try to erase 0x1fc00000 with NVMErasePage, but it does not erase, and NVMErasePage return a good status. How can I erase the boot flash from code?
Not an expert on these things but, there is a register with a boot flash write protect bit, search the PIC32Mxxx/2xx data sheet for this.
DEVCFG0: DEVICE CONFIGURATION WORD 0
Check that out.
I have a CE 6.0 project on a PXA310 where I need to be able to download OS updates (nk.bin) via Wi-Fi and safely flash the new OS to my device. I'm open to other suggestions about how to do this, but I'm considering saving the nk.bin to my file system in NAND flash, then restarting and have the bootloader locate the file in the file system and flash it to the BINFS partition. Is this possible, and if so, can you give me an outline of what I'd need to do?
One caveat is that this needs to be very robust since the devices are deployed in the field and are not field serviceable. I need to be sure that if the OS flash fails (due to power failure, etc.) that upon reboot the bootloader can try again. That is why I'd like to store the downloaded image in persistent flash and avoid having to re-download the image.
Technically just about anything is possible. For this strategy what you would need is code for your bootloader to mount the NAND flash as a drive and have a FAT driver so that it can traverse that file system and find the image. That is a lot of work if you don't already have it.
THe other option is to just store it in flash outside of the file system in a known address location. That's a lot easier from the bootloader perspective as all you have to do is map to the address and copy. Of course it makes the writes more challenging because then you're doing it from the OS and you have to disable any other flash accesses completely while you do your write to prevent corruption by two threads sending flash commands to the chip at the same time.
In either case, if you have the space it's a good idea to store a "known-good" image elsewhere too, so that if the new image has a problem (fails a checksum or x number of load attempts fails) then you have a working OS that the bootloader can fall back to.
Clearly a lot depends on your hardware setup, but we've done this without making the Bootloader support the Flash Filesystem.
In our product, the OS image is loaded from Flash to execute from RAM -- I think most WinCE devices work this way nowadays. So to update the OS we use a special Flash driver which lets an application, running under WinCE, update the OS blocks in the Flash -- then all you need is a hard reboot and the Bootloader loads the new flash image into RAM in order to execute it. We've found this pretty reliable in the field (with some not-very-technical end-users!).
A special Flash driver was needed because the MS Flash Filesystem drivers have no access to the OS image sectors of the Flash, in order to prevent trashing the OS by accident.
You do need to load the NK.BIN into some memory which the OS programming application can read, normally the NAND Flash, but if you had enough RAM it could just go into the root of the filestore. However either way you can delete it when you've finished programming the OS sectors before the reboot so it's only a temporary requirement.