Newbie question:
Have generated a .BIN file using two user commands: elfdwt .\Debug\Target.axf fromelf --bin -o .\Output\Target.bin .\Output\Target.axf
Resulting .BIN file has size of 11,848 bytes.
Is it possible to divide these 11,848 by 4,096 (size of one flash sector) and use 'Copy RAM to Flash' three times to overwrite sector 0, 1 and 2 of program flash?
Of course, code doing this is located in f.e. sector 7 (or RAM).
Best regards, Juergen
No, because normally you cannot write more than 256/512 bytes at the time (on the LPC chips I work with).
Ok, I have to erase (and prepare) a whole 4,096 byte sector (sector 0). Then write 16 chunks of 256 byte? Then erase and prepare the next sector (sector 1). Again write 16 chunks of 256 byte. And so on?
Main question is: Is the .BIN file a 1:1 binary copy of program flash?
Yes on all questions.
Thank you very much for your support. Last question so far: If my 'flashing' goes wrong, am I able to get the board to life again using normal USB programming (delete and copy firmware.bin)? Best regards, Juergen
Have you even told us what processor you have?
Sorry, use NXP LPC1343 and KEIL MDK V4.23.
I don't fully understand your question but i'll try. You can always use uv4 to flash your print unless CRP is enabled. programming .bin files can be achieved using a secondary bootloader - which you write and program starting at address 0x0 in internal flash.
Ok, try to explain. Application development is done as normal using uv4, flashing (development) target as normal via uv4 and ulink pro. After tests, software is ready for production use. Now have to update machines using targets with older software. This should be done while target application is running (IAP, In Application Programming). BIN data of new software is transmitted via uart (as uart is the only communication port of the targets in the machines) using an appropriate serial protocol. Uart irq handler is placed in a ROM (or RAM) area which is not been overwritten by software update procedure. After update has completed, target jumps into Reset and the new software should run. So, besides writing software for transmit/receive of the BIN packets, have to use IAP commands, the LPC1343 supplies for flashing the program area with the new software. Many years of programming experience tell me, that this will not work without errors in the first tries. So the question: Am I always able to get the (development) target run again via its USB bootloader mechanism, in case my IAP goes wrong? Best regards, Juergen.
First of, you don't want to "jump" to your reset vector. Use a watchdog reset to start anew, otherwise there is no guarantee that the processor's internal state will be consistent.
So the question: Am I always able to get the (development) target run again via its USB bootloader mechanism, in case my IAP goes wrong?
You should implement a CRC check before starting to program. Consider maintaining a backup of the firmware software in a non-volatile memory section in case of trouble. You can split your bootloader in two: a permanent one that restores the main bootloader (USB enabled, can program itself and firmware) and the firmware itself or jumps to the firmware's entry point if the system is ready to startup.
This tool will probably be of help while testing/developing:
http://www.flashmagictool.com/