What kind of weirdnes here comes be4 me? PORTB Pullups NG

Go To Last Post
19 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have gone over this again and again. While stepping through, all of PORTB stays high in the i/o view. My code is good, it simulates properly, but when put through the STK-500 it fails. All of PORTB was set to input (not assumed in) and pullups were enabled. The problem is that 6 & 7 are low whilst all others are high. See the attached pix. No other code ever clears this port or writes to this port. It is strictly interrupt driven from PORTD, while dip switches are read on A & B. Both A & B are disconnected at the connector on the STK. I have used both the M8515 and the S8515. Any one have any ideas??? Thanks.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you disconnect anything connected to the port, do the values then constantly read high for all pins? If it simulates correctly, it's likely a HW issue and most likely a faulty chip or something connected to the pins is pulling them low.

Clancy _________________ Step 1: RTFM Step 2: RTFF (Forums) Step 3: RTFG (Google) Step 4: Post

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clpalmer wrote:
If you disconnect anything connected to the port, do the values then constantly read high for all pins?

As I have already stated, there is nothing hooked to the port. (B) As par as I can see there are no "traffic cops" on the STK to the pin ports from the test socket. Port lines are direct to the PORTB pins. I was stepping through as seen in the picture and stopped for a photo. I also can apply +5v to the PB6 & 7 pins while running the programmed circuit, without any shorts. Ohm meter reads open on these as well. Compile or Studio issue???

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you ever hit anything like this again look at the "I/O Ports" section of the datasheet and, within that, "alternate Port functions" - guess what else gets connected to PB6, PB7 on a mega8515?

As another clue check out Table 92 in that datasheet

Cliff

(then remove the ISP6PIN cable on the STK500 and try again)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"guess what else gets connected to PB6, PB7 on a mega8515?" I also used the standard 90s8515 same result.

"As another clue check out Table 92 in that datasheet"
Did that, assume it applies only to the Mega.

"(then remove the ISP6PIN cable on the STK500 and try again)" I'm using parallel mode.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Then are all the parallel cables removed?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Of course!! I'm not that much of a NoOb!!! :shock:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Fine - sort it out yourself then - I'm out.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What Cliff was nicely saying is that the PB6 and PB7 pins are also the clock (XTAL) pins for those chips and they get their signals routed differently on the STK500. In the case of the 90s8515 it needs an external source so those pins are used ( you wouldn't want your clock signal to be routed to the PortB header and hooked up to a switch now would you?).

In the case of the mega8515 it can work with an internal clock so those pins can be used for I/O purposes. So if the mega8515 is set for that then how do you see those pins? IIRC those pins show up at the PortE header as XT1 and XT2 . Use your ohmeter to verify this. You will also need to remove the XTAL1 jumper ( or else you will be fighting the STK500 clock generation circuitry).

Pete

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the reply Pete, but I am confoosed as to exactly where your coming from. Both chips do not have any dual or alternate functions configured. Even the M8515 is configured as S8515 compatibility. A & B are both inputs w pullups all pins. PB6 & 7 are low for some unknown reason. I have looked at the datasheets and am lost as to just what is configuring these chips to do this alternate mode. I have an EETools parallel port programmer, as wel as going through the STK. No alternate bits are set in either. Any help would be appreciated.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Steve wrote:

Quote:

Pete,

I think maybe you are getting the mega8515 mixed up with the mega8 (maybe). I am looking at the datasheet for the mega8515 now and XTAL1 and XTAL2 are on pins 18 and 19. PB6 and PB7 are on pins 7 and 8. But then again, maybe I am the one confused .


Like Pavlov's dog I saw the PB6 and PB7 issue and responded but like you say it's for the 8 series :oops: .
Quote:

I have an EETools parallel port programmer, as wel as going through the STK.

Why?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I have an EETools parallel port programmer, as wel as going through the STK.

Why?

Because I frequently do other micros as well as eproms.

So....any way...does anyone have an idea???

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

"(then remove the ISP6PIN cable on the STK500 and try again)" I'm using parallel mode.

When you say parallel mode are you talking about your EETools parallel port programmer?

Is your EETools programmer still hooked up to the STK500 when you notice the PB6 PB7 issue?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"When you say parallel mode are you talking about your EETools parallel port programmer?"

"Is your EETools programmer still hooked up to the STK500 when you notice the PB6 PB7 issue?"

No no no. Or maybe yes. The EETools programmer is a separate entity. It programs in parallel mode only. ZIF socket, software configurable, no jumpers. No relation or connection to the STK module. It is a confirmation tool for a very confusing issue, my PB6 & 7 dilemma. i.e. drop in the S8515 or M8515 and read it to see what options were set or reprogram the chips to see if they still do the same thing as when the STK programmed them.
....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you certain that the SPI is not enabled? (SPE bit in SPCR)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok I looked at the EETools programmer ($295) and here I thought it was just another one of those homebrew jobs.

For a sanity check( not all of your code is presented for inspection) just write a quick little program that just sets PortB as you have and just enter a loop not touching the port anymore then measure.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, as the obvious hasn't been suggested yet, I'm back in with the following suggestion - that you remove the chip from the socket, bend out the PB6/PB7 pins and reinsert. Now measure the "floating pins" that cannot possibly influenced by anything within the STK500 circuit - if the problem persists its the chip/software if not it was something in the STK circuit loading the lines.

I'm kind of surprised that you hadn't thought of this obvious test yourself?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Which STK500 socket are you using? Is pin 1 in the correct direction? [If you are doing successful ISP sequences, Read Signature, etc. then this is probably moot.]

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

digitool wrote:
Ok I looked at the EETools programmer ($295) and here I thought it was just another one of those homebrew jobs.

Nope it's $995.00
http://www.eetools.com/index.cfm...
It's been around for at least 10 years.

Problem solved. I bit the bullet and installed Studio on another computer, took the asm file, compiled it on the new computer and the chip(s) work fine now. Retried them on my computer and no good. I'm going to do a complete reinstall of Studio on my computer tomorrow. The last thing I did recently was to upgrade my previous version last week. Go figure..... Thanks for trying to all who responded in a civil manner.