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.

TM4C123GH6PM ICDI micro

Other Parts Discussed in Thread: CCSTUDIO, EK-TM4C123GXL

Hi all,

I was trying to update a CC3000EM with a tiva-c tm4c launchpad using the "PatchProgrammer" with LMFlash but something goes wrong and now seems that I 've flashed the ICDI micro (the other tm4c used for debug) and now I can not see any device when plugging the usb cable.

Is there a way to flash again the ICDI micro with a JTAG or something else to get the launchpad working ?

There is a ICDI JTAG (TC2050-IDC-NL) port , could I use this , where can I find the firmware ?

Thanks

ALessio 

  •  Alessio, the ICDI TIVA has no JTAG connected, this sound as you activated USB bootloader on first chip, this sound as very strange, if so I fear no image of ICDI is available due I suppose some sort of board protection is on this provcessor, remember CCSTudio is code locked and I see this as the locking key.

     This moment I am far from lab and I cannot try but If you own another TM4C and an external ICDI or JTAG programmer try connect jtag and read back code from this processor, may be as for MSP series it is unlocked and readable too.

     

  • Alessio,

      We've had a few reports of people accidentally reflashing their ICDI and I'm working on methods to (a) prevent this from happening in future and (b) ways for people to recover if they do this. It would help me enormously if you could post a detailed list of exactly what you did to get into this situation. The only way I know to incorrectly flash the ICDI instead of the main MCU involves using the dfuprog tool to manually switch the mode of the ICDI and this isn't something you are likely to do by mistake.

      It is possible to recover the ICDI using JTAG to reprogram it but you need a special cable that connects to the 10 pads on the bottom of the board. It may also be possible to recover it via USB depending upon how the image got corrupted in the first place. When you plug in your ICDI connection, do you see any device appear in Device Manager? If so, I may be able to help. If you see nothing then likely you've flashed a bad image to the ICDI and it's crashing after starting up. If that's the case, only JTAG can update it.

  • Hi all,

    thanks for the reply, I think the ICDI firmware is crashing after starting up because when I plug the usb cable I cannot see any device.

    Anyway ... let  assume that I can use JTAG , where can I found pin out and firmware for the ICDI interface ?

    However I just use TI tools to crash it, I was trying to update CC3000 firmware and I am not sure that it was necessary.

    Thanks

    Alessio 

  • Alessio,

      I had a chat with some of the people in our support group and I'm afraid you're not going to like the answer. Although it is possible to update the ICDI firmware using JTAG, we are not presently releasing the firmware binary to do this. The cost of buying the JTAG connector needed and the effort required to get this up and running would cost so much more than just replacing the LaunchPad that our suggestion is just to consider the LaunchPad destroyed and replace it.

      That said, I'm still very interested to find out what could cause the ICDI to get corrupted in the first place. Could you let me know exactly which tool you ran on it that caused the problem in the first place? Ideally, if you have the URL you downloaded it from and a list of what you did with it, I can try the same thing here and see what happens.

  • Seems that your access to - and use of - that proprietary firmware binary would quickly (maybe easily) restore poster's board.  (assumes that he ships it to Dave W's attention)

    That "carrot" may induce the (detailed) cooperation you (properly {imho}) have twice now requested...

  • Dave,

    thanks for the reply, you are right .... "The cost of buying the JTAG connector needed and the effort required to get this up and running would cost so much more than just replacing the LaunchPad" .... but if it happen again with a dk-tm4c123g that costs much more than a launchpad? 

    By the way I have a em-cc3000 and I would like to use with the ek-tm4c123gxl I try to follow the instructions given in http://processors.wiki.ti.com/index.php/CC3000_Patch_Programmer 

    Since I develop in a Linux environment I first try the linux way but the source code in Cortex-M4-PatchLM4F232H5QD-4_11_7_13_19-linux-installer.run package won't compile in ccs 5.5 so I try the windowz way I install stellaris_ftdi-2 + stellaris_icdi_drivers + LM Flash Programmer build 1588 and finally PatchProgrammerLM4F232H5QD_4_11_7_14_24windows_installer.exe wich include PatchProgrammer.bin then I try to flash it with LM FLash with no success, then I try to update ICDI firmrware from LM flash (Other Utilities tab)  and (If I remember well) seems to do something but do not complete the update and then the launchpad is  dead.

    I was using LM Flash with TM4C123G in the quick set configuration

    Alessio

     

     

     

     

  • Alessio,

      No doubt you are correct. If we start seeing reports of ICDI problems on dk-tm4c123 or dk-tm4c129 boards I suspect there will be an incentive to come up with some kind of solution even if it involves users having to find special JTAG cables.

      Regarding the CC3000 patch programmer, I'm afraid that code was developed by the CC3000 folks and we (Tiva software development here in Austin) know next to nothing about it. Interestingly, I've been working on getting CC3000 support added to TivaWare this week so no doubt I'll be looking into this stuff very soon. If and when I find anything, I'll update the post.

  • Hi Dave,

    Glad to hear that TI is going to add support for CC3000 to TivaWare. I'd like to note one thing in that regard

    The CC3000 host driver uses some AES encryption so the source code incorporates forward and reverse sbox tables [of 256 byte each].

    Meanwhile certain MCU types (e.g. of the Blizzard family) has exactly the same tables in ROM. So it'll be a good idea to remove that tables from the driver code and use the ROM tables instead. Doing so will save 512 bytes in the Flash memory.

    That's what I did in my project. During that effort I did noticed that the ROM AES tables are not referred in TivaWare at all. There are no defines to facilitate compile-time mapping, no data type definitions, etc.

    It's not a big deal as the tables are documented in the ROM library user's manual. It just a matter of convenience. So it'll be nice to see support for that tables in future versions of TivaWare.

    ---

    regards,

        Igor

  • Thanks for this information, Igor. I'll look out for those tables and see what I can do when I get to that part of the porting.