Problem with SS pin Arduino Micro

Development Tools IDE 1.x
1

Hello!

Firstly, I've googled all day and haven't find anything really usefull to solve my problem.

I'm using Arduino Micro (Tried several of them), software 1.0.5-r2. Windows 7.

I want to communicate over SPI with several devices, and wanted to use the SS pin of the Arduino Micro as the Slave Select pin for one of the devices. The problem is not about the SPI, but the SS pin.

In my understanding ...the SS pin can be used as an I/O digital pin, and just as an Output pin while using the SPI library.

But...it doesn't seem to work at all. As I said, I know it must be configured as an output pin before starting the SPI library..but even without using the library, It doesn't seem to respond. The RX Led flickers when the program is uploading, and after that it remains OFF. Setting the SS Pin HIGH does not make any change.

I've tried "SS" and "17" in the digital pin functions.

The following is a simple sketch, which should turn ON the RX light (connected to the SS pin). Everything is done in the setup(). The SPI library is not used in this example...the SS pin should respond anyway, shouldn' it?

void setup()
{
  pinMode(SS, OUTPUT);
  digitalWrite(SS, HIGH);
}

void loop() 
{
}

Am I missing something?? Am I doing wrong assumptions?

Any comments and suggestions are welcomed. Thanks a lot!

2

The Arduino Micro ?
http://arduino.cc/en/Main/arduinoBoardMicro
It uses the ATmega32u4 chip:

You have read information for the Arduino Uno. That board has SS at digital pin 10, and it should be set as output to make the SPI work.
The hardware for the SPI inside the microcontroller is a little different for the ATmeg32u4. I think you don't have to set SS as output anymore.

The Arduino Micro uses a mix of hardware and software for the serial port via usb and to upload sketches, and the RXLED is connected to SS. That is in the bootloader, but also in the sketch (for the Serial functions). I think you better not use the SS pin at all.

Choose one of the pins of the Micro board, either a digital pin or analog pin. Use it as chip select and set it high or low as needed. That's all. Just forget the whole 'SS'-pin.

3

Can't forget SS entirely, the slave device(s) still need to see it being controlled to tell them to come on line.

As for a specific pin:

Did your test include
byte SS = 17;

If you had
pinMode(17, OUTPUT);
that should have worked as well.
Your LED had a current limit resistor, and the LED is not reversed? (short lead, flat spot on body) is the cathode, it goes to Gnd.

4

From Atmega32U4:

17.1.2 Master Mode
When the SPI is configured as a Master (MSTR in SPCR is set), the user can determine the direction of the SS pin.
If SS is configured as an output, the pin is a general output pin which does not affect the SPI system. Typically, the pin will be driving the SS pin of the SPI Slave.
If SS is configured as an input, it must be held high to ensure Master SPI operation. If the SS pin is driven low by peripheral circuitry when the SPI is configured as a Master with the SS pin defined as an input, the SPI system interprets this as another master selecting the SPI as a slave and starting to send data to it. To avoid bus contention, the SPI system takes the following
actions:

  1. The MSTR bit in SPCR is cleared and the SPI system becomes a Slave. As a result of the SPI becoming a Slave, the MOSI and SCK pins become inputs.
  2. The SPIF Flag in SPSR is set, and if the SPI interrupt is enabled, and the I-bit in SREG is set, the interrupt routine will be executed.
    Thus, when interrupt-driven SPI transmission is used in Master mode, and there exists a possibility that SS is driven low, the interrupt should always check that the MSTR bit is still set. If the MSTR bit has been cleared by a slave select, it must be set by the user to re-enable SPI Master mode.
5

Thanks Both.

Peter_n:

I know Micro has diferent hardware than Uno. But in the reference (they talk about leonardo as one of the examples) they say:

Note about Slave Select (SS) pin on AVR based boards

All AVR based boards have an SS pin that is useful when they act as a slave controlled by an external master. Since this library supports only master mode, this pin should be set always as OUTPUT otherwise the SPI interface could be put automatically into slave mode by hardware, rendering the library inoperative.

It doesn't say the ouput step shouldn't be taken with the leonardo (32u4).

The issue about the SS pin is that i'm running out of pins in my project :sweat_smile: , and would like to use it if possible.

CrossRoads:

I tried pinMode(17, OUTPUT); with same result.

About the led...it turns ON on when the SS state is HIGH, that's clear... please don't miss the point. I just talked about the led because is a faster way of checking the state of the output, than measuring its voltage with the multimeter.

About the 32U4 datasheet text, I had already read that, and that's definitely where I read that it could be used as any other digital input pin...and not in the library or in the forum.. :roll_eyes: Any way, I see two parts.

First part (The one we are intested in):

When the SPI is configured as a Master (MSTR in SPCR is set), the user can determine the direction of the SS pin.
If SS is configured as an output, the pin is a general output pin which does not affect the SPI system. Typically, the pin will be driving the SS pin of the SPI Slave.

Second part (we ignore this part, as SS is set as output):

If SS is configured as an input, it must be held high to ensure Master SPI operation. If the SS pin is driven low by peripheral circuitry when the SPI is configured as a Master with the SS pin defined as an input, the SPI system interprets this as another master selecting the SPI as a slave and starting to send data to it. To avoid bus contention, the SPI system takes the following
actions:

  1. The MSTR bit in SPCR is cleared and the SPI system becomes a Slave. As a result of the SPI becoming a Slave, the MOSI and SCK pins become inputs.
  2. The SPIF Flag in SPSR is set, and if the SPI interrupt is enabled, and the I-bit in SREG is set, the interrupt routine will be executed.
    Thus, when interrupt-driven SPI transmission is used in Master mode, and there exists a possibility that SS is driven low, the interrupt should always check that the MSTR bit is still set. If the MSTR bit has been cleared by a slave select, it must be set by the user to re-enable SPI Master mode.

The whole text talks about SS pin when using SPI hardware...I'm not using the SPI library in that simple example :S (altough I would like to do so hehe).

I also tried setting manually the DDRB and PORTB registers (SS is on PB0 I think)...same behaviour.

6

I am confused - in the first post, you said "Setting the SS Pin HIGH does not make any change."
In the last post you said "About the led...it turns ON on when the SS state is HIGH,"
So I'm not certain what the problem is. Is the pin going High & Low as commanded, or isn't it? Is something else connected to the pin to prevent it changing?
Or is it as Peter_N suggested in that SS is not brought out to a header?
That was my problem with some (all?) of the 32U4 based board designs - the IO was available on the chip, but wasn't brought out to a header for our use. One had to tack wires on the board to access the signal.

7

TonySnes, tell us about your project and pin usage. We might be able to free one or two normal pins. You can use the analog pins as digital pins for example.

8

CrossRoads :

You are missunderstanding me. The problem is: I'cant control the state of the SS output from the program. Its state after the program starts is always LOW, no matter I use the digitalWrite(SS,HIGH) function or not.

Apart from that, and talking in general terms, the LED brights when the SS state is HIGH . I mean... as a fact...taking into consideration the board design. I'm not saying I could manage to set the SS state HIGH while the program is running, I'm saying what happens when there's 5V on that PIN. For example, while the program is uploading, the RX led flickers (because the SS is being succesfully controled from the bootloader...but I can't control it anymore from the program).

During the tests there's nothing connected (externally) to the SS PIN.

The SS pin/header of the Arduino board is fisically connected to the SS pin of the chip (SS/PCINT PB0, Pin 8 of the 32u4). The SS pin is connected to the RX_LED through a 1K resitor.

Peter_n:

As a matter of fact, there are still unused pins in the actual design of my project , but I need to reserve some of them for expansion purposes... as future upgrades to the hardware are expected.

It's similar to an arduino Board...where shields can be attached trough a port. Those shields could be added for additional functionality, if needed, over the initial hardware. But those upgrades are still not defined or documented. In fact, the kind of improvements that can be achiveded by means of those upgrades, will totally depend on what free pins are still avariable.

The SPI communication is needed for the initial hardware design. Because of that, It's preferably to use the SS pin for the selection of one of the currently used SPI devices (in theory the SS pin can be used just as a digital output pin), instead of a Digital(PWM)/Analog Pin, which is more interesting for the expansion port.

We are getting off the subjet: The SS pin is a header of the Arduino Micro board, connected to the SS pin of the 32u4. It was placed there to be used, and there must be some way to use it as a digital output. That is the problem to be solved.

The help of someone with experience with the Arduino Micro and the SS pin would be welcome!

Thanks.

9

The SS pin not available during the boot, that is okay, it is used as RXLED output pin.
I have not tested myself if it is also RXLED pin in the sketch with the Serial communication.

But there is still confusion. Since when is the SS pin on a header of the Leonardo board ? which header, which pin ? As far as I know, it is not ment to be used and it is not on a header.

10

The problem is now missing, but not solved.

I'tried powering the board externally (not through USB). After reset, the SS pin worked as espected.

I thought: OK, if the micro detects an USB connection.. then it disables SS pin during program run, because It could be used to light the RX led...

But now......... it works no matter how it is powered (I mean.. with or without USB connection during boot).

So......what has happened?? Why the SS pin was not responding before???

All this made me think another thing. What if I use the serial connection during program (serial or serial1) , and I don't want the library to use the RX_LED??? because I'm using the SS pin for other things...

11

Peter_n sorry, I deleted the other post xDD, please read the last one.

By the way, the SS pin is not avariable on a header of the Leonardo board, but it is in Micro. Actually, it is named RX_LED/SS.

12

Thanks TonySnes, this is new for me. I don't have a Arduino Micro :roll_eyes:

Here is the same discussion : Need some help on ATMEGA32U4 pins mapped to Arduino micro - Other Hardware Development - Arduino Forum

I think it always will be used by the bootloader.
When the Serial is not used, will it still be controlled by the code that was uploaded with the sketch ? I don't know, that is something to test.

13

I've just checked what happens if I use the Serial library....as espected, it controls the RX_LED (SS pin) during reception of data...even if I set it HIGH or LOW anywhere around the program...

Perhaps changing some defines or macros.....I found some macros in the header of the arduino Micro: RXLED0 RXLED1, which seems to be used for turning ON/OFF the leds... the serial libraries might use these macros...will keep you informed.

PD: Well in that post they also talk about those macros...and the USB library...will try to redefine those macros...for a ; or something hehe.

14

In the Micro header:

C:\ [...] \Arduino\hardware\arduino\variants\micro\pins_arduino.h

By replacing:

#define RXLED0       PORTB &= ~(1<<0)
#define RXLED1       PORTB |= (1<<0)

with:

#define RXLED0       1
#define RXLED1       1

The RX_LED (SS pin) is no longer used during the USB serial reception of data ( in the program ). Consequently, the SS pin can be safely used as a digital output pin, without the serial library messing around. The pin is defined as an ouput in the same header... if it is to be used as an input, that part might also have to be modified. Remember that it must be set as an output when the SPI library is being used.

RXLED0 and RXLED1 are macros used in USBcore.cpp, normally followed by a semicolon, as functions. If the macro is replaced by an space for example, it gives compilation problems in some parts of code. "1" is a "TRUE" stament...wich will generate no aditional code I suppose, and I think is a safe replacement for that macro...and there's no need of touching more code in other headers or sources.

I also tried writing:

#undef RXLED0
#undef RXLED1
#define RXLED0        1
#define RXLED1        1

In the top of the sketch, before the #include Serial.h, but it doesn't work...
It might be compiled after the USBcore.cpp.... so we have to modify the pins_arduino.h header.

This method has not been tested with the Serial1.h library. Notice the "1" in Serial1.h, is the TTL serial comunication on pins 0(RX) and 1 (TX)...which I suppose also uses RX and TX leds...

15

TonySnes:
This method has not been tested with the Serial1.h library. Notice the "1" in Serial1.h, is the TTL serial comunication on pins 0(RX) and 1 (TX)...which I suppose also uses RX and TX leds...

The pin 0 (RX) and pin 1 (TX) go to the ATmega32u4 chip directly and there is no software running in the Leonardo/Micro that uses anything with it. In my opinion, the Serial1 (the 'serial-one') has nothing to do with the RX led.

16

Well, then there will be no problems with SS pin and the serial-one library 8), thanks!

If Someone knows an easier way of "disabling" the RXLED0 and RXLED1 macros...please let us know.

However, we still don't know why the SS pin dind't work in my first's attemps...nothing has really changed in the program...it's curious it "came to live again" after powering the board with no USB connection... but well, I'm prone to this Kind of unreproducible problems...this one will appear again sooner or later :~.

Until then...thanks every one!