Does SPI (MOSI/MISO/SS) on ATTiny328/88 work differently from other ATTinys?

Other Hardware 3rd Party Boards
1

Hi,

I have been trying to connect the RFM69CW module to work with ATTiny88, which is pin compatible with ATTiny328. I have working boards on which the RFM69CW module is connected to the ATTiny84 MCU. Reading the connections on that PCB, I get the following table:

             RFM                   ATT84
           -----------------------------------
            5 (MOSI)             8 (MISO)
            6 (SCK)              9 (SCK)
            7 (NSS)              3 (PCINT10)
            8 (MISO)             7 (MOSI)
            9 (DIO0)             5 (INT0)

This works and has been in use for >5 years now.

So I connected the SPI lines on ATTiny88 similarly. It did not work. Following are the connections I used:

          RFM                    ATT88 [Not Working]
       ------------------------------------------------------
           5 (MOSI)            18 (MISO)
           6 (SCK)             19 (SCK)
           7 (NSS)             16 (SS) 
           8 (MISO)            17 (MOSI)
           9 (DIO0)             4 (INT0)

However when I switch the MOSI/MISO lines, it works fine. Following are the connections that work:

          RFM                    ATT88 [Working]
       -------------------------------------------------
           5 (MOSI)            17 (MOSI)
           6 (SCK)             19 (SCK)
           7 (NSS)             16 (SS) 
           8 (MISO)            18 (MISO)
           9 (DIO0)             4 (INT0)

**My question is: Does the SPI work differently on ATTiny328/88 from other ATTinys (like ATTiny84)? **

The above experience suggests that there are differences, but not sure if I am doing something wrong/different which manifests itself as a different SPI behaviour on ATT88 vs ATT84. If there are differences, what are those? Where I can I read about it?

I am using the ATTinyCore for programming the ATT88 from Arduino UNO and the JeeLib library for operating the RFM69CW module. I am also running the ATTiny88 at 1MHz (it will ultimately be powered by batteries).

Thanks.

2

Yes, it does work differently on the 84 vs the 88 - most ATTiny's have a USI, instead of a full hardware I2C and SPI implementation. For parts with the USI, the hardware DOES NOT HAVE THE CONCEPT OF MISO AND MOSI. It has DI and DO - so if the part is acting as master, it's DO is MOSI and DI is MISO, if the part is acting as slave, the reverse is true.

This is described in the ATTinyCore documentation - both in the main README under the SPI section, and under the SPI section of the part specific documentation pages. Can you suggest any change that I could make to the documentation that would have made this clearer?

On the parts with a USI, as stated on the pinout charts, the MISO/MOSI markings refer to the pins to be used when programming the part via ICSP (where the part is, essentially, acting as a slave with the reset pin as chip select); this follows the convention used by Atmel in their datasheets.

3

Thanks very much DrAzzy! This was most useful information. I must admit that I had not read this part of the ATTinyCore documentation. But now I have and I think I understand the difference. I will write it down in my words what I understood and see from there I can make any suggestion for your document. As such, it's quite clear to me now.

Reading other parts of the document I agree with your suggestion to not run the MCUs at the lowest clock rate, particularly for applications where it will in sleep mode for the majority of the time. This is my case too and I recall reading somewhere (sometime ago) that SPI communication with the RFM69CW may have issues at lower clock speeds.

The RFM69 radio isn't yet working on the PCB for me, though I have checked the connections many times. It works on the breadboard with ATT88 with the same connections (there are additional components on the PCB of course, but aren't activated for this test. I.e. they aren't receiving power). I have now also added the 0.1uF decoupling caps between VCC and GND of the RFM69CW module and between AVCC and GND of ATT88. VCC and AVCC are shorted. I wonder if you have any thoughts for debugging this? I understand though that this may not be right forum for that question.

Thanks again.

4

Vcc and avcc are connected internally through a protection diode. You still want each to have it's own decoupling cap, and they still must be connected externally too

Do you have a larger cap somewhere between power and ground? Iirc the rfm modules have the 0.1uf caps they need on board, but may not have larger caps, which are needed if the wires supplying power are long enough that the output cap on power supply is too far away.

Post the designs of the PCB, and the working circuit you have on breadboard - this will help us suggest what the key difference may be

5

Thanks for your time DrAzzy.

Attached with this message is the PCB as a PNG file. It's a 2-sided PCB. The red and blue layers are ground planes on both side.s The entire length of the PCB is about 2in. So the distance between VCC (3.3V) and RFM is about 2in. I have large cap (2200uF) in the circuit but it's not on the 3.3v rails and is not power yet. Its turned on via a MOSFET switch, which also is not power yet (i.e., the large cap is disconnected).

On the top left of the PCB is the RFM module with the decoupling cap immediately on it's right. The MCU is immediately on the left of the RFM. Between the header on the top and the MCU is the decoupling cap for the MCU. Pins 20 is AVCC and 7 is VCC (shorted on the PCB).

The only difference in the PCB is that the PCB shows the following connections

RFM ATT88
5 18
8 17

On the PCB I am using, I have cut those tracks and changed them to

RFM ATT88
5 17
8 18

I can send a picture of the breadboard (which is bird-nest of wires right now :)) if that would help in diagnosis. The wire lengths there are much longer. RFM module is sitting on those wires above the breadboard.

There are two possibilities that come to my mind right now

  1. The RFM module on the PBC is sitting on a ground plane. On the breadboard (and other PCBs I have where the radio works) there is no such ground plane. Could this be a problem in RF transmission/receiving?

  2. The particular RFM module on the PCB is bad. I could replace it with a different one.

Thanks again for your time. I will post the picture of the breadboard anyway, a bit later in the day.

PCB.png
PCB.png964×778 48.6 KB

6

What is the symptom of the problem? Are you getting communication with RFM69, but no no transmission? Are you sure that the antenna pin isn't shorted to something? Is there an antenna connected? (I see pics of people using it with a simple wire as an antenna, which should be the correct length for the frequency it transmits at - range will probably be terribad without the antenna.

Is that an RFM69CW or HCW? The pinouts are completely different for those two, your pinout at first glance looks like the CW one. If you were using the HCW, it would be totally wrong.

Why is one of the ground pads not connected to ground? The plane on the top should be your ground plane, not the power plane, to ensure a good connection to ground. Since the antenna is sticking up from the board, the ground plane I think is desirable, not undesirable (for PCB-trace antennas, you need to keep the area under the antenna free of the ground plane, but for a whip antenna, you want a good ground plane, as that effectively serves as part of the antenna. I would definitely put a larger cap between Vcc and ground somewhere on the board (I'd do 47-100uF, as a default value), since you have no power supply filtering on the board except for the decoupling caps and that giant cap (which will probably create enough of a current surge when finally connected that it resets the board, btw - why is that there?!) - and wires between the 3.3v supply and your board.

If you look at the common breakout boards, you'll notice they have 2 caps, one small one (probably 0.1uF) and a much larger one (probably 10uF ~ 47uF).

7

DrAzzy:
What is the symptom of the problem? Are you getting communication with RFM69, but no no transmission? Are you sure that the antenna pin isn't shorted to something? Is there an antenna connected? (I see pics of people using it with a simple wire as an antenna, which should be the correct length for the frequency it transmits at - range will probably be terribad without the antenna.

I am using RFM69CW. There is no transmission from it. The set up I have is that when this is turned on, the RFM69CW will send a message which is immediately captured by the basestation radio and reported. I don't see that message at all from the unit. I see from other units. And from the RFM69CW on the breadboard.

I have checked for antenna pin short. There is none. But I will check again just to be sure.

The antenna is a simple wire (though I tried a coil-loaded one too) of the correct length -- same length as the ones on units where this works fine (I think about 17.1cm long for 433MHz). The range when it works is quite good (at last 50m through multiple walls -- probably longer).

DrAzzy:
Is that an RFM69CW or HCW? The pinouts are completely different for those two, your pinout at first glance looks like the CW one. If you were using the HCW, it would be totally wrong.

It's RFM69CW. The connections I have checked and they seem to be correct.

DrAzzy:
Why is one of the ground pads not connected to ground?

Did you mean the ground pad of the RFM69CW module? It is connected to the ground. It is pin 3 (antenna is on Pin 1) and is connected to one of the legs of the cap, which in turn is connected to the ground on the power supply header (on the extreme left). It is also connected to Pin 8 of the MCU, which is also grounded.

DrAzzy:
The plane on the top should be your ground plane, not the power plane, to ensure a good connection to ground.

The top (red) and the bottom (blue) planes are both ground planes. There is no power plane in my PCB. Power is supplied via traces.

I have tested this PCB earlier to check the MCU operation without connecting the RFM69CW. That worked just fine. Even now, if I don't care about the radio link the MCU program works fine (e.g., it triggers the solenoid drivers on the bottom edge of the PCB. More details of that part of the circuit below).

DrAzzy:
Since the antenna is sticking up from the board, the ground plane I think is desirable, not undesirable (for PCB-trace antennas, you need to keep the area under the antenna free of the ground plane, but for a whip antenna, you want a good ground plane, as that effectively serves as part of the antenna. I would definitely put a larger cap between Vcc and ground somewhere on the board (I'd do 47-100uF, as a default value), since you have no power supply filtering on the board except for the decoupling caps and that giant cap (which will probably create enough of a current surge when finally connected that it resets the board, btw - why is that there?!) - and wires between the 3.3v supply and your board.

I think so too (ground planes for a whip antenna are good). That's why I put those planes. But was just wondering if I am missing something here. Thanks.

I will put a larger cap between VCC and GND.

The power supply I am using is already stable. It's from Arduino (3.3v supply), or 2xAA batteries or from a very stable power supply unit in a lab. So felt that that won't be a problem. Do you agree?

The 9V supply, which powers the large 2200uF cap, is from separate 6xAA battery pack. I don't expect a glitch in the MCU/RFM69CW power when the large cap turns on. Indeed, I don't see it in the 2-port version of this that is working (details below).

This is PCB is for a remotely controlled 6-port sprinkler controller which DC Latching solenoids. They need a 20millisec pulse between 6-9V to operate (of opposite polarity to open/close). The H-bridge drives at the bottom of the PCB can each drive two solenoids and can handle 2A current -- certainly for 20msec. Pulse is powered from the 9V supply via the 2200uF cap, which is turned-on for the H-bridge drivers via a MOSTFET switch. The program on the MCU wakes up the appropriate H-bridge breakout board, turn-on the MOSFET, deliver a pulse of 40msec (just to be safe). Then it shuts down the MOSFET cutting off the 9V supply to the drivers, and puts them to sleep.

The diodes are there to stop reverse connection (which are in the details of the H-bridge driver boards) which eventually left the 9V supply connected to ground (with some effective resistance in between). That drained the 9V battery faster than expected. With this circuit and the diodes, the 3.3V and 9V supplies will last for many years (my estimate from operating a 2-port version for over a year now).

I have this circuit, with the RFM69CW module working for two ports and using ATT84. This circuit is really just a extension of that one, with the MCU replaced by ATT88 (for extra DIO lines). And of course a new PCB.

The 2-port unit which is working wonderfully for the past year, has the ATT84 and the RFM69CW on a separate board while the H-bridge driver and MOSFET circuit is on a different PCB. The two PCBs are connected with jumper wires on the headers on both PCBs. The PCB of the 2-port circuit which works is here.

The 3.3V circuit (which powers the MCU and the RFM69CW only) is therefore not affected by the presence of the 2200uF cap. The whole circuit, with the radio communication, works for the two port circuit. Herein lies my confusion: why is the RFM69CW not working on this 6-port PCB?!

DrAzzy:
If you look at the common breakout boards, you'll notice they have 2 caps, one small one (probably 0.1uF) and a much larger one (probably 10uF ~ 47uF).

8

There are two ground pads on the RFM69CW, though. You only have one connected (also, you have a mysterious trace drawn from one of them, despite that there is a ground plane, which is strange, but shouldn't be the cause of the problem). Both of those ground pads should be connected.

From the perspective of the ATTiny, is the RFM69CW talking to it, or are the SPI transactions failing or returning incorrect results?

9

DrAzzy:
There are two ground pads on the RFM69CW, though. You only have one connected (also, you have a mysterious trace drawn from one of them, despite that there is a ground plane, which is strange, but shouldn't be the cause of the problem). Both of those ground pads should be connected.

Good point. Thanks. I will connect the other ground pad to GND.

When writing the earlier reply, I also realized that there is a track going from the GND pad of RFM69CW all over, which should be connected to the ground plane right there! I think it's because the way I made the PCB. Thanks for pointing this out. I will fix this in the next version.

DrAzzy:
From the perspective of the ATTiny, is the RFM69CW talking to it, or are the SPI transactions failing or returning incorrect results?

Good question. I don't know the answer, but will try to find out. One problem is that there is no easy way for me to get a message from the MCU other than via the radio. I will check by letting the program flow go beyond initializing the RFM69CW and change the state of the pin(s) on ATT88. The JeeLib's call to init. RFM69CW does not return if the communication with the RFM69CW module is not proper. If that happens, the expected change on the ATT88 pin(s) won't happen.

10

Yup. You could also use SoftwareSerial, or the builtin Serial (which is also software serial, but uses the Analog Comparator interrupts on fixed pins, leaving the PCINT ISR free for your application)... (See the part-specific docs for details)

But I think for something this simple, toggling pins will work fine.

11

Some updates below:

DrAzzy:
There are two ground pads on the RFM69CW, though. You only have one connected (also, you have a mysterious trace drawn from one of them, despite that there is a ground plane, which is strange, but shouldn't be the cause of the problem). Both of those ground pads should be connected.

On more careful examination, it turns out that the PNG file I attached earlier of the PCB was at a low resolution, due to which it appeared that there is a "mysterious track" instead of a direct connection to the ground plane. Attached is a higher resolution PNG file, which better shows the PCB as it is in reality. One of the ground pads of the RFM69CW is immediately connected to the ground plane.

DrAzzy:
From the perspective of the ATTiny, is the RFM69CW talking to it, or are the SPI transactions failing or returning incorrect results?

My tests over the weekend suggests that the RFM69CW module is getting initialized, and the JeeLib calls to Tx and Rx both return without error. Just that Tx from this radio is never found by the basestation radio and packets from basestation radio are never received by this radio. Though for a brief moment, a single packet sent from this radio was received at the basestation (the code should send a ping packet every 5 sec). Not really sure what's going on then. Perhaps some timing issues in talking with the radio?

I did notice that when I ported the code that runs very reliably on ATT84 to ATT88, on ATT88 it is rather sensitive to the exact sequence of calls before and after JeeLib calls for Rx and Tx. I will soon try a bare minimum program on the ATT88 for Tx only. And then for Rx only and see if I can find something that points to the source of the problem.

Another annoyance I have on the PCB right now is that I can't program the ATT88 while it is on the PCB. For that, I need to pull the RFM69CW's NSS line (pad 7) high so that it does not get selected as a SPI device. I did not anticipate this and therefore don't have a jumper to change Pad 7 connection to ATT88's Pin 16 to VCC (to pull Pad 7 high). So it's just quite painful to program the ATT88 right now -- take it out, to program, then put it back every time!

Meanwhile, if you have suggestions please let me know.

PCB.png
PCB.png1924×1550 168 KB

12

Connect the second ground pad to the ground plane - scratch off some of the solder mask on the ground plane next to that second ground pad and connect it with an ugly blob of solder. I'm concerned that they may have the two ground pads laid out so that one is more tightly coupled to the digital power, and the other to the RF section, and if only one is connected, noise from the digital side would be coupled more strongly to the RF section. Since, as you say, your previous designs used the RFM69CW on a breakout board, that would have done the ground connections correctly and thus prevented you from encountering this problem.

Do you have a larger cap in place across power and ground yet? (you can tack a second cap to the bottom of the pins - I do that when I realize I needed more decoupling than I had)

Next rev of your board, put a pullup on NSS; this is the standard solution here.

13

DrAzzy:
Connect the second ground pad to the ground plane - scratch off some of the solder mask on the ground plane next to that second ground pad and connect it with an ugly blob of solder. I'm concerned that they may have the two ground pads laid out so that one is more tightly coupled to the digital power, and the other to the RF section, and if only one is connected, noise from the digital side would be coupled more strongly to the RF section. Since, as you say, your previous designs used the RFM69CW on a breakout board, that would have done the ground connections correctly and thus prevented you from encountering this problem.

I will connect the other ground as you suggest. Should be simple enough.

DrAzzy:
Do you have a larger cap in place across power and ground yet? (you can tack a second cap to the bottom of the pins - I do that when I realize I needed more decoupling than I had)

This I haven't done yet since I don't have a cap in the 47-100uF range. That would be quite big (physical size) to be comfortably under the PCB also. But I will put one as soon as I have one.

DrAzzy:
Next rev of your board, put a pullup on NSS; this is the standard solution here.

Oh I can't thank you enough for this suggestion. While it may be obvious to experienced designers, it wasn't to me till you mentioned. And it's so useful that I have put one on the breadboard already (where also, without this I was connecting/disconnecting ATT88 Pin 16 to VCC!). I can now program ATT88 on the breadboard without any problem. This is so useful that before I do anything else, I am going to figure out how to put a 10K resistor across Pad 7 (NSS) and Pad 2 (VCC) of the RFM69CW module on the PCB!

I also realized that I was running the ATT88 at 1MHz. The interrupt timing of JeeLib recommends no slower than 4MHz (I just forgot about this recommendation). I feel now running at 8MHz, much of the otherwise delicate timing in the ping-pong program has become much more robust. Also wondering if the pull-up on Pad 7 has stabilized the ATT88<-->RFM69CW SPI communication. If so, it might work on the PCB also now. But of course, as I said, the pull-up on the PCB first :). That one is surely going on the next rev of the PCB.

Thank you very much for your time so far. I will report back here as soon as I have anything significantly new.

14

I connected the 10K pull-up between Pad 7 (NSS) and 2 (VSS) of RFM69CW. With that, and the MCU running at 8MHz fixes the problem on the PCB! Phew.

To be sure that the MCU running at 8MHz does matter, I loaded the bootloader with 1MHz setting and loaded my program again. Clearly, I was able to program the ATT88 on the PCB due to the pull-up resistor (much relief). But the pings stopped coming. Back to 8MHz bootloader and re-loaded my program and ping-pong is back and very stable. So yes, the MCU needs to run at least at 4MHz.

I am able to command it remotely also. I.e., both Rx and Tx modes are working fine. In a few days I will connect the H-bridge drivers, test their operation. If all that passes, will try it on the field.

Your help DrAzzy was most crucial and I can't thank you enough for your time. Love these forums and hope to contribute back to it as well.

As a passive contributions, following is some more useful information in case someone with similar problem(s) wanders around here:

  • I checked that the second GND Pad (Pad 14) on RFM69CW breakout board is shorted with Pad 3 (also GND). On my PBC Pad 3 is firmly connected to the ground plane. Then I don't think it is necessary to connect Pad 14 also to GND. Do you agree DrAzzy? Since it can't hurt, in the next rev of my PCB, I am going to connect it anyway.
  • My original reason for running the ATT88 at 1MHz was that it increases the range of it's operating voltage:
    1MHz: 1.8--5.5V.
    8MHz: 2.7--5.5V.
    However clearly, JeeLib driver needs at least 4MHz clock. Running the ATT88 at 8MHz with the 10K pull-up resistor across Pads 2 and 7 of the RFM69CW has made the radio operations quite stable and robust.
15

so if the part is acting as master, it's DO is MOSI and DI is MISO, if the part is acting as slave, the reverse is true.

On the parts with a USI, as stated on the pinout charts, the MISO/MOSI markings refer to the pins to be used when programming the part via ICSP (where the part is, essentially, acting as a slave with the reset pin as chip select); this follows the convention used by Atmel in their datasheets.

I have been using the ATtiny84 and 85 for some time.

Not having used SPI for any peripheral, I am currently using I2C, I actually missed the DO/DI part. I obviously lucked out on the ICSP programming due to the labeling convention.

I would definitely have fallen foul of the DO/DI function change if I tried to use a SPI device.

Thanks for the reminder of the details (I hope I remember it when the time comes to use SPI - seems we never stop learning).

Willem.

16

sanbee:

  • I checked that the second GND Pad (Pad 14) on RFM69CW breakout board is shorted with Pad 3 (also GND). On my PBC Pad 3 is firmly connected to the ground plane. Then I don't think it is necessary to connect Pad 14 also to GND. Do you agree DrAzzy? Since it can't hurt, in the next rev of my PCB, I am going to connect it anyway.
  • My original reason for running the ATT88 at 1MHz was that it increases the range of it's operating voltage:
    1MHz: 1.8--5.5V.
    8MHz: 2.7--5.5V.
    However clearly, JeeLib driver needs at least 4MHz clock. Running the ATT88 at 8MHz with the 10K pull-up resistor across Pads 2 and 7 of the RFM69CW has made the radio operations quite stable and robust.

Glad it works like that. I would 100% connect that pad in the next rev though; I suspect it is there to improve noise rejection or something like that. You don't know that there modules don't have an analog and digital portion of the ground, connected by an inductor to keep high frequency noise from passing between them - this would look like a short to a multimeter.

1.3.3 of ATTinyCore will add new clock options to at least the t88 - I think I'll do a 4MHz internal clock option for all boards that don't already have it, in the interest of the board being able to reach it's minimum voltage spec at the highest supported clock speed.

17

Hi all,

I have been using ATTiny88 in my projects, but am now planning to experiment with ATMega328P-PU chips. The ATTIny88 are pin-compatible with ATMega328P-PU. So physically, I would be able replace ATT88 with ATM328 chips on my PCB.

My question is about the SPI interface. Earlier DrAzzy pointed out that the ATT88's SPI behaviour is different from that on other smaller ATTiny's (like ATTiny84). Basically, I had to change the MOSI/MISO lines for ATT88 compared to what I was using on ATT84.

Would my sketch that works with ATTiny88 continue to work with ATMega328P also without need to change any of the SPI connections? I.e., is the SPI implementation on ATMega328 same as that on ATTiny88? The MCU talks to the RFM69CW module on-board via SPI lines.

Regards,

18

sanbee:
Hi all,

I have been using ATTiny88 in my projects, but am now planning to experiment with ATMega328P-PU chips. The ATTIny88 are pin-compatible with ATMega328P-PU. So physically, I would be able replace ATT88 with ATM328 chips on my PCB.

My question is about the SPI interface. Earlier DrAzzy pointed out that the ATT88's SPI behaviour is different from that on other smaller ATTiny's (like ATTiny84). Basically, I had to change the MOSI/MISO lines for ATT88 compared to what I was using on ATT84.

Would my sketch that works with ATTiny88 continue to work with ATMega328P also without need to change any of the SPI connections? I.e., is the SPI implementation on ATMega328 same as that on ATTiny88? The MCU talks to the RFM69CW module on-board via SPI lines.

Regards,

Yeah, the t x8 has the full SPI module, like the m328p does, and on the same pins.

It's only parts with a USI where the MISO/MOSI markings on the pinout charts are just for ISP programming, and so for SPI you need to wire up DI and DO as MISO or MOSI depending on whether it's a master or slave. Note that doing the wiring here right should be all you have to do on those parts (the SPI.h bundled with the core will figure out whether there's a USI or SPI peripheral, and presents the same API)

19

Thanks DrAzzy. I already have the wires connected such that it works with ATT88. From what you wrote, I understand that then nothing needs change if I were to replace the ATT88 with ATM328p on my PCB. If I misunderstood something, could I request you to let me know. Thanks.

My original wiring on the PCB was indeed incorrect. The earlier wiring was based on what worked with ATT84 which, as you explained earlier also, does not have the full SPI module (has USI?).

Regards,