SX48 Failing above 42mhz

natpie

I've been working on a project for a while now that has 20 7-seg Displays 4 2-bit Grey code rotary encoders and 4 push buttons. Everything was working fine until I bumped up the clock to add a VP UART. Everything seems to work fine until I hit about 41 or 42 Mhz. The first bank of displays is very dim then fades away then the second bank fades out as well.


I'm using a SX48 Proto board from parallax. The displays are driven via 8 pins on the SX with 470 ohm resisters on each. The displays are indexed via 6 pins (I put some current limiting resisters on these but don't remember the values) connected to two 54154 4 to 16 multiplexers (4 pins are the address and the other 2 are connected an enable pin on each of the multiplexers). The outputs of the multiplexers are connected to 20 PNP Transistors then each of the Cathodes on the 7-seg displays. The encoders and push buttons are connected to ground and pullups are enabled on the SX.



I've tried running the clock form my SX key, when I hit the magic number I lose communication with the sx key and the displays on my project fade out. I'm no expert but it appears to me I'm drawing too much current somewhere, but I'm not sure where. I would appreciate any suggestions you could offer.

I'm including my source code in case it will be help full. Be warned its a bit messy as its a work in progress. Right now the interrupt overruns itself but that isn't the problem it occurs without that problem.

Post Edited (natpie) : 6/15/2009 4:14:44 PM GMT

Peter Verkaik

I think 42MHz is your limit for your isr code.
Your isr code (serial comms ?) takes a number
of cycles. Increasing the clock decreases the number
of available isr cycles.

regards peter

natpie

Peter Verkaik said...
Increasing the clock decreases the number
of available isr cycles.

I'm not following you on that one. The ISR runs every time the counter rolls over to zero. This happens on the same number of cycles regardless of the speed. Are you referring to the SX/B option to add the Frequency of the interrupt at the beginning and have it calculate the the ISR counter?

I've run a completely striped down ISR (my display routine isn't long at all) and I've overrun the interrupt and the display will still work. The only variable that breaks it is the clock speed.

I'm in the process of adding the serial code now. I've elected to not reinvent the wheel again and am using the buffered serial example from the forums (I think it was posted by Jon Williams). Its intended to run at 50mhz. I'm in the process of tweaking it to run slower as I cant get my system to run at 50Mhz without failing.

Bean

My guess would be a Read-Modify-Write problem.

This is caused to changing the bits of a port too quickly (before the pin actually changes state).

This can cause all kinds of headaches.

For example, let's say all bits of PORTB are low. If you do:

RB.0 = 1
RB.1 = 1

At high clock speeds, there is a very good chance that RB.0 will be low after the sequence. Why ? Well to execute the "RB.1 = 1" (SETB RB.1), the processor will read the entire RB port, then modify the RB.1 bit, then write the entire port back. If the RB.0 bit has not changed from 0 to 1, before the port is read, then RB.0 will read as zero. Then the processor will set bit RB.1 and write the entire port back (with RB.0 still zero).

I hope that makes sense.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There is a fine line between arrogance and confidence. Make sure you don't cross it...

·

natpie

I'm assuming your example:

RB.0 = 1

RB.1 = 1 translates to:

SETB RB.0

SETB RB.1

when asymbled.· The displays use whole ports A for the multiplexer (first 4 bits) and 7 seg displays are on one as well.·· The recive 8 and 4 bits at a time.·· I am however using RC.0 and RC.1 to select between two muliplexers.·· When my counter reaches 17 I run a CLRB and SETB on RC.0 and RC.1 and again at 21 to reset back to the first.··



If this the problem would a copule of No Operation commands betwen my SETB and CLRB commands fix this?·· Is there a rule of thumb on when this becomes and isue, and how long of a delay I really need?

natpie

THANK YOU BEAN!!!

Looks like you nailed it. When I got home I added 3 NOP (I'm sure I probably don't need that many) between my SETB and CLRB, uploaded the code, slapped in a 50mhz resonator and it worked for the first time at that speed.

Bean

You are welcome.
The voice of experience. I have worked for hours on a similar problem, and it drove me NUTS!

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There is a fine line between arrogance and confidence. Make sure you don't cross it...

·

natpie

Bean said...
The voice of experience. I have worked for hours on a similar problem, and it drove me NUTS!

I wish I had posted this question sooner. I did a complete redesign added an additional board and had the same problem when I was done. Thanks again.

Leon

You won't need the NOPs if you use a shadow register. It's the usual way of avoiding read-modify-write problems.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

natpie

Can you go into more detail on how to deploy this shadow register technich?

UPDATE:
Never mind I found a reference to it.

MOV Shadow_Register, RC
SETB Shadow_Register.0
CLRB Shadow_Register.1
MOV RC, Shadow_Register

So I take it from this that memory doesn't have this issue, just the pins?· At a glance that looks like 4 op codes.·· I'm currently overcoming the problem with 3 NOP, I haven't rolled it back to see if less will work yet, but for my application it looks like NOP is a more economical solution in time and memory.

Thank you for the tip, I definatly can see situations where this techinich will be very usefull.

Post Edited (natpie) : 6/16/2009 7:46:01 PM GMT