This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

ICDI interface as boot loader

Hi community,

we are going to prepare the transition to a new processor - LM4F232. So you can expect some questions from a fledgeling here.

Yesterday I got the eval board EKS-LM4F232, connected it onto a PC's USB port and everything worked well. Better as expected or let's say: I do not know why :-) Even I cleared the whole flash, the device was capable to take the pre-saved .bin file via the ICDI interface back and has programmed it correctly into it's flash. Wow!

Were is the flash burner code located?

Ok, let's assume it is part of the library or start-up code residing in ROM. I've read that after power-on the start-up code is checking some conditions it discovers on beginning of flash and, if it seems to be a valid image, it will start it. Otherwise it branches to listen for download.

But, if I produce a corrupt image which is formally correct and download it into flash with the LM Flash Programmer - do I get into trouble?

I do not want to try it out because I'm afraid to saw the last bough I'm sitting on.

Maybe this is a basic debug concept of ARM/ICDI but I still not got it. In the e2e-forum I read something like "The LM3S3601 on the EK-LM4F232 uses a form of GDB remote serial protocol over a USB Bulk transport layer." In another thread I learned that the firmware for the LM3S3601 is not publicly available.

Our final custom board will not contain these ICDI chip. With a native JTAG emulator I can imagine to stream some data into the processor's internal RAM but I need it finally in Flash.

Thanks for any explanations.

Btw, where to get a 10-pin Stellaris debug plug adapter to standard 14-pin JTAG connector?