ATmega16M1 to Atmega16A bidirectional SPI [solved]

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

I'm trying to get bidirectional SPI comms. between an Atmega16M1 running on an STK600 using the alternate ports MOSI_A etc and an Atmega16A running on an Easy AVR5A.

I've checked (and had independently checked) the port connections and am using assembler in Studio5.
I can send data from master to slave with no problem but although MISO shows pulse activity on my scope, the master will not return any data. I have checked that I'm not getting a write collision during Slave send.

I've lost a lot of my remaining hair on this. All the published examples I've found only describe an interrupt or polled transmission from Master to Slave (ie. one way). The DN_035.pdf document that describes bidirectional transmission resorts to dynamic switching of Master/Slave to achieve alternate half duplex comms. Why? If full duplex is available using the SPI ports on the AVR chips, why not use it?

Has anyone any experience of the Atmega16M1 chip? Is there a problem with it when using the alternate port designation?

Any help/suggestions would be gratefully received.

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

Sorry but how are you trying to get the slave to send to the master?

You do realise that the master is the one that controls SCK? So only a master can initiate a transfer. It has to poll the slave to get anything it may want to send back.

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

Master is clocking slave, I load write to slave when slave's byte received interrupt is triggered and also read the incoming byte from master. Within this interrupt routine, I have tried reading the incoming byte before writing the return byte and also writing the return byte before reading the incoming. Makes no difference - always get master to slave data but nothing slave to master even though I check that the collision flag is not set.

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

Quote:

but nothing slave to master

"nothing" is not technically possible - after a transfer both slave and master will have some value between 0x00 and 0xFF in their SPDR.

I guess there could be an issue if the slave doesn't get its return value into SPDR before the master starts SCKing but you could solve this if the master sends first a "request value" command then waits a millisecond or two to give the slave a chance to load his return value. Another idea is an extra IO line so the slave could interrupt the master to say "I've loaded SPDR, start clocking". Or the other way round the master could interrupt the slave to say "quick, load SPDR. I'll start clocking very shortly".

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

A standard suggestion is "check line #47 in your code" :lol:

Warning: Grumpy Old Chuff. Reading this post may severely damage your mental health.

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

You are right - I get a random bit value that ramps up to a constant 0xFF.

In the master:
I enable slave /SS

On a 1/800 th second tick from timer 0, I put out a byte to SPDR [0x00 to 0xFF]

I get an interrupt on byte sent

In this interrupt, I read the returned byte from the slave [changes from 0x00 to constant 0xFF - should be 0x07] and put it to a port driving status LEDs.

In the slave:

I wait for byte received interrupt

In this interrupt, I write the next byte to SPDR [0x07] and read the SPDR for the received byte which is the correct value [0x00 to 0xFF].

When I rest both processors, the initial data received by the Master is 0x00. After a few seconds data values build up until the data received is constant 0xFF - it should be 0x07.

Its almost as though the MISO port is latching up as I have to re-programme the master to clear the wrong received value of 0xFF to a wrong received value of 0x00.

Its worth noting that I programme the chip using the SPI facility on the STK600 board which also uses the alternate SPI port pins.

My gut feeling is that the problem revolves round the fact that I'm using the alternate SPI port on the Atmega16M1 hence my question to fellow AVRfreaks - has anyone actually used this chip and the alternate SPI port in real bidirectional mode?

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

I've narrowed the problem down to running on a STK600 and or the Atmega16M1 chip. If I run the attached short programme ported for the Atmega16A it works fine. If I run it as is on the STK600 using the 'regular' SPI ports with MOSI and MISO shorted, I get no interrupt activity.

Any further thoughts from Atmega16M1 fans would be much appreciated.

Attachment(s): 

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

Had a very helpful e-mail from (Dean Camera
Atmel Technical Support Team). Was able to load the hex code and prove it was a problem with my STK600 to socket board connection which when fixed runs the code fine. :D