Using LM Flash Programmer Utility to program LM4F232 devices

sherwin tiongson said:

I was able to send and receive strings from PC to the microcontroller

Kindly explain "how" you accomplished this - specifically how did you get your code into your M4F MCU to send/receive strings?  Would serve us both to read/review MCU datasheet (new one recently released) - believe that a flash loader is resident in this MCU's ROM - saving you from its unwanted erasure and in theory - simplifying your task.  Had you earlier programmed your MCU via JTAG?  (so that it could send/receive the strings you mention)

Hi cb1_mobile,

Good morning!!

Thanks for you reply!!..

I see where you coming from. What I did to verify the uart connection is I run a seperate code (not the hello world sample code) that I've written before, in this code I used uart to RS232 connection to send/received strings/data to a hyperterminal or a putty to act as my console. I also tried to run an example program called uart_echo and it works perfect. So with this two codes running and behaving what I expect them to do, I think this really guarantee that my uart to RS232 HW connection works perfectly. I did used CCS to load these programs into the LM4F device via USB(In-circuit debug interface) not with UART or JTAG.

On the other hand I've used the hello world sample program to investigate on how to load my code to the LM4 devices without using CCS. I've choose the hello world sample program basically  to make sure that its the most basic program and this would minimized variables in my set-up.

Cheers,

Sherwin Tiongson

sherwin tiongson said:

I did used CCS to load these programs into the LM4F device via USB

Hi Sherwin - bet you that in the process above - you DID use JTAG to program your 4F MCU!  (a small Stellaris 3Sxxxx resides on the flip side of your 4F Eval board - and it "talks" JTAG to your 4F MCU.  That solves that "initial programming" mystery.

Now your M4F Stellaris MCU contains a ROM and w/in that ROM resides the Stellaris Boot Loader and vector table.  Here's a direct quote from my 64 pin M4F datasheet: "The boot loader is used as an initial program loader (when the Flash memory is empty) as well as an application-initiated firmware upgrade mechanism (by calling back to the boot loader)."

The Stellaris® ROM User’s Guide will help you gain understanding - attention to detail and sequence of your actions is important.  In a nutshell - upon reset you can direct the MCU to execute the ROM Boot Loader or your application programmed w/in Flash - through the use of a pre-arranged GPIO signal.  You need to read (then re-read) "Boot Loader Overview" w/in your MCU datasheet (there is brand new one) and the separate ROM User's Guide.  (suggest that you "not" read either if you are at all tired...)  Good luck...

.

thanks cb1_mobile,

that is a great help.. I did try to read LM4f232 datasheet and the Bootloader guide and it's now much clearer to me, I must say that the Boot Loader documentation on LM4f232 datasheet needs to be re-read multiple times because the sentences are badly arrange. :)  Thanks for the heads up!

Thanks,

Sherwin

Thank you - suspect that much of the tech datasheet/manual was written by engineers/programmers who "really know" - and often generalize their understanding & experience in a way not fully suitable for the less skilled and/or practiced.  TI is in "no way" unique in this characteristic.

LMI (and TI subsequently) make this point about their neat Eval Kits, "tested/verified by inexperienced persons - to insure both kit & written description are adequate."  What you/I/other users have noted is that this neat technique may not fully/properly extend to complex descriptions w/in MCU datasheets.  Those "so close" to the action typically fail to recognize or appreciate the natural questions/issues raised - by even the slightest inexactness of description.  Even at 1400+ pages - still more detail is needed in highly complex areas...

Proof of this assertion - count the number of forum requests for Bootloader issues - IMHO an, "Airplane Pilot Sequential Check-List" - greatly detailed - is required.  Few seem to quickly & completely, "get it."  And "this reporter" is - and remains - among this group...

Indeed, I find myself hacking away at datasheets, rom bootloader guides and of course the forum.  To make matters worse, some responses from TI engineers seem austere in the way that don't get to the bottom of the issue in a holistic and simple way, and refer users to datasheets and documentation for "additional information".  I don't know if they realize they cause additional frustration with these sort of responses and I hope things improve.

Wow - this is an old thread to be posting to! I'm sorry you find some of the information here less than completely helpful. Please be assured, though, that if you ask for clarification, we try to do our best to help out. We also make a point of updating documentation based on forum input so please do let us know if you feel something in a PDF isn't clear or complete.

Dave Wilson said:

make a point of updating documentation based on forum input so please do let us know if you feel something in a PDF isn't clear or complete.

Might the unending stream of users falling afoul of PD7 and/or PF0 - which default into dreaded NMI state - fly bit in the face of, "make a point of updating...?"  Of course - none of this your fault.

This reporter/others have long, "begged for mercy" in this particular, NMI default regard.  And - facts in evidence fail to reveal the long suggested use of, "More numerous and greater warnings/emphasis" to this (oft unwanted) NMI default behavior.

While the thread is old - sentiments expressed remain - in most cases - uncomfortably valid...

Let me add a caveat. The software development people monitoring the forum can and should update TivaWare documentation any time they see a case where an explanation needs expanded or clarified. We also send feedback to the folks who work on the datasheets when we see deficiencies there but we don't have direct access to the source for those documents.

On the question of PD7/PF0/NMI, I hate to admit it but I don't know about this issue. Looking at the TM4C129 part I'm playing with today, I see PD7 apparently defaults to GPIO. I would be happy to look into adding any missing information if you can let me know what the problem is. Actually, I may just go and search the forum to see if I can find references to this :-)

Dave Wilson said:

I may just go and search the forum to see if I can find references to this :-)

Really?  I'd stand far from the, "field of fire" if you open that forum search door.  (i.e. PF0 and/or PD7 don't work!)  This issue usually evidences when users try to harvest peripherals which are drawn from pin clusters containing either NMI pin. 

I have personally addressed this issue 20+ times - new TI arrival Amit & outsider Kel have subsequently assumed that workload.  I've, "pleaded" for better emphasis multiple times...  Warnings are present (twice iirc w/in MCU manuals) yet imho - should be bit better promoted!  (i.e. moved from, "cheap seats.") ... (in one post I dared to suggest that bit of the "left over, "This part NRND" red ink - be better (or additionally) employed to alert to NMI's "grab" of PF0/PD7...)

I found many pleadings and see what I think the problem is. I assume you want us to add a table in the datasheet that explicitly lists the GPIO pins which default to locked state (i.e. all the JTAG and NMI-capable pins)? I'll ask the tech writers about this and make sure that the affected GPIO functions in DriverLib are updated to tell people to beware that some pins must be unlocked before they can be configured and to point readers to the gpio_jtag example for information on how to do this.

I can't really list explicit pins in the DriverLib documentation because these could change from part to part but hopefully that will make things a bit clearer. Let me know if this is what you are looking for or if there are more changes you reckon are needed.

Our posts near crossed - (reread of one up likely helps).

Believe that for Gov't work - stronger (i.e. more numerous and bolder) mention of NMI default beharior upon PF0 & PD7 - warrants consideration.  May even justify, "Page ONE" mention - along w/JTAG pin caution.  Again - the current, "alert/warning methods" are (to be kind) a rather notable failure.  (and have been so for quite some time...)

When & should NMI pins change (my belief: PF0 & PD7 currently dominate) that fact can be reflected w/in the pertinent MCU data manual.

Yes - those warnings are present in multiple as things stand now.   But - hundreds have fallen victim - which signals that some, slight rethink (i.e. more numerous, promotion to Page ONE, and possibly red ink (boldness) may be in order...   Repetition deliberate - as less direct methods have failed to, "turn this, "locked course" ship."

Dave Wilson said:

hate to admit it but I don't know about this issue

Swear to God - had nothing whatsoever to do w/today's post, "Struggling to make GPIO work!"

 http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/316511.aspx

As we outsiders regularly encounter - seems likely that "cure" is deliberately avoided - surely someone offical (bit caring) should have "flagged" - and better highlighted - as long - and multiple times - past suggested...

You'll be delighted to hear that I spent 10 minutes with the writer responsible for the datasheets yesterday and there will be changes. One of the GPIO chapters is being updated to include all pins which have to be handled differently from the default (where the default is a pin which has no lock and comes out of reset configured as a GPIO input). Although that information is already there, I think having it in tabular form will make things a fair bit clearer.

I've also added a block of warning text regarding JTAG and NMI pins and the locking mechanism to the top of the GPIO chapter in the DriverLib User's Manual and in the API reference for every affected call. This also references the gpio_jtag example application. Hopefully this will do the trick. Let me know if you have any other suggestions after you see the results.

I don't know when the updated datasheets will next be released but the software with updated documentation should hit the streets in 3 or 4 weeks.

Don't know that my delight is of high importance - myself/others here should - and do - "feel the pain" of the hundreds who've long "fallen victim" to this technical detail.  It is normal/customary for one to "expect" a (usually unmarked/unnoted pin - as shown in the MCU pin-out graphic) to behave, "as normal" - is it not?

Now you/I/experienced others have been past, "burned enough" to have learned the value of good read/review of data sheets.  But not all here!

My "prevent view" differs from yours.  I suggest asterisk and/or "coloration" to make each/every such special pin better stand out!  And - I believe the pin-out MCU drawing should be an obvious place to so highlight.  The use of GPIO chapter - as is presently done - even w/tabulation - has long proven insufficient.  (I do appreciate your effort & it is an improvement - but I doubt that it is as impactful as stronger methods I've/others have suggested)

I'd place such "key pin warnings" front/center Page 1 (Mgmt will love that, I realize) and upon each/every pinout drawing - as well as the method you describe. 

Your interest and involvement is - as always - appreciated...  Some here have "visited" for awhile - and hate to see users endlessly "set adrift" - when safe harbors exist and could be far better marked... (especially when such harbor markings bear "NIH" and "free"...)  Here (non-NIH) - quite simply - has not yet proved, "up to task..."

To best illustrate: (cb1) (this works even for those who studiously avoid "reading the fine manual") QED! 

Note - minus those highlighted "warnings" users too easily, "fall victim" to the NMI & JTAG usage issues...  As now exists - all pins look "up for grabs" - we can - and should - do better... (even if beyond "10 minutes" is required...)

Pins highlighted require, "Special Handling" - please review GPIO Chapter for important details... (credit cb1)

I have  the same problem, but with RDK-IDM-L35 - Stellaris board.

I wrote  somewhere, boot loader there is in flash memory from 0x000 to 0x800

and sometimes Somebody can erase it.

I do not knew that bootloader there is in ROM memory.

The best regards

Andrzej M.

P.S.    

 STM32 ST-LINK Utility  loaded  ER_CONFIG.HEX,  ER_FLASH.HEX

 and  Tinybooter.hex  in STM32F429ZI-DISCOVERY and afterwards  I can load

the program bin in hex.

The best regards

Andrzej M.