Mikroe SC16IS740IPW not working

Hardware
1

I am using a Boron as an asset tracker. I also need to connect to equipment over serial while using the serial-based GPS. I know this is not a novel problem. to keep the form factor small, I am using a Mikroe SC16IS740IPW that is two boards in one + the DB9 connnector. It is the SC16IS740 that we know and love for solving this problem, mated to a UART to RS-232 transceiver. It speaks I2C and SPI. Pretty handy for ~$20.

Here are the problems. 1st, you change between i2c and SPI modes by desoldering five SMD jumpers. That is a pain. So, I am trying to get SPI working. I am connecting it the same way you would the SC16IS750 purple board that folks are using.

How it’s acting…

  • It is sending binary 00000000 to my USB to RS-232 adapter every 5 seconds.
  • The green light flashes quickly constantly on the Boron, as I have no reception in my lab in the basement.
  • The other Serial and Serial1 don’t seem to send anything out as I am also monitoring them. They should be sending something every second.
  • RealTerm is showing a solid “BREAK” in the Status.

Thanks for any help!!

IMG_3024
IMG_30243024Ă—4032 2.25 MB
FailedSPItoRS232
FailedSPItoRS232752Ă—598 12.4 KB

Boron Clickboard
GND GND
3.3V 3.3V
MI SDI
MO SDO
SCK SCK
A5 CS

code attached below…

// This #include statement was automatically added by the Particle IDE.
#include <SC16IS740RK.h>

#include "Particle.h"


SYSTEM_THREAD(ENABLED);

//Particle.connected() - use this to check for connectivity

// SC16IS740 extSeriali2c(Wire, 0);
SC16IS740SPI extSerial(SPI, A2);

unsigned long lastTime = 0;

void setup() {
  Serial.begin(9600);
  Serial.write("Serial write in setup()");
  
  Serial1.begin(9600);

  delay(5000);

  //extSeriali2c.begin(9600);
  extSerial.begin(9600);
} 

void loop() {
  

  if (millis() - lastTime >= 1000) {
    lastTime = millis();
    
    //extSeriali2c.print('i');  
    extSerial.print('S');
    
    //extSerial.println('ExtSerial print line');
  
    Serial.write("Serial write in main loop()");
    //Serial.println("Serial print line");
  
    Serial1.write("Serial1 write in main loop()");
    //Serial1.println("Serial1 print line");
    //extSerial.print(out);
  }
}
2

I think you need to flip MI/MO.
MasterIn should connect to the SlaveDataOut (SlaveOut on the chip itself) on the Clickboard while MasterOut would send SlaveDataIn(to) (SlaveIn on the chip itself) the device.

image
image1092Ă—732 40.7 KB

(image credit: https://www.nxp.com/docs/en/data-sheet/SC16IS740_750_760.pdf)

1 Like
3

Thanks for the help. I thought the MO was short for MISO (Master In, Slave Out) and MI was short for MOSI (Master Out, Slave In). I see now, that I was backward on that one; too many O’s and I’s :slight_smile: I switched them up and now it doesn’t send anything. I am still getting the “BREAK” status.

Should the CS on the Clickboard be connected to the Borons’ A5 or A2? What is the purpose of the A2 in the line:

SC16IS740SPI extSerial(SPI, A2);

Also, I used Mariano’s advice and was able to easily move the jumpers over using two soldering irons with fine tips. Very gangster. :sunglasses: Now, I can set up another Boron to try to use the Clickboard in i2c as originally intended. I still want to try to get this SPI working in case the i2c doesn’t cooperate.

Thanks!

4

Since SPI uses a distinct SS line for each individual slave that parameter indicates which GPIO is used to activate that specific sensor.
A5 might be the default SS line on the Boron you don't need to use exactly that but can choose whatever you want as long it is not used otherwise.

1 Like
5

I owe you a beer!!! I moved the CS pin from A5 to A2, rebooted and I am in business!!

I read that the SS line had to be dedicated to the SS function and not be used by anything else. I have seen when working with over boards they will say you can’t use pin X for anything because a library is using it, but that is because it is being mapped internally, not because the pin is physically being used.

I didn’t realize that was the actual pin to connect to the slaves CS. That is why I was confused. Of course it can’t be used by anything else if I am using it for that. That is a redundant statement. That is like saying I can’t also use a SerialSoftware DA port for something else like a motor controller.

1 Like
6


I know you have this link already. It is for others who read this :wink:

So, Rikkas library only seems to allow me to specify an ic2 address between 0-127. However, the Clickboard documents seem to be 144-174 range:

Annotation 2020-03-22 112731

Annotation 2020-03-22 112730
Annotation 2020-03-22 112730598Ă—526 57.2 KB

7

That is normal as the base address is only 7 bit but shifted left one bit where the bottom bit becomes the read/write bit.

You see the X in the table? That is where the direction bit would be.
When you take that bit out (shift right by 1) you will find all addresses will fall into the 0x00 to 0x7F range.

1 Like
8

Thank you. So, my 144 becomes a 72. I’m not sure how to follow Rikkas’ directions in his Readme.
" public SC16IS740 (TwoWire & wire,int addr,int intPin)

Construct the UART object. Typically done as a global variable.

Parameters

  • wire The I2C port to use, typically Wire.
  • addr The address you’ve set using the A0 and A1 pins, 0-3. This will be converted to the appropriate I2C address. Or you can directly specify the actual I2C address 0-127."

He doesn’t say if it should be in decimal or hex or what, although I do see it says 0-127. I’ve tried

SC16IS740 extSeriali2c(Wire, 0x48);

and

SC16IS740 extSeriali2c(Wire, 72);

and neither seem to work

9

Decimal or Hex is irrelevant - a number is a number no matter how you write it.
Just as I could write 10 dots or .......... :wink:

Have you connected A1 and A0 (on the Mikroe) to 3v3 to set the address to 0x48?

You can also run an I2C scanner program to find the actual address.

1 Like
10

So, it works! Thank you so much for being so tenacious with helping on HW you don’t even make. This allows me to move forward for Particle on this solution.

After my first flashing attempt I put it into a 10 blink red SOS state. That was caused by Win10 file location protections breaking things. So, that was fun to fix LOL. I now write locally, cloud compile, and local flash. That is the fastest and most consistent for me.

Point is, I needed to pull the power altogether after the flash and it started working.

Thank you so much for your help. I can now move on to other challenges and get this put together.

1 Like
11

I'm not even a Particle employee :wink:

2 Likes
12

That means you get two beers :wink:

1 Like
13

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.