Cortex-M3 Bootloader

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.

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.

Hey All,

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

Which UART does the ISP use on the LPC1788 or do you set this is this chosen by the boot loader?

UART0 - by hardware.

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?

I don't understand what you are asking here. Please clarify.

Does IAP allow for new firmware to be programed with out reseting the LPC1788?

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.

you can use anyone as long you the the UAR correctly.

AFAIK this statement is not correct - see the user manual!

Yes, as long it doesn't overlap the bootloader flash area.

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.