Mega128 extmem baffling problem

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

This prob has had me stumped for days. I have a buildtoprint of a mega128 bd we built back in 03 (!) that uses a ram and the extmem interface. It has a 74LS373 latch and a 138 decoder with chip selects going to a CS8900 eth chip, a kbd encoder chip, and an lcd display chip. When I burn the prog using the jtagice, program runs perfect. Then I disconnect power and repower, and it acts like the ext mem interface isnt initing. The clue is, when you dump the address where the eth chip is, you get incrementing bytes on the bus read. I print out the contents of 0x230a and b and when its initialized right, I see 0x630e (contents of reg0 in the chip). When it not working, I see 0d0c like the memdump at 0x2300. When its working, the eth chip inits and reads and writes ok, the kbd chip works, the display works, the ram works (holds the display stuff). I have it rigged to spin in a loop reiniting everything and after a couple secs, it sticks... good numbers show up on the screen. At first, it would always init ok if I hit the hw reset button. It acts like a cap charging up. I'm scopeing everything... power pins, chip selects. Hitting the hw resets starts it in the reinit loop. Doesnt matter if the jtag is connected or not. Doesnt matter if the jtag is disabled or not at init. The hw reset DOES NOT go to the CS8900. I send it a sw init. I guess it just isnt getting a good poweron reset. (Thanks for reading.... I'll add a delay before the 1st init... standby...) post any additional suggested tests... thanks. Crap. Adding 300ms delay at poweron before swinit didnt make it better. Its a 4 layer bd with pwr and gnd in the middle, and every chip and cap has vias down to pwr and gnd.

 

Imagecraft compiler user

Last Edited: Fri. Oct 16, 2015 - 04:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
When I burn the prog using the jtagice, program runs perfect.

 

This tells me that you have a variable that is initialized by JTAG, but not properly initialized at runtime.

 

In consideration of others, please RTFM!

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

I Just use the jtag to burn flash and rom, not debugging. After the burn, the prog is running with the right numbers on the serial on the pc. If I turn off then on, the eth chip out at 0x2300 doesnt seem to init, because I cant read and dump from 0x2000 and see anything except incrementing bytes... 00 01 02 03 .... 0e 0f. Like the extmem wasnt initialized. But thanks for the tips... keep em coming folks.

 

 

Imagecraft compiler user

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

I can only think of three things, a DDR incorrect, a bad solder joint, or do you need a wait state?

It all starts with a mental vision.

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

The 138 selects eight 0x1000 byte hunks at 0x1000 0x2000 0x3000 0x4000 0x5000 by using addr12,13,14. A15 goes thru an inverter and is the /CE for the ram. Addr <0x8000 is A15 lo, /CE hi, which I run to the OE1 on the 138. OE2A and B are gnd. 8K ram is the 2nd sector at 0x8000. Ramtest is perfect. Can fill and readback unique patterns. This means the latch is working. I put 0x48 in MCUCR... the 8 means 2 wait states in the lower sector. I think I tried C which is 3. Might try it again now that you mention it.

 

Imagecraft compiler user

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

And, of course, if the clock is >=8MHz you MUST be in full swing mode, just in case.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Last Edited: Fri. Oct 16, 2015 - 08:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yep, 14.7456, CLKOPT, I can see it on the scope. I guess I'll cut the reset loose and run it to an output. Cant see any diff between this bd and the last 2 or 3 that used the same mega128 abs CS8900.

 

Imagecraft compiler user

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

jpmargis wrote:

bobgardner wrote:
When I burn the prog using the jtagice, program runs perfect.

 

This tells me that you have a variable that is initialized by JTAG, but not properly initialized at runtime.

My money is on this being the problem.  During JTAG programming all RAM is cleared to zero.  I'll bet you have an uninitialized local variable that is giving you fits.

 

Letting the smoke out since 1978

 

 

 

 

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

+1 for uninitialised automatic. @digitalDan is quite correct about SRAM and GP registers clearing during programming. SRAM otherwise powers up in a semi-random state. GP registers >>will<< power up as zero >>if<< Vcc drops below about 0.2V. Between 0.2 and about 0.5, they will begin to lose bits. Above that and they are unaffected. So even if the 'culprit' automatic is held in a reg, unless you bleed the PS caps to 0V before a power-up, you might have trouble.
I haven't tested theses findings on an m128, but they are true for m328p and t85, at least.
Of course, I'm not an ICC user, so I can't be certain. Does ICC clear GP regs and SRAM before calling main()?

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

You blokes might be on to something. Imagecraft has a check box to 'don't use regs 20,21,22,23', and I have a ticcnt var used in a tight refresher loop to update the display. If I uncheck the box and put my ticcnt in a GPIOR and it works, I'll owe you all a bottle or a case. Its a 40usec interrupt. How long do 65536 of those take? Stand by till Mon.

Imagecraft compiler user

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

Well, here it is Monday. I got rid of my clever faster way of keeping a var used in an interrupt handler in a reg, and just made it global. Driving home Friday I was thinking "How could this lcd refresh variable have anything to do the ethernet chip initialization?". Sure enough, program burns with jtag then runs, prints out the cs8900 register contents correctly. But after a power off on, it just spins in the loop at init calling initCS8900 then reading back the reg0 in the chip. It seems to take after several seconds, but hitting the hw reset doesnt help, jtag connected or disconnected doesnt help. I said I was going to add an avr out to reset the cs8900... there goes my idea of being a hero and coming up with a sw only fix...

 

Imagecraft compiler user