SPI Communication Problem on Pro Mini / 5V @ 16MHz

Projects Networking, Protocols, and Devices
1

I'm connecting up to a high resolution ADC (TI's ADS1247) via SPI bus and am able to initialize the device and read back the configuration registers and get it to do everything I want it to using my Arduino Mega 2560 (including take an extremely precise read from a PT100 RTD).

But when I try to use a Pro Mini, it fails completely. I have no clue what's going on short of there being an underlying configuration problem with the SPI bus. Ground planes on the Pro Mini are all tied together, and the devices are being powered from the USB-FTDI board. I've also tried dropping in a 0.1uF decoupling cap between Vcc and Gnd to no avail. I have tried different delays and wait times while initializing the bus and at key points (soft reset of the ADC etc).

Here's a subset of the code that I'm using:

  SPI.setClockDivider(SPI_CLOCK_DIV16);
  SPI.setDataMode(SPI_MODE1);
  SPI.begin();
  SPI.transfer(0x06); //Reset
  delay(1000);
  SPI.transfer(0x14); //SDATAC
  SPI.transfer(0x4B); //Set IDAC1 Register (0Bh) Write 01h - Output reference current on ANIN0,1
  SPI.transfer(0x00);
  SPI.transfer(0x01);
  SPI.transfer(0x4A); //Set IDAC0 Register (0Ah) Write 07h - Select 1.5mA reference current for RTD
  SPI.transfer(0x00);
  SPI.transfer(0x07);
  SPI.transfer(0x43); //Set SYS0 Register (03h) Write 52h - PGA:32, Sample at 20sps
  SPI.transfer(0x00);
  SPI.transfer(0x52);
  SPI.transfer(0x42); //Set MUX1 Register (02h) Write 30h - Select internal reference always on, internal ref connected to REF0 pins. Use 33h if wanting an on chip temp read.
  SPI.transfer(0x00);
  SPI.transfer(0x30);
  SPI.transfer(0x40); //Set MUX0 Register (00h) Write 01h
  SPI.transfer(0x00);
  SPI.transfer(0x08);

Register data is dumped via a 1s loop of:

  //Register Dump
  SPI.transfer(0x20);
  SPI.transfer(0x0F);
  for(int i=0; 16>i; i++)
  {
    A2DVal = 0x0;
    A2DVal |= SPI.transfer(0xFF);
    Serial.println(A2DVal,HEX);
  }
  Serial.print("\n\n");
  
  delay(1000);

Like I said, it works flawlessly on the Mega 2560 so I don't understand why the Pro Mini is on the struggle-bus. Any ideas?!!

Cheers,

Josh.

2

You don't show any code controlling the Chip Select / Slave Select line.

3

SS is tied to ground permanently as it's the only device on the bus, and pin 10 is left floating on the Arduino. Regardless, I'm not sure why it would work with one board but not the other.

4

Thx @johnwasser - you got me thinking about the SS line on my walk home from work today. I wondered if in enabling the SPI bus whether it was glitching out the SCK, MISO and MOSI lines and that was confusing the ADS1247. So rather than permanently tie the SS line to ground in my original design, I tied it to the SS line on the Pro Mini. With SS set to output, we can safely toggle this bit without disrupting Master communication on the SPI bus (DDB2 must be set in DDRB) and thus use it to control SS on the ADS1247. The following bit of code solved everything.

  DDRB |= (1<<DDB5) | (1<<DDB3) | (1<<DDB2); //Set SCK, MOSI, SS Pins as Output
  PORTB |= 1<<PORTB2; //Pull SS High to Disable Communications with ADS1247
  SPCR = (1<<SPE) | (1<<MSTR) | (1<<SPR0) | (1<<CPHA); //Enable SPI, Set Master, f/16 CLK, Mode 1
  PORTB &= ~(1<<PORTB2); //Pull SS Low to Enable Communications with ADS1247

Cheers!

Josh.

5

A lot of SPI devices say that CS should be high at initialization time - its usual practice to add a physical pull-up resistor to ensure this is the case as the microcontroller is itself initializing. Some rather more carefully designed devices include a weak pull-up on their CS line.

I'd certainly never expect an SPI device to work with CS tied to ground, each transaction requires CS to go low at the start and high at the end.

6

Hey MarkT - Thanks for this. The ADS1247 datasheet says that CS can be tied directly to ground, however this is not recommended. Now I know why :).

Thx again!

Josh.