Problems with 2 SPI Slaves

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

Hi Guys

 

Hope someone can help be out here, I'm going nowhere after a couple of days debugging.

 

I have an Atmega328p on a custom board with an external clock running at 20MHz

 

On the board there are two SPI devices, namely MAX7221 and an MCP4132 (rheostat).  The board is controlled via TWI

 

Each slave has their own SS pin on the 328p

 

All is working fine except the MCP4132.  

 

If I write to the MCP first, it works as do subsequent writes to the MAX.  But after writing to the MAX, the MCP doesn't respond anymore.  Slowing down the commands doesn't help.

 

Below is my setup

 

// Ports for Atmega328P

#define PIN_SCK  PORTB5

#define PIN_MOSI PORTB3

#define PIN_SS   PORTB2

#define PIN_SSW  PORTC1 // Slave select for MCP

//Init SPI interface

// SCK MOSI CS/LOAD/SS as OUTPUT

DDRB |= (1 << PIN_SCK) | (1 << PIN_MOSI) | (1 << PIN_SS);

 

//Setup SS for MCP as output

    DDRC |=  (1 << PIN_SSW);

------------------------------------------------
//Write out data for MCP
 

PORTC &= ~(1 << PIN_SSW); // Start transaction

spiSendByte(0x00); // function

spiSendByte(data); //Set position

 

PORTC |= (1 << PIN_SSW);     //End transaction

--------------------------------------------
// Write out SPI data for MAX

PORTB &= ~(1 << PIN_SS)
 

spiSendByte(0x00); // function

spiSendByte(data); //Set position

PORTB |= (1 << PIN_SS)
 

void spiSendByte (char databyte)

{

// Copy data into the SPI data register

 

SPDR = databyte;

 

// Wait until transfer is complete

while (!(SPSR & (1 << SPIF)));

}

 

 

Any pointers as to where I'm going wrong would be appreciated.  It's almost as if the SS pin on the MCP isn't working as it should

 

regards

 

 

 

 

 

 

 

This topic has a solution.

 

 

Last Edited: Sat. Sep 7, 2019 - 02:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your code leaves a lot a questions....

 

Not sure if you are using Studio or not but this:

// Write out SPI data for MAX

PORTB &= ~(1 << PIN_SS)
 

spiSendByte(0x00); // function

spiSendByte(data); //Set position

PORTB |= (1 << PIN_SS)

Looks suspicious because PORTB is in BLACK as opposed to the PINK PORTC is.  Usually if Studio recognises definitions it highlights them in PINK.

 

Does the compiler spit up any warnings?

 

Do you have a scope or Logic analyser that you can put on the pins and see whats happening?

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

I'm using studio, the lack of colours is just my bad pasting.

 

It's a little difficult to attach any probes on the board as it's all SMD.  I guess I'll have to breadboard it.  I was hoping I'd missed the obvious.

 

regards

 

 

 

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

nikm wrote:

 I was hoping I'd missed the obvious.

 

 

You really did not leave much to make it 'obvious'....theres not much there.

 

Another Freak may be able to come up with a better answer than I though, but you could try soldering some thin wires to the pins of the parts maybe and connect your probes to that?

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

Have you read the mcp4132 datasheet, mainly the section descripting CS pin function? Haven't used spi device which CS pin does have 3 states, but maybe that is the proplem you are observing here.

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

I did wonder about the CS state of that port.  Have to say I didn't fully understand that section of the data sheet.

 

regards

 

 

 

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

As a test you could try cycle the CS pin of mcp4132 once after issuing a command to the max device.(low, high, low, with atleast 100ns delay in between).

Edit: Thought, if the proplem is that the mcp switches between command and high voltage command modes I don't think cycling will work, could not find high voltage command mode threshold voltage with quick peak of the datasheet.

Last Edited: Tue. Sep 3, 2019 - 04:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nikm wrote:
I did wonder about the CS state of that port.

 

Crap!  I forgot I used the MCP 41xx series parts once

 

Just tie the CS pin to your I/O  pin and thats all you need for standard operation.

 

Jim

 

 

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

That's what I've done.  The data sheet speaks of a required delay after dropping the pin, and I'm allowing 1ms which should be plenty it's still unreliable.  The MCP4232 I'm using has a 0-50k resistance and it's in series with a 10k resister.  The wiper is then connected to the iset pin of the MAX7221 which is looking for around 12k-62k which allows me to programatically adjust the current draw.

 

I'm going to breadboard this tomorrow and hook up a logic analyser to see if that gives me clues.  

 

When I run the two slaves fast, I notice overtime that the data intended for the MCP is being sent to the MAX.  It may be I have a race condition somewhere.  However running the data in 5 second bursts makes the MCP unresponsive almost immediately.  At first I thought it might me an SPI speed issue but the MCP will do 10MHz so that should be fine.  I could check for an error condition coming back from the MCP, but I still haven't figured out from the data sheet how to do that yet. 

 

Somehow I'm just missing something simple here I think.

 

Question:  It looks like the MCP needs mode 0, is that the default mode?

 

regards

 

 

 

Last Edited: Tue. Sep 3, 2019 - 08:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

SPI has 4 modes of operation, have you verified your using the correct mode for each chip?

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

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

nikm wrote:
It's a little difficult to attach any probes on the board as it's all SMD

Wot - no test points ?!

 

surprise

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1
//Init SPI interface

// SCK MOSI CS/LOAD/SS as OUTPUT

DDRB |= (1 << PIN_SCK) | (1 << PIN_MOSI) | (1 << PIN_SS);

 

//Setup SS for MCP as output

    DDRC |=  (1 << PIN_SSW);

Your init seems a bit light, as I don't see where you setup the SPI control reg with Enable, data order, master/slave or clock polarity/phase or speed???

Is this ALL of your code, if not, please post a complete small program that demos the problem.

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

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

Yes that's all I have for the init.  To be honest it's been working fine with the MAX7221's for some time.  It's just been the addition of another slave.  MCP runs at 10MHz.  Are there other options I should specify that aren't default?

 

I managed to hook up a logic probe today, just on the MCP side (triggering on the SS going low).  What I discovered was that only the first byte was going out on the wire, not the second.  I did get another byte some 2 seconds later that was garbage.  The code calls a function in the same class (spiSendByte) with the toggle of the SS pin before and after sending.  When I copied the code from that function, lo and behold the MCP started working as I could see two bytes being transferred.  Thought I'd cracked it.  That said, why would the code work inline, but not as a function?

 

It's still not working as it should though.  If I make a lot of calls to the MAX.  Pause 5 seconds and then call the MCP I'm back to square one.  1 byte and the bus seems to hang. why!!!!! grrrrr

 

Tomorrow I'm going the wire the SS for the MAX and add that to the logic probe and see if there are more clues.  Given that I'm waiting 5 seconds from the last send to the MAX, I don't think it's a timing issue.  However the AVR is locked at that point.  No SPI activity at all.  Perhaps both SS lines are low?  But I don't know how that could be.

 

regards

 

 

 

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

No,  thought the board was good to go after a month of testing the MAX.  wired some tiny cables on instead to get a look at the signals.  It's like fixing a computer I guess,  Never put the box on until you've tested it first.

 

regards

 

 

 

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

nikm wrote:
it's been working fine (sic?) with the MAX7221's for some time.

Does that mean, "rigorously validated that all parameters are well within spec under all conditions" - or just that it's been running, and you haven't noticed any problems?

 

  It's just been the addition of another slave.

Whenever that kind of thing happens, it suggests that something(s) was/were marginal before - and the "extra" has just pushed it over the edge ...

 

I'd suggest capturing what goes on with each sensor alone, then with the 2 together, then spot the difference ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Its been running for about 6 weeks on and off at 50 x expected speeds using the 4 x MAX7221's without problem so I don't think it's marginal.  It's TWI driven so I'm looking towards a potential conflict with an interrupt being triggered.  In any event, I should hopefully be able to see them both on the analyser later today which might give some clues.

 

Running the MCP on its own hasn't caused any issues for many hours.  It is also perhaps the fact the CPU is running with debug wire on, might be an issue I guess.

 

 

regards

 

 

 

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

Wait
Originally you said 2 slaves...now there's 4x7221 and the MCP?
That's 5 total not 2

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

The MAX7221 are daisy chained so they appear as 1 logical SPI device

 

regards

 

 

 

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

nikm wrote:
Yes that's all I have for the init.

Hum that can't be right as the SPI is not even enabled from the code???

nikm wrote:
The MAX7221 are daisy chained so they appear as 1 logical SPI device

Sorry too much seems to have changed from the OP, where one (or is it now 4) "worked" but the other (or is it now 5) device does not?  I'm lost.

Start from the beginning, tell us about all of your HW and show us a small complete program that your having problems with.

Then maybe someone here can follow along with you and help you trouble shoot your issue.

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

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

    
Apologies, cut and paste error.  Been staring at the code way to long, here's the init

 //Init SPI interface     
// SCK MOSI CS/LOAD/SS as OUTPUT

 DDRB |= (1 << PIN_SCK) | (1 << PIN_MOSI) | (1 << PIN_SS);

 

//Setup SS for MCP as output        

DDRC |=  (1 << PIN_SSW);     

 

// SPI Enable, Master mode     
SPCR |= (1 << SPE) | (1 << MSTR) | (1 << SPR0);

 

The board consists of an Atmega328P, 1 MCP4132 and 4 x MAX7221 daisy chained 

 

The 4 MAX7221's appear as one SPI Slave.  I am manipulating 2 slave select pins
 

The code is pretty complex because of the functionality which has nothing to do with the SPI.  In essence I'm receiving a command over TWI and depending on the data I'm selecting a slave and writing two bytes to it.
 

I'm about to hookup the logic analyser so see what's going on behind the scenes SPI wish.

 

regards

 

 

 

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

nikm wrote:
The code is pretty complex because of the functionality which has nothing to do with the SPI.

That's why

ki0bk wrote:
show us a small complete program

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Think I may have found the issue, but not the solution.  It looks like the SS pin on the MAX is being held low most of the time and there's an overlap when both slaves have it low

 

Logic analyser

 

 

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


nikm wrote:
and 4 x MAX7221 daisy chained 

So connected like this:

so you send a multi-byte stream when the SS pin is low and "talk" to all devices at one time?

 

Instead of this:

Where you only "talk" to one chip at a time by enabling only one SS pin? 

Sorry, I just want to be sure I understand how the HW is connected.

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

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

The max7219/7221 are wired thus (daisy)  or rather serial cascading.  These work just fine, it's the interaction with the other slave that's the issue.  The load/data line is SS

 

regards

 

 

 

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

Don't YOU have control over when the various peripherals are accessed? It seems very unlikely that one would be accessed while the other is. Normally, you would wait for one to finish before starting the other.

 

Jim

 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Thu. Sep 5, 2019 - 07:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

 

That's the way the code is written yes.  However I've been reading up about SPI devices that don't release the bus.  While the MAX7221's look genuine, I'm not 100% sure they are.  I've ordered a set from  a reputable, if expensive supplier and I'll make a new board tomorrow.  It's very strange that the outputs from the logic analyser show that the SS pin for the MAX was low most of the time even though it wasn't processing data.

 

regards

 

 

 

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

nikm wrote:

Hi,

 

That's the way the code is written yes.  However I've been reading up about SPI devices that don't release the bus.  While the MAX7221's look genuine, I'm not 100% sure they are.  I've ordered a set from  a reputable, if expensive supplier and I'll make a new board tomorrow.  It's very strange that the outputs from the logic analyser show that the SS pin for the MAX was low most of the time even though it wasn't processing data.

 

regards

 

Do you have pullup resistor for the SS? Usually I have added one just in case.

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

No I don't and wish I had.  At the time I didn't think I needed to.  Could wire one on to test though.  10k?

 

regards

 

 

 

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

If that long chip select is on the daisy-chain set, you  need to be aware that the chip select needs to be continuously low during the entire transaction. Otherwise, the message will be broken up and devices will get the wrong data. The key event is when the chip select returns high.  THAT is the signal that tells each one to latch the data that it contains.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

Agreed, but isn't this line going to block to prevent this?  Besides in testing I'm waiting 2 seconds between transmissions.

 

regards

 

// Wait until transfer is complete

while (!(SPSR & (1 << SPIF)));

 

 

Last Edited: Thu. Sep 5, 2019 - 08:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That only waits for the first byte to complete, not the entire message!

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

0hhhhh!  Just to get my head around this, here's the sequence of events

 

TWI Stop/restart tells me I'm done receiving data and interrupt is triggered. 

Run function that then sends formatted data to appropriate device.

stretch TWI clock if required until I'm done.

 

Surely this is all single threaded?  The SPI sending just loops through the data.

 

regards

 

 

 

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

But how does that other SPI process run while all this  is happening? Surely, its not in an interrupt, is it?

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, I'm not using the SPI interrupt.

 

Changing the MAX7221's for ones I know are 100% genuine made no difference, neither did adding a pull-up on the SS line.

 

The issue, which shows up in the logic trace is that I'm getting an overlap on the SS pins as I'm driving the MAX's as fast as I can.  If I introduce a 10ms delay between each SS transition the issue is resolved in that I'm not getting corruption of data.   However the performance hit is too much. 

 

I'm replacing the chip with an Atmega328PB which has 2 x SPI.   One will be the high transaction one, and the other for lower levels.  I could mess with the code and put more logic in it to improve things but I need to be almost continuously send 32 bytes to get the performance I need.  Changing the chip type will resolve the collision/overlap.

 

Thanks for everyones help, much appreciated.

 

regards

 

 

 

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

YOur solution is not really a solution, more like an expensive band aid, but if your happy with it then great.

 

Thanks for letting us know you have solved the problem to your satisfaction.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

I am confused because post #22 shows both SS's are low at the same time.  But both SS pins are output right?  Both are controlled by the AVR?  According to your code, one goes low, two bytes are sent, then it returns high, then the next SS line goes low, two bytes are sent, and it goes high.  I don't see why/how you would have both low at the same time?  It isn't like these have a pullup and the slave device can hold them low, right?  If they are output on the AVR, then the AVR dictates what they will be and the other side should be high impedance and accept what it is sent, low or high.

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

You're absolutely correct but testing says otherwise.  The time of the overlap is 40 micro seconds.  Is it possible that this is the time it takes a pin to change from low to high?  Either way I was getting both devices being talked to at the same time when running at high speed.  By that I mean data was being processed continuously.

 

regards

 

 

 

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

I take your point, and I would dearly have liked the time to figure it out software wise, but time was a constraint.  The purist in me wanted to keep going, sadly I ran out of time. 

 

As far as cost goes, chips are similar in price with just a few tweaks to the board.

 

regards

 

 

 

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

I'm glad you have it working.  The pin change speed might be in the datasheet, but it is going to be very fast, likely in nanoseconds.  I would think the only way it could take 40 microseconds is if it was weak - you have that pin set to output right?  Not set to input and you are just enabling/disabling the pull-up resistor?

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

hmm, I thought I was toggling high low as below

 

PORTC &= ~(1 << PIN_SSW); // Start transaction

spiSendByte(0x00); // function

spiSendByte(data); //Set position

 

PORTC |= (1 << PIN_SSW);     //End transaction

Is there a better way?

 

regards

 

 

 

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

If the DDRC has that pin as output, then yes.  If the DDRC has it as input, then you are toggling the pull-up resistor.

 

You can do a quick test and modify your code to toggle it high/low/high/low immediately and see what happens.  Does it show a high/low/high/low transition that is very fast (say a couple clocks of the AVR)?

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

this is how it's setup

 

/Setup SS for MCP as output

    DDRC |=  (1 << PIN_SSW);

 I'll but some test code on the analyser tomorrow, but what's the alternative solution?

 

regards

 

 

 

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

I don't know that there is an alternative solution.  I think you need to to more testing to figure out what is really going on, but the short of this is that if you take a SS pin HIGH, it should occur very quickly.  Sometimes it takes a device a little time to disable its one output (MISO) if it is truly a SPI type device that will do that (some devices do NOT disable the output - I've dealt with displays that have a data out DO that is always enabled irregardless of the SS state).  When you run into an issue like this, you basically have to modify the code to try to expose what is going on.  Try changing it in different ways and evaluate what happens, hopefully this will yield an aha moment of what is going wrong.  Try toggling both SS pins, do they both exhibit the lazy state change?

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

nikm wrote:

hmm, I thought I was toggling high low as below

 

PORTC &= ~(1 << PIN_SSW); // Start transaction

spiSendByte(0x00); // function

spiSendByte(data); //Set position

 

PORTC |= (1 << PIN_SSW);     //End transaction

Is there a better way?

 

regards

 

Thats low-high

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user