This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Secondary bootloader queries;

Hi,
I am looking for UART based secondary bootloader for LPC1768.
Please clarify the following queries:
When I am sending binary file from say UART, should I send .bin file or .hex file of the application code?
Should it be interpreted(.bin / .hex) and written to flash ? or should it be written as it is (as generated from IDE) into flash using IAP?

Please Help and guide..!

Thank you ..

Parents
  • As Andrew says you've got to think about what you've got to solve, and how/what you are capable of doing at each end of the connection. If you can write a PC app to send the code, or if you have to use Hyper Terminal or whatever. If you have to use a program built by someone else, the limits of that program (send file, X/Y/Z Modem, etc) will be an important factor.

    Generally, I think binary would be a way of simplifying the micro-controller's job, and post-processing the IDE output into an idealized form. If your boot loader is more like a "monitor" application, loading hex is also workable, but might require some flow control, or buffering, so as not to overflow if the erase/flash is slow. Other protocols for X-Modem, or with ACK/NACK packets can be self paced, and have known buffering requirements.

Reply
  • As Andrew says you've got to think about what you've got to solve, and how/what you are capable of doing at each end of the connection. If you can write a PC app to send the code, or if you have to use Hyper Terminal or whatever. If you have to use a program built by someone else, the limits of that program (send file, X/Y/Z Modem, etc) will be an important factor.

    Generally, I think binary would be a way of simplifying the micro-controller's job, and post-processing the IDE output into an idealized form. If your boot loader is more like a "monitor" application, loading hex is also workable, but might require some flow control, or buffering, so as not to overflow if the erase/flash is slow. Other protocols for X-Modem, or with ACK/NACK packets can be self paced, and have known buffering requirements.

Children
No data