Hey All,
I'm looking at implementing a boot loader in to project. The communication interfaces that i will be using are RS-485 and Ethernet. The specific MCU i'm using is a LPC1788 from NXP. I have looked around forums to find a boot loader that i could use but i have had no luck. If someone could give me example code or point me in the write direction for implementing it this would be much appreciated.
Matt
Hi,
have a look at the NXP Webpage. There is already Stage1-BL Code on a Boot-ROM of the Chip, and an AppNote explains how to write a Stage2 BL.
BR, /th.
This application note explains what you have to do:
www.nxp.com/.../AN10866.pdf
Basically the last things your bootloader does is: - Disable _all_ interrupts - Load the SP-register according to your firmware to boot - Load the PC-register according to your firmware to boot
The last two steps can be coded as follows:
static __asm void BootJump(UInt32 firmwareStartAddress) { LDR SP, [R0] ;Load new stack pointer address LDR PC, [R0, #4] ;Load new program counter address }
After that, your firmware is executed. Make sure to relocate your interrupt vector table as a first step in your firmware before enabling any interrupts! You can do that using CMSIS-function NVIC_SetVectorTable. You can use the linker-symbol __Vectors to get the interrupt vector table base address to calculate the offset that you have to provide to NVIC_SetVectorTable automatically.
HTH!
I cannot provide you with code because our ethernet boot code is to specific to our user application:
But if you want to make ethernet boot loader you need to manage the following items.
1.- Reading and writing data using ethernet port. Many examples are provides in sample code.
2.- You need to learn how to create user applications on kiel project with memory offset so it doesn't overlap your ethernet bootloader.
3.- Creation and interpretation of HEX file, you need to set your project to generate the HEX file for user application. You need to extract the content of HEX file and transfer it with ethernet.
search for "parallel flash format intel hex" in google to understand HEX format.
4.- Using IAP (in application programing) to write the content of your HEX file into flash memory. There is a sample project about how to use IAP.
5.- Jumping from boot loader, once you have downloaded the user application to flash you need to jump to user application, many threads on this forum deal with how to set vector interrupt table and how to jump to user application.
HEX files are not needed.
The program fromelf.exe can convert directly into a binary file.
But is very easy to extract the content of your HEX file and transfer it to flash, and as HEX provide information about memory offset you will know where to write it in flash.
And the bin file is one single block of raw data ready to transfer. You should already know where, because of the settings made in the memory dialog of the project.
Next thing is that you normally don't want to distribute a hex file that requires the boot loader to parse data. The binary data don't have anything needing to be parsed. But are very easy to extend with some fill data so you get <app_bin> + <fill_data> + <app_id> + <app_version> + <crc32>.
Then you can instantly look at a fixed address in the file and see that it is a binary intended for your hardware, and not a random file someone have accidentaly found somewhere. And you can see if it is the same version as currently used or a newer or older version.
And it's possible to compute a CRC32 directly on the file and verify that the file hasn't been corrupted.
The binary file is also half the size (unless you had holes in your flash memory layout) speeding up transfer to device, potentially using over-the-air updates where the traffic costs money.
Points taken,
but my parsing of the HEX file occurs in the window application that uses ethernet to talk to M3 bootloader so what is sent is mostly raw image + memory offset.
Using memory offset in the HEX file means that M3 bootloader (and windows application talking to it) doesn't need to know what is the setting of your keil user application project.
Of course file is verified after writing, HEX file also includes checksum.
Thanks for getting back to me so quick. I wont be able to implement the ideas yet, the board is still in the development stages. I have some more specific questions about the functionality of the boot loader.
Which UART does the ISP use on the LPC1788 or do you set this is this chosen by the boot loader?
When designing the circuit for the LPC1788. Is there any specific circuitry that i need to add so that the USB and Ethernet can be used to boot load from later on?
Does IAP allow for new firmware to be programed with out reseting the LPC1788?
Thanks in advance
UART0 - by hardware.
I don't understand what you are asking here. Please clarify.
Yes, but this is not recommended. It is better to either physically reset the system or let the watchdog do it for you.
>>>>>>> Does IAP allow for new firmware to be programed with out reseting the LPC1788?
Yes, as long it doesn't overlap the bootloader flash area.
BTW, before writing flash with IAP you need to blank the sector to are going to write, IAP provides functionality for this.
>>>>>> Which UART does the ISP use on the LPC1788 or do you set this is this chosen by the boot loader?
you can use anyone as long you the the UAR correctly.
AFAIK this statement is not correct - see the user manual!
Technically this is true. You can just place the program counter at the beginning of the new firmware. But do you really want to?
What I mean is "AS LONG AS YOU SET YOUR UART CORRECTLY", meaning from the hardware and software side.
the UART is only to transfer data, you can use any UART to do this, has no impact on IAP.
"Technically this is true. You can just place the program counter at the beginning of the new firmware. But do you really want to?"
I'm not too savvy and most likely there are better ways of doing this than the way I do it, but for me setting the vector table and jumping to user application seems to work fine.
"the UART is only to transfer data, you can use any UART to do this, has no impact on IAP."
Yes, but you have to be very clear about the difference between IAP and ISP.
You talk about IAP.
But the OP asked about ISP.
It's the first UART that is hard-coded as ISP interface for the built-in boot loader in the chip.
If the chip is given a secondary boot loader (which requires JTAG or ISP-programming using UART0), then that secondary boot loader can receive data on any UART, CAN, SPI, Ethernet, USB, I2C or whatever interface the processor has. A secondary boot loader can then use IAP to program the chip.
The important distinction here is that if the factory wants to use ISP to program the chip initially, they either needs to use JTAG or (if using FlashMagic with serial port) the UART0 port. Because of this, it's quite useful to consider UART0 as "the" UART to use for software updates.