There seems to be a bit of confusion over what you are doing since your description seems to get your PEs and PDs mixed up. Here's my understanding of what you are trying to do:
When you run the code, only driving PE3 seems to have any effect. The states of PE0, PE1 and PE2 do not result in any changes in PD5 or PD6.
Is this correct?
Looking at your code, the only mistake I see is that you configure PE0:3 twice and, in the process, remove the internal pull-down:
GPIOPinTypeGPIOInput(GPIO_PORTE_BASE, (GPIO_PIN_0 | GPIO_PIN_1 | GPIO_PIN_2 | GPIO_PIN_3)); GPIOPadConfigSet(GPIO_PORTE_BASE, (GPIO_PIN_0 | GPIO_PIN_1 | GPIO_PIN_2 | GPIO_PIN_3), GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD_WPD); GPIOPinTypeGPIOInput(GPIO_PORTE_BASE, (GPIO_PIN_0 | GPIO_PIN_1 | GPIO_PIN_2 | GPIO_PIN_3));
The function GPIOPinTypeGPIOInput() calls GPIOPadConfigSet() internally and sets a basic configuration that does not engage the pull-down. As a result, your PE0:3 pins will float if you don't explicitly connect them to something and this will likely result in unexpected behavior.
Also, the way you have your loop code structured, only a single high GPIO will affect the output at any given time. If you pull more than one high, the higher numbered PE pins will not result in any change in the output. Is this what you intended?
You mention reading the GPIO_PORTx_DATA register but it's not clear if you are reading from the correct place. The "data register" is actually 256 different registers between offsets 0x000 and 0x400 in each GPIO peripheral's memory map. These allow individual pins to be read or written without affecting others. To read the current state of all pins in a given GPIO peripheral, you should look at the register at offset 0x3FC. The same is true for writes - if you write to the register at offset 0x3FC, you write all 7 bit of the GPIO port simultaneously.
I think the next thing to do here is to determine if the problem is on the read or the write side. Fix the problem with the pull-downs then drive each of the PE0:3 pins high one at a time and verify that you see the correct value when you read 0x400243FC (the data register showing the states of all PORTE pins). If that works, try writing to the relevant PORTD data register to drive PD5:6 independently and see if you can toggle these pins successfully. If that's working, step through your code and verify that it is doing what you expect when a given PE pin is pulled high.
Hi Dave!
The code I posted is only a little part of the code I wrote. I use PE0-PE3 to read the status of four external switches, and the PORTD7-0 how databus to drive a graphic LCD.
But when I tested the code,
- only input PE3 seemed to work correctly
- output PD0÷PD3 and PD6÷PD7 were driven correctly, but PD4 and PD5 weren't.
So, i tried this simple code to understand were is the problem.
As you correctly understand, only PE3 seems to have any effect (but the init config was the same for all PEx ports!!);
If I change the code to generate a train of short low to high pulses on PD4, PD5 and PD6, there isn't any toggle on PD4 and PD5; it seems that there some problem in the PDx output port settings too (similarly, the init config was the same for all PDx ports!!):
GPIOPadConfigSet(GPIO_PORTD_BASE, (GPIO_PIN_6 | GPIO_PIN_5 | GPIO_PIN_4), GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD); GPIODirModeSet(GPIO_PORTD_BASE, (GPIO_PIN_6 | GPIO_PIN_5 | GPIO_PIN_4), GPIO_DIR_MODE_OUT); // Loop forever. while(1) { HWREG(GPIO_PORTD_BASE + (GPIO_O_DATA + (GPIO_PIN_4 << 2))) = 0; HWREG(GPIO_PORTD_BASE + (GPIO_O_DATA + (GPIO_PIN_4 << 2))) = GPIO_PIN_4; HWREG(GPIO_PORTD_BASE + (GPIO_O_DATA + (GPIO_PIN_5 << 2))) = 0; HWREG(GPIO_PORTD_BASE + (GPIO_O_DATA + (GPIO_PIN_5 << 2))) = GPIO_PIN_5; HWREG(GPIO_PORTD_BASE + (GPIO_O_DATA + (GPIO_PIN_6 << 2))) = 0; HWREG(GPIO_PORTD_BASE + (GPIO_O_DATA + (GPIO_PIN_6 << 2))) = GPIO_PIN_6;
}}
I remark that the same part of code works correctly on LM3s6965 EVB
Thanks again
Massimo
Massimo,
The next thing to look at is the values in the various PORTD registers that affect configuration for the pin. Once all your configuration code has run (inside your while loop above), stop the debugger and check the values of the following registers:
If the code runs on a 6965 but not on the 6C65, I would suspect the PCTL register (only found on the 6C65) is wrong. If not, check to see if GPIOCR (offset 0x524) has 1s in bits 4:6 (it should. If it doesn't, that would prevent changes to some of the above registers for the pins corresponding to 0s in GPIOCR). I wouldn't expect this to be the case but check anyway since an incorrect GPIOCR value could cause the problem you are seeing.
Dave,
these are the PORTD registers value that I see with the debugger:
The only strange thing I see is the difference between the value of GPIODIR displayed and the value that I see at offset 0x408.
The port PD6 continues to toggle, but PD4 and PD5 doesn't.
And there is the problem on PEx inputs too...
I see a warning in the CCS console:
"C:/StellarisWare/boards/ek-lm3s6965/qs_ek-lm3s6965/ccs/../../../../inc/lm3s6c65.h", line 1517: warning #48-D: incompatible redefinition of macro "GPIO_LOCK_KEY" (declared at line 101 of "C:/StellarisWare/boards/ek-lm3s6965/qs_ek-lm3s6965/ccs/../../../../inc/hw_gpio.h")'Finished building: ../qs_ek-lm3s6965.c'
What does it mean? Is there any relationship with the above problems, and how to remove that warning?
Thanks
Certain newer MCUs have an updated GPIO_LOCK_KEY (sometimes renamed: GPIO_LOCK_KEY_DD) Your current MCU datasheet should detail w/in the GPIO section. This would explain why 3S6965 works - newer MCU does not.
Mystery remains - I read your datasheet - see NO requirement for unlocking any pins on Port_D. However using the 6965 Lock Key with your new MCU may be the cause agent - change it as described...
*** Very important - be certain that you've properly selected your new MCU w/in your IDE set-up. Also - check to insure that the GPIO_LOCK_KEY_DD w/in your code file "matches" that described w/in your current MCU datasheet.
This is a possible cause but it seems that his GPIOCR register is 0xFF for this port so all pins are apparently unlocked. Given what we know so far, I can see no reason for the PD pins not toggling on the 6C65 part.
Are you 100% sure that there's nothing external that could be affecting those pins (shorted to ground or whatever?). Have you tried lifting/disconnecting the pins and checking them when they are in that state?
Agree 100% w/ Dave Wilson - was going to make same point about "external circuit/connection" preventing your pins from toggling high.
Another thought - you cannot buy Eval board for your MCU - so it must be yours is custom board. Have you "ohmed out" those Port_D suspect pins - insuring that they're not tied to ground or other low impedance path on your custom pcb? And - we've long ago learned - never wise to expend such time/effort on single pcb. Build minimum of 3-5 - you need to test all of Dave W's advice on pcb #2 - see if the problem is confined to a single board.
Also - are you sure that in schematic & pcb layout - someway/somehow pinout for BGA version of that MCU wasn't used in place of QFP? (or vice-versa) (mean no disrespect - we are remote and have to "assume" nothing - question everything which is suspect) Check also that the suspect Port_D pins actually make it to your connector/header.
Last thought - is it possible that "elsewhere" in your software you "re-purpose" those Port_D pins - after you've configured as Dave has advised? The only config that counts is "last one" - we've seen this several times - in each case client swore - they hadn't done that... (clients often delightful...)
Hi you all!
I just tried with two other PCB and I saw the same problems; I tried too to isolate the pins PD4 and PD5 from the pcb track and nothing changes...
The only code in the project is the base init (SysCtlClockSet + SysCtlPeripheralEnable) and the PortD init.
With the debugger, the PORTD GPIO_LOCK register seems always 0x00000001 -> LOCKED!!
So, I add this code before all the PORTD registers write commands
[code]
HWREG(GPIO_PORTD_BASE + (GPIO_O_LOCK )) = 0x4C4F434B;
[/code]
Now, GPIO_LOCK reg contains 0x00000000, but nothing changes
I add an external pull-up too on PD5, but the port seems always at high level; with the scope I see a "little" toggle (about 200mVpp), but I think it's due to crosstalking between the adiacent port PD6 that toggles ok.
Any other ideas? I will try to change the LM3s6c65 with a LM3s6965 on my pcb, and verify code and hardware.
Wow - surprised that between Dave W's and this reporter's suggestions - still not performing. Ratz!
Thank you for accepting suggestions and then reporting upon results - even in failure this does help.
As manufacturer and occasional consultant I have one, "w/in the realm of possibility" idea - which I did find & correct for client 2 or so years past. This client left one of his Stellaris Ground pins unconnected. (they just missed it) And - as a direct result they could not "drive low" several GPIO! (appears that Stellaris routes I/O to nearby (nearest) VDD and GND pad on that side of the MCU. Is this possible? (use good, low-voltage meter and ohm out every single MCU pin listed as GND) Have also seen case where the "re-flow" didn't quite work on suspect pin(s) - you need a good visual check (under magnification) here to confirm. (force of your ohm probe may "make" such connection - which "unmakes" as you remove your probe. With the same quality, low-voltage meter it may prove instructive for you to measure resistance to ground (and to VDD) on both "good" and "bad" Port_D pins. Present here, please. (we are looking for a difference between good/bad)
I would have a 2nd person review the datasheet pinouts of 6965 and 6C65 - insuring that they "are" really exactly the same. (sometimes the same person "always" misses something - fresh person will "catch" almost instantly) Remain unsure if you "really" have to employ "Unlock/Lock" as Port_D is not so protected - however be sure to use the appropriate Unlock Code (assuming that codes for each MCU differ - datasheet will detail) after you swap MCUs.
Only after you've performed these checks/measures would I then "swap" MCUs. (seek to save you time/effort) Appreciate your follow-up - this has to be maddening...
Hello cb1, we appreciate your support!
As you suggest we checked all the supply pins (VDD, VDDC, GND): they seem all ok; the re-flow (using a 40x magnifier) seems ok too.
We also measured the pins resistance:
PD4 vs GND 2,48Mohm same value vs VDD
PD5 vs GND 2,48Mohm same value vs VDD
PD6 vs GND 2,50Mohm same value vs VDD
seems to be no striking differences.
We also revised the pinouts of 6965 and 6C65: the only difference we saw and we have to fix is on pins 5 and 6 (on 6965 they are ADC input pins, on 6c65 we use them for digital output purpose); perhaps have you revised the parts datasheets too? Have you found any difference?
Today in the afternoon I will receive the LM3S6965 parts and then I swap the MCUs; hope to solve (temporarely) the problems. Later this week we must complete the pcb firmware...
When all else fails - RRTFM! (really read...)
Find that parts may not be pin for pin replacements - key being pins: 36, 83, 84. These are defined as VCCPHY by 3S6965 - as "normal" VDD by 3S6C65! One suspects that 6C65 was chosen to "avoid" Ethernet function (cost saving) and just perhaps - pins 36, 83, 84 are "no connects" or isolated from normal VDD - they must tie to VDD for use w/ 3S6C65! Below from 3S6965 datasheet...
Further - pin 42 of 6C65 is GND yet is defined as GNDPHY w/in 6965 datasheet. (May well be tied to ground - but should be checked - could have been missed in your pcb layout!)
Hope this info reaches you before you swap MCUs - my finding this morning agrees with my earlier expressed suspicion that a vital VDD pin was "missed/no connect"
Kindly review - check your pcb - and report. Note also that VLDO is about half (1.3V) w/ 3S6C65 that of 3S6965 (2.5V) - best to check...
RRTFM is always a good practice... but we just read and compare the parts datasheets a lot!
GND, VDD and VDDPHY pins are all ok, checked with the scope; (we'll use the ethernet function)
VLDO/VDDC is internally generate; we cheched with the scope and value are ok.
So, we made the MCU swap on our board; recompiled the code with minimun changes (target in ccs project options, system clock setup) and load the program: the ports PD4, PD5, PD6 are toggling correctly, and the PEx ports (inputs with wpu) levels change as we expects.
What we can do even? Next days we must works on code & pcb to complete the project, but any other suggestion is welcome.
If port D is locked by default, that tends to suggest something weird is going on with this part. I'll have to get hold of am LM3S6C95 and try to reproduce the problem here. This may take a couple of days but I'll get back to you once I've had a chance to play with it.
Ratz! Feel good about effort/persistence - not so much about results - sorry. I'm "out of tricks" - schematic of your 3S6C65 board would enable multiple, fresh eyes to review...
Hello Dave!
In recent days we have worked with LM3S6965 cpu, managing to deliver prototypes to our customer.
Now, we have a few "quiet" days, and we would like to solve the IO problems on the same PCB, with LM3S6C65 cpu.
In the meantime we also involved our local distributor for technical support direct from TI's FAE, but we still have no contacts...
Have you got an LM3S6C95 and did you try to reproduce the problem? We expect a friendly response ASAP.
Regards,