Code changes required for custom board

Hi Glenn

Typically only CCS update should be OK. Please do make note of the following

1. CCS support for XDS200 with TIVA. Do check that in the CCS Menu and the following links

http://processors.wiki.ti.com/index.php/XDS200

As an additional safety, I would test XDS200 on the Prototype Platform before doing it on the Custom Platform.

2. The crystal that is there on the Dev Board is same as the one on your custom board. This is essential if you are using the PLL from the external crystal to generate a System Clock

3. The JTAG connections are clean for TIVA C MCU and the are as per the XDS connection guidelines

http://processors.wiki.ti.com/index.php/XDS_Target_Connection_Guide

On the TI-RTOS front, I am not sure as to what board files need to be edited. You may have to do some serious search into the files, application notes/guides and the forum and how they relate to the LaunchPad.

Amit

Hi Amit,

Thanks for your quick and helpful response!

I will be using the XDS200 with CCS for debugging my custom board.

For the factory to flash the Tiva C with my code. What do you recommend?

Can I use the XDS200 with LM Flash Programmer?

Are there any other options available? I know about Segger J-Link and J-Flash. But that programmer is twice the cost of the XDS200.

Glenn.

Hello Glenn

XDS200 may not work with LMFlashProgrammer. If you open the LMFlashProgrammer application then on the Configuration Tab, the Interface section lists what interfaces can be used.

May I ask why at the factory flashing of TIVA-C cannot be handled by XDS200.

Amit

Hi Amit,

I am assuming that the only way I can use the XDS200 is with CCS (If LM Flash is not viable). This would mean I would need to send my code to the factory (which I would not want to be doing). And the factory would also require licenses for CCS.

So how do I go about programming my board in a factory production line?

Glenn.

Glenn Vassallo said:

I know about Segger J-Link and J-Flash. But that programmer is twice the cost of the XDS200.

Might that cost differential exist for good reason? 

You may benefit from reviewing recent posts from Petrei (and others) lamenting the "robustness" of the "discount methods" you propose.  Acquisition cost alone may not best (nor fully) serve your long-term financial interests.

And - should your project succeed - does not the ability to program multiple boards - via the simple, "parallel strapping" of the 2 SWD signal lines - deserve some consideration?  System you propose may, "close the door" to this more efficient, faster & more robust method.  (Vendor's Sue Cozart produced a, "white paper" outlining the advantages of SWD over JTAG - again acquisition cost alone may prove sub-optimal...)

Hi cb1_mobile,

Thanks, this is all new information for me. I will definitely be looking into SWD....the goal is to be in a position where fast multiple programmers are required to keep up with the demand. 

My board has been designed for JTAG, actually I am using a Tag-Connect for programming (http://www.tag-connect.com/). Do I need to consider SWD in my board design, or will it work with my existing JTAG setup, by using a different programmer?

I am surprised that my method is considered the discount method, the XDS200 is a midrange programmer and is the one recommended for the Tiva C by TI. The XDS100 is the discount model, and I have seen enough to tell it would be too slow for my requirements.

Glenn.

p.s. I couldn't find the post you were talking about, unless it was this one - http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/310997.aspx?pi297168=1

Sue's white paper far pre-dated the rebrand arrival - you may find it via a Google search of SWD.  (I don't have it readily available, now)

I'd really review the benefits of SWD - and "serious" methods of programming - as opposed to, "acquisition cost dominant" which was your opening gambit.

And - as always - you further lock yourself into a single vendor solution.  Best feature set, price, availability & well announced/executed "wind-down" may not always result...

Indeed, I am TI throughout, this has worked well so far, well except for the CC3000, but that's for another forum and support group to worry about.

And yes, I am using CCS, as I am using TI-RTOS. CCS does provide support for Segger, but only beta drivers are available, which lack full feature set. So for debug, I really need to use XDS debuggers. For programming at the factory, this is still to be determined. 

One thing you need to keep in mind about some us in this forum....Is that some of us are self funded entrepreneurs, and just one person, working on one product. Quite different to your large multi-national team working on numerous products. Compromises and decisions that result in quick development times and simplicity are required under my conditions. And this often means going with a single vendor tool chain.

Who knows, if I am successful, the future may present the "luxuries" you see as "the right choices".

And as always, I appreciate your feedback and opinion!

Glenn.

Don't believe that any claim of, "large, multi-national team -> numerous products" fairly reveals.  Our reach is necessarily global - long, close/select contact w/in business, finance & design/development is demanded for leverage - does not register as large.

In fact - it is some of our far larger clients who demand that we harvest our tech "bits/pieces" from multiple sources - thus raising the odds that adequate review & considerations have been made - and that results meet specification & are predictable. 

It is from that basis that I offer comment for you & others...