• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 34 subscribers
  • Views 2048 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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 firmware for LM3S3601 for the LM4F232 Eval Board?

Shannon Holland
Prodigy 40 points
Other Parts Discussed in Thread: LM3S811

Hello,

I'm in the process of designing a LM4F board and am wondering if the firmware for the LM3S3601 ICDI from the LM4F232 Eval board is available publicly or not?

I realize I can just add a standard 20 pin jtag header and then use something like the LM3S811 eval kit (I'm using Code Composure Studio on the software side) but given I'm developing a custom board anyway it seems like just adding on board debug support (along with USB power) would keep things simpler. Longer term (this is meant to be a development kit product) having customers not have to get something else in addition for debug seems like a good thing...

Or, for this level of support, am I just better off using the FTDI chip? As far as Code composer studio features would this be equivalent?

Thanks for your help!

Shannon 

  • 0
    Guru 117855 points

    Surely this reporter will be, "Banned in Boston" for this - Digi-Key reports near zero stock (2 pcs) - and rather large "minimum quantity" order requirement as well!

    In running small biz. - always wise to insure source security.  Note that your alternative device/chip is readily available...

    Unfortunately "launch pad" for such older parts not too likely - Caveat Emptor...

    *** And - after closer inspection now note that 3500 are ensconced in, "factory stock!"  And - you can buy in relaxed (smaller) quantities - "if" factory truly does release these devices to disty.  (perhaps - word to the wise...)

  • 0
    TI__Genius 10650 points

    Shannon,

    The firmware for the 3601-based ICDI is not publicly available, so the FTDI solution is the only one you have.  You can upload the EEPROM contents from any of our evaluation boards and program it into your custom solution.  You could also just, as you said, purchase a 811 EVM or a XDS100.

    Eric

  • 0
    TI__Genius 17225 points

    We do not currently release the firmware for the LM3S3601.  Likewise we do not release the firmware for the ICDI on the LM4F120H5QR on the Stellaris LaunchPad.

    At the moment the FTDI solution is more widely supported particularly by openOCD.  The LM3S3601 on the EK-LM4F232 uses a form of GDB remote serial protocol over a USB Bulk transport layer.  The same solution is also found on the new Stellaris LaunchPad.  openOCD is working to integrate support for Stellaris LaunchPad which would also then work on EK-LM4F232 since to a host they appear identical.  All of the commercial IDE's that StellarisWare is offered for fully support both our FTDI solution and the Stellaris based ICDI.

    My memory is that at the time we released the EK-LM4F232 kit we intentionally created an LM3S3601 part number to be a ICDI only part for our use.  It may not be orderable to the general public.  The Stellaris LaunchPad has revised that decision and uses an LM4F120H5QR for both the target and the ICDI. This is a standard part. The LM4F family is in preview status at the moment. Talking to TI sales you should be able to get samples and more details on availability.

    I hope this helps in your decision making process.

    Dexter

  • 0 in reply to Stellaris Dexter
    Prodigy 40 points

    Thank you Eric and Dexter!

    Sounds like FTDI is the way to go for now - particularly since it's supported by both OpenOCD and the commericial tools. Perhaps later as the LM4F120H5QR becomes available that will make sense as well.

    Thanks again!

    Shannon

  • 0 in reply to Shannon Holland
    Prodigy 40 points

    Hmm, so I have another question here. Before adding the FTDI part to my design I thought I would verify that the ICDI board from my old EK-LM3S9B92-B dev kit would work with the LM4F232H5QD Eval board.

    As a sanity check I first created a new factorial test project (using the latest version of the Sourcery IDE) targeted at the  EK-LM3S9B92-B dev board - this worked without errors.

    I then created the same factorial test project targeted at the LM4F232H5QD eval board, powered it from USB OTG and connected the ICDI board to the JTAG connector on the LM4F232H5QD board. It seems in this case that the debugger is unhappy with the CPU ID as here is the error log:

    arm-stellaris-eabi-sprite: error: E100. Connect: Invalid Cortex-M3 CPUID. Expected 410FC230, got 410FC241

    arm-stellaris-eabi-sprite: waiting for GDB connection, to pass error along
    warning: unrecognized item "timeout" in "qSupported" response
    Ignoring packet error, continuing...
    Ignoring packet error, continuing...

    I've verified in the target debug settings that the board is the ekc-lm4f232 so I'm not sure why the debugger is looking for a M3 CPU? Is there some other settings change I need to make here? Or perhaps the Codesourcery tools do not support debugging an LM4F target over ftdi?

    As an alternative solution, should I be able to use the LM3S3601 ICDI on the LM4F232H5QD eval board to debug another LM4F board using the supplied JTAG header (assuming the on board LM4F is not powered).

    Thanks for any help!

    Shannon

  • 0 in reply to Shannon Holland
    Guru 117855 points

    Shannon Holland said:
    (assuming the on board LM4F is not powered

    Sometimes our wish proves less than ideal...  And how do you plan to "depower" the onboard LX4F while you power the LM3S601?  (You really don't want to "slice up" this relatively expensive board)  Further - if you do succeed in depowering the LX4F - how do you prevent damage to this MCU when other LX4F pins receive signals?  (The JTAG signals which you plan to "output" from the 10 pin "mini-header" of course route directly to the LX4F - thus any such depowering of the LX4F may prove destructive when the LM3S601 drives those unaltered signal paths)

    TI is on record - this forum - advising against using these current "4F" Eval Boards as JTAG Output probes...  (search function - upper left this page should confirm)

    Should note that our paid IAR finds both LX4F232 and our smaller LX4F231 - without issue/problem.   (LX is part marking till vendor officially qualifies the device)

  • 0 in reply to Shannon Holland
    TI__Genius 17225 points

    The LM3S3601 on the EK-LM4F232 was not intended to do debug out as you would like.

    The ICDI on the launchpad which is identical from the PC's perspective can do this.  See the wiki page http://processors.wiki.ti.com/index.php/Stellaris_LM4F120_LaunchPad_Debug_How_To.  There is a jumper to de-power the target chip and leave the ICDI chip powered.

    The e-store wait for the LaunchPad is several weeks.  However, Digikey and mouser have them in stock but not at the fully discounted price.  Search for EK-LM4F120XL as the part number.

    Dexter

  • 0 in reply to Stellaris Dexter
    Guru 117855 points

    Stellaris Dexter said:
    a jumper to de-power the target chip and leave the ICDI chip powered.

    Suspect the on board LX4F is what is meant here by, "target."  Have not seen this board's schematic - but should the LX4F "really" be de-powered the user must insure that no other signals/voltages appear at any of the LX4F's pins!  (driving any MCU's pins - while MCU is not under proper bias - usually proves harmful)

    Rather than "de-power" - it may be that this on-board LX4F has its Reset pin held in reset - thus the borrowing of JTAG signals - originally intended for that LX4F may be routed elsewhere - and any/all "errant" signals/voltages which may arrive @ LX4F will prove harmless...  (provided they are w/in max ratings of MCU)

    Original poster brought up this, "de-power" idea - I have reacted strongly against it and documented my objections...

  • 0 in reply to cb1_mobile
    TI__Genius 17225 points

    Yes, the on-board LM4F target is de-powered. Thank you for the clarification.

    The current LM4F family has been designed with increased robustness in the GPIO pads.  Applying 0-3.3V logic level signals (JTAG to the external part in this case) to the GPIO pins of an un-powered device will not harm the un-powered device.

    Dexter

  • 0 in reply to Stellaris Dexter
    Prodigy 40 points

    Yes, the point on de-powering the LM4F cpu is a good one - at the time I had forgotten that the ICDI/OTG power jumper also controlled the power source to the ICDI circuit. There is a sense resistor that could be removed to disable power to the LM4F. Good to know that that part won't be damaged in that configuration!

    Even better to know that the Launchpad was designed with this in mind and is available via distributors! I had ordered one several weeks ago from TI but it still looks to be a few weeks out - will get one short term from digikey.

    Thank you everyone for the help!

    Shannon

  • 0 in reply to Shannon Holland
    Prodigy 30 points

    Probably late to the party but there is an excellent open source debugging solution in the "Blackmagic Debug Probe" from Blacksphere Technologies in New Zealand. The repo for the source is here:  https://github.com/gsmcmullin/blackmagic and you can probably port it to the Stellaris equivalent Cortex M3 for an on board program/debug capability. I'm using one of these with my EKS-LM4F232 and it totally rocks. 

  • 0 in reply to Shannon Holland
    Prodigy 180 points

    Hi Shannon,

    How did you get rid of 'Connect: Invalid Cortex-M3 CPUID. Expected 410FC230, got 410FC241' Error?