• State Resolved
  • Locked Locked
  • Replies 14 replies
  • Subscribers 29 subscribers
  • Views 2535 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.

Tivaware TM4C (Pin_map.h) missing analog comparator pins.

Genatco
Guru 55913 points
Other Parts Discussed in Thread: LM3S8971, STRIKE, EK-TM4C1294XL

PinMux utility 1.0.4 creates and saves the Ports Pins configuration similar to listing below however there are no mappings for the comparator pins created in the (pin_map.h) file.

 

  • 0
    Guru 117855 points

    Mon ami - had you tried the (far earlier) Analog Comparator code I past, directly, supplied you?

    While your "new, BP authored" GPIOPinConfigs() are "inventive" - might these MCU, "Analog Comparator" pins not require such treatment?  (confirmed by their absence - as you so note - your pin_map.h file)

    Presented below are the set-up/config codes employed (w/success) past 2+ years w/"nrnd" blessed LX4F device.  (such code blurb passed your way - months past)

            ROM_ComparatorConfigure(COMP_BASE, 0, (COMP_TRIG_NONE |
                                    COMP_ASRCP_PIN0 | COMP_OUTPUT_NORMAL));
     
            ROM_GPIOPinConfigure(GPIO_PF0_C0O); //  Comp Output  *** we did not even "rescue" from NMI default!

            ROM_GPIOPinTypeComparator(GPIO_PORTC_BASE, GPIO_PIN_6 | GPIO_PIN_7);  // that's it, baby!

    Seeing your post - I "dialed up" our long past code - this is it!  (but always watch - magician's, "off-hand!")

    Appears that your "four" GPIOPinTypeComparator() calls were accepted - and those "near" duplicate the past code I supplied you directly.  You'll note that such, "GPIOPinType()" calls accept multiple parameters.   You've used just one, repeatedly - forcing you into those four, (3 unnecessary) separate, PinType calls!  As a "lone ranger" type/style operator - efficiently husbanding your time/effort should be welcome - and achieved via this comment/observation...  (further - use of the single Pintype() call is far easier to read/review downstream - when memory dims - and you review the code for tweaks, what ifs, etc...)

    Your, "merci beaucoup" via famed, Verify - as always (& often) gratefully accepted...

  • 0 in reply to cb1_mobile
    Guru 55913 points

    Tried earlier to remove the +/-  though these pins belong to the analog comparator peripheral assigned AFSEL GPIO inputs. That Pin format was spit out by the PinMux utility in (pins.h). Wild pin address mappings in this area not investigate how difficult to fix (pin.map) or merely make additions to it. 

    The analog comparator inputs should be part of the library either way as it configured the outputs with out compaint. Just noticed Tivaware is missing GPIOPinIntClear() leaving only GPIOIntClear() to clear the entire port interrupt. However attempts to add a (uiInt32) amendment much as article 2 of the constitution would turn read upon threats such lines be left out have burned like a banner flag in a lost war.

  • 0 in reply to cb1_mobile
    Guru 117855 points

    cb1_mobile said:
    Mon ami - had you tried the (far earlier) Analog Comparator code I past, directly, supplied you?

    That code works to perfection - both our original LX4F (may they rest in peace) - & newer, equiv. TM4C...

  • 0 in reply to cb1_mobile
    Guru 55913 points

    Will give (doc) a look over this weekend.  Finding (eth_client.c) not taking kindly UDP 23 (Telnet motor port) frolicking its robust functions around the TCP 80 war zone. 

    Many things learned during Cisco router & switch days has made possible such efforts. Blended well never shaken serial partners of CSMCSDA, tossing 7 network layers far easier than many a pizza parlor chef hands full of dough.

    Many Kudos go to TI staff engineers for the excellent work done, Boot Loader and (Lwip.c) TCP war zone!

  • 0 in reply to Genatco
    Guru 117855 points

    BP101 said:
    Will give (doc) a look over this weekend.

    That (doc) is 90% present in my brief cut/paste w/in this thread.  You used 4 calls for "PinType()" - you can eliminate three of them.  And escape those nasty errors in that process.  (and award {finally} the well earned Verify by your sole responder...)

    Little progress on your BLDC noted - "focus" shifted again - "stick to knitting" seems rejected/over-rated...

    Note your (long forgotten subject) "Pin Map.h missing Analog Comparator Pins" - quickly & completely addressed & answered by this reporter - alas to zero (thus far) apparent interest and/or focused response.  (yet Cisco router, pizza parlor & boot loader (none part - your subject)  win appreciative (if focus-free) mention...

  • 0 in reply to cb1_mobile
    Guru 55913 points

    Little progress on your BLDC noted - "focus" shifted again; Its all part of migrating M3-M4 mostly Friday night pizza, shots and all. 540 count not really errors rather were a migration issue known to exist. Simply added #include <stdint.h>, <stdbool.h> to each (*.c) file of the project quickly put count down to 36 errors with added motor Telnet calls and all original Boolean still in place. Not to bad a migration so far amongst the learning curve, text poorly described, missing GPIO PinInts() and muffed up templates.

    Cut paste comparator mention of earlier doc not found in text, will try method above post. PinMux utility made 6 total calls to PinType() analog peripheral AFSEL key unlock function which is not shown in the print screen.  

    TM4C focus shifting BLDC upward of 1.5Kw @125VDC Like to see LM3S8971 RDK pull that off. Vision the X11 interface PCB with over head 80 CFM fan keeping FET (jTa@29degC) driving BLDC @330 Watts sustained. That (jTa) well below 150c max 235 watt TO-220 case each FET with a clip on aluminum heat sink require 4.4 LFPM air flow, translates roughly to 60 CFM when (jTa@63c) BLDC pushing @875 watts.

  • 0 in reply to Genatco
    Guru 55913 points

    Port Issues inside (hw_memmap.h) went almost unnoticed AHB status missing from PinMux Utility output (*.h). Had to  edit each every port entry after forced to updated (gpio.c). Odd address GPIO ports were mixed in the code not belonging to this MPU. Wait until someone tries to enable the USB port with wrong memory addresses. 

    Cb1 thanks again for the comparator configuration info. Tweaked it for using the inverting inputs and internal reference pins. Tracing GPIOPinTypeComparator(); sets the input PAD for analog and negates to set the DEN bits accordingly. 

  • 0 in reply to Genatco
    Guru 117855 points

    Merci mon ami - green ink known to soothe even silicon beast...

    Being lone ranger/lone operator always stressful - that reveals quickly/forcefully - your eruption into so many subjects - most all steering far from your promised, focused, Analog Comparator thread.

    We considered - and then rejected - use of the analog comparator's, "internal voltage reference" which you've adopted!  This due to the relatively, "wide gaps" between adjacent settings - such would never be accepted by our BLDC clients. (read on - there's even a more powerful reason - NOT to do this!)

    Instead - as past stated to you privately - we employ a pot to drive the comparator's (-) input.  No such voltage gaps/jumps there - client can "dial-in" the exact level of current-limiting they desire.  (And - no way for our elite group to "screw-up" the SW - as none required...) 

    Recall we drive the comp's (+) input with the current-sense R's amp'ed output - when that signal exceeds that of our current-set pot - the comp. output goes high and that kills the PWM.  Effect is wonderful for "correcting" transients - and "shames" the RDK's, "One strike and you're out!" (i.e. shut down of the MCU due to any singular over-current event - no matter how brief - no matter how slight!) 

    You may wish to reconsider use of those "multi-gapped" internal voltage references.  Simple pot is so much quicker, so much easier to adjust - so easy to gauge/view its setting! 

    In stark contrast - your internal reference method requires you to "hunt for" the MCU manual - recall the present setting - and then reprogram the entire MCU!  Is that smart - or efficient?   (2nd greenie could not hurt for this "focused" likely helpful, detail!)  Note that magician did not once, "remove eye from the ball..."  (i.e. no Cisco mention...  Just the facts, ma'am - just the analog comparator facts...)  (credit mythical Joe Friday, LAPD...)

  • 0 in reply to Genatco
    Guru 117855 points

    Two more points - these based upon quick/dirty glance @ your code listing:

    a) You continue w/the use of multiple GPIOPinTypeComparator() calls.  (i.e. you call for PC4 & again for PC7)  Only one call - as was past noted - is required when those pins reside w/in the same MCU port (Port C, here).  You're one guy - operating in a back room - behind a back room.  Some respect for your time/effort needs to be emplaced.

    b) You're mucking w/always dreaded Port C (home of JTAG) and you employ, "= 0xyy;" (your post @ 15:50)  Does not such potentially impact one or more of the "holy JTAG quad", PC0-PC3?   Is that smart, wise, deliberate?  "Houston - we done got ourselves a problem..."

    Use of  |=  or  ~&=  seems a safer (Houston approved) mechanism...

  • 0 in reply to cb1_mobile
    Guru 55913 points

    CR register enables the high order nibble bits port C leaving the JTAG low nibble locked (1001.0000) lock override safe by TM4C design. Good to point out that Huston informative. :)

    Multi turn pots and screw drivers tend to randomly slip off crash into live components creating some really great sound & visual effects. Do agree the resistor divider range is somewhat nonlinear more of a stair stepping later matrix.

    The primary point of this post was more informational in purpose to notify the PinMux utility 1.0.4 has pin assignment output issues in this area that clash with (driverlib.lib). Later uncovered AHB port issues from using that file output in bulk GPIO pins migration into existing code of the EK-TM4C1294xl support packaged library.

  • 0 in reply to Genatco
    Guru 117855 points

    BP101 said:
    pots and screw drivers tend to randomly slip off crash into live components 

    No such crash into, "live components" on a properly designed board.  (would be nutz to introduce/route elevated voltages/currents on/around the MCU's ADC.)

    And - if you follow my guidance - design the pot into your board - you may always "dnf" it!  (do not fill)  But this way you've at least, "covered yourself."  Leave it out - I'll give you odds that - downstream - you'll regret that.  

    Small firms really don't succeed by, "designing in imprecision!"  Especially so after they've been warned... 

  • 0 in reply to cb1_mobile
    Guru 55913 points

    Checking the comparator code a bit further after you mention JTAG C port lock, it dawns on me after reading a bit more source text there was something still missing. GPIOPinTypeComparato() is setting GPIO pins incorrectly as a SW Input. GPIOPinConfigure() would have called  port control (Add.BASE:0x52C) selecting the analog comparator peripheral function in the GPIO pin mux.

     GPIOPinTypeComparato() was selecting analog input PADS, AFSEL and DIR mode HW but does not access the pin mux register. GPIOPinConfigure() would have assigned the analog comparator peripheral function which requires a unique hexadecimal code based on the _TM4CX type for each comparator input which is missing in (pin_mux.h) . The work around requires modify (gpio.c) setting HW direction which configures the GPIO pin mux for the analog comparator input peripheral.

         // Enable pin PC7 for COMP0 C0/C1- input
        // MAP_GPIOPinConfigure(GPIO_PC7_C0-, GPIO_PC4_C1-); //Unknown hex peripheral value    
        MAP_GPIOPinTypeComparator(GPIO_PORTC_AHB_BASE, GPIO_PIN_7 | GPIO_PIN_4);
        //
        // Enable pin PP1 for COMP2 C2- input  
        // MAP_GPIOPinConfigure(GPIO_PP1_C2-); // Unknown hex periperal value  
        MAP_GPIOPinTypeComparator(GPIO_PORTP_AHB_BASE, GPIO_PIN_1);

    Opps: Later stumbled upon this section in the data sheet, possibly others have as well since the PinMux utility outputs (green highlight)  GPIOPinConfigure() incorrectly attempts to reroute these analog inputs using  (PCLT). The GPIOPinTypeComparator() sets the DEN bit as the text below infers.

    Page 1777, Other analog signals are 3.3-V tolerant and are connected directly to their circuitry (C0-, C0+, C1-, C1+, C2-, C2+, USB0VBUS, USB0ID). These signals are configured by clearing the DEN bit in the GPIO Digital Enable (GPIODEN) register. 

  • 0 in reply to Genatco
    Guru 55913 points

    Totally bamboozled believing EK-TM4C1294XL advertised as TM4C processor is an XM4C1294NCPDT viewed under 8 diopter mag light. Explains all the inconsistencies between datasheet GPIO AHB ports only exist ports A-J and figured the ICDI was misreporting that. Holy crap batman, Robin laid an egg.

  • 0 in reply to Genatco
    Guru 117855 points

    BP101 said:
    ...bamboozled...8 diopter...Holy cr**...batman

    Not since George Costanza steamrolled women & small children - in achieving, "first to escape" apartment-fire status - has such unique, exotic & memorable word-play, "smoked" the air... 

    We pity the next (unsuspecting) electronic disty who accepts your order - only to have their shipment "stripped naked" - then exposed to its very core by your wildly probing, 8 diopters...  Bamboozled may thus attain, "2-way street" status!"

    Amit may be able to (briefly) forego use of his normal/customary, glare-reducing, "green eye shade" - as his pupils dilate - attempting accommodation/focus upon your (tad understated) GPIO Port ... code rampage...