I am using self developed ARM board with
I can download my program into the board
and perform all the things well in the emulator software. When I plug out the
emulator and re-power up my board. It seems no program downloaded to the board
and the board is no response.
Could anyone give me a hand?
Self-developed ARM board, LM3S9B90
Linux UBuntu 11.1
a) switch to TI Flash Programmer for programming purposes - read, comply with instructions and give that a try
b) insure that you have pull-up R's on all 4 JTAG pins (and possibly on PB7 depending on your MCU)
c) set your JTAG programming speeds to lowest settings
d) double check JTAG connections from your connector to the actual MCU pins - insure no pin to pin shorts - routings should be short/direct for JTAG
e) insure that your board power supply can deliver 500mA during the programming condition. (likely overkill - but you need to "start" conservatively)
Dear Mr. cb1_mobile,
Thanks for your suggestions. I have the following comments on it:
a) I tried to install TI LM Flash Programmer, it only support ICTI interface, UART, USB and LAN, it seem do not support JTAG.
b) added four pull up resistor on TMS, TCK, TDO, TDI,. Problem still exist.
c) Problem still exist.
d) confirm no problem. BTW, I can do the emulation during that the ARM M3 was connecting to the emulator. does it means that the pins are correctly connected?
e) I am using LM1117 3.3 regulator from 5V supply. It supports that it can deliver 800mA max.
Sorry for your trouble - fastest/easiest way to get you going is with LM3S811 Eval Board. (50 USD - this is lowest cost) This connects via USB to PC (usually under Windows) and this Eval Board then connects via JTAG to your custom, target board.
Perhaps there is "help" with your emulator (XDS) board? Surprised if it is Debug only - suggest that you find one who has recently used that device - should be great aid. Everything else you report seems fine - once you overcome this issue you should have "clear sailing" - wish you well... (plz tell us your outcome/solution)
Dear Mr. cb1_mobile
Thanks again for your information. Here are my updated situations:
I can download the programme into another M3 board, LM3S2620. The PC, IDE, OS, emulator, power supply and other cables are the same expected that I am now using LM3S2620 instead of LM3S9B90.
I brought an EK-LM3S8962 EVM Kit before and I was able to perform emulation and download program into the ARM.
I also got my own LM3S8962 self developed board. Again, all the things are well in this board.
The only thing I cannot do now is download programme into my self-developed LM3S9B90 board.
Are there any differences between 2620 8962 and 9B90?
Thanks again for your information.
Have no 1st hand experience with any of your 3 chosen Stellaris MCUs - suggest that you go to, "TI Product Selector" and compare each of these. Current Datasheets always should be reviewed - and unfortunately the most recent "errata" for each of your chosen MCUs. Errata is likely to have the most current data - can save you much time/effort.
If all of the above appear normal - suggest that you follow this checklist which has helped us/clients often when bringing up, "newly produced MCU boards:"
a) insure that all JTAG cables, connections are good - measure right to the pins of the MCU. Always use pull-up Rs during check-out/commissioning - "believe/trust" internal JTAG R's presence/effectiveness "only" after you have verified that the new board performs. Check for pin to pin JTAG shorts. Certain MCUs must have PB7 or other NMI interrupt pins pulled up - thus the importance of "reading" your datasheets and errata.
b) Your xtal description in SysCtlClockSet() must match the actual value of the xtal on your board - double check. Too high C value on either xtal bypass can prevent proper operation. (this recently cost a client a week down-time - even after we had "alerted" - part simply "looked good" - they failed to adequately/really "check/measure." Be sure you read, understand and comply with "legal" values for xtal, PLL divide and related set-up values. We like clients to "start" without the PLL - without highest MCU speeds - to eliminate Pll Set-Up/operation as a souce of trouble.
c) use lowest JTAG speeds during check-out/verification - once operational you can increase.
d) insure that you have used sufficient number of closely located bypass C's - required by VDD and VDD2.5/similar. VLDO has critical value C - problems result from too much or too little.
e) should your MCU employ Hibernate - Wake - VBat - again "really" read, understand and comply with data-sheet & errata's handling of each of these critical pins.
f) beware should your MCU contain a "flash resident" bootloader. This usually requires "special programming" - so that you do not "over-write" the bootloader. (meaning that your program must start at a "special" address - normally above the bootloader's location in flash memory)
g) beware GPIO allowed to "float" - "temporary" plug-in of pull-up/down R's @ your board's I/O connector eliminates this issue. We built, always use a standard "test/commissioning" pcb which quickly/easily "plugs-in" to our "BUT" (board under test) - this board then feeds our data logger for more challenging tests - after initial check/verify is passed.
h) we've found it wise to monitor & data-log VDD, VDD2.5, VLDO - especially when you launch your programmer. Drop-out of any of these voltages under program conditions usually indicates some board or set-up code violation. Recent clients mistakenly used a very undersized 3V3 VReg - board start-up and programming demand more current - best to "over-supply" (at least during test/commissioning) and only later "dial down" should size/cost so dictate.
Always advise clients NOT to build just one board - single board problems "eat time/money/effort" - 3 board minimum enables you to A-B test - eliminates "single board" anomalies...
Thanks for your informative comments. I will try it one by one next Monday.
One more question I would like to know, according to the LM3S8962 Evaluation Board, Pin 50 WAKEn is grounded. However, in LM3S9B90 Evaluation Kit, Pin 50 WAKEn is pulled up. In both of the datasheet it wrote:
Pin 50: An external input that brings the processor out of Hibernate mode when asserted.
So I am not sure I should make the pin50 pulled up or down in LM3S9B90.
BTW, I will check out the Pin 51 HIBn to confirm the status of the ARM on Monday.
Thank you again for your help! :)
Normally - if the pin is designated as /Wake it is safest to ground this pin. For flexibility - suggest that you design with a pull up R and an easy means to ground this pin. (shunt/jumper) You do want your MCU to be "awake" during debug and programming modes.
Another critical point - your MCU may contain a bootloader which requires that your program be downloaded to a starting address "other" than 0x00000000. Your MCU datasheet and possibly MCU errata should so guide/specify. (I have back-annotated my earlier post in this series (dated Friday, 18 Nov) to include this item)
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.