Help with SPI component

[fotios]

Hi everyone.

I try to establish SPI communication between a P16F18877 (master) and a Semtech SX1272-LoRa module (slave) without success.
I try to read the status registers but the Return byte is always 186d.
For example, when I try to read the register 0x42 which contains the Semtech ID revision number which is 0x22, the SPI read access returns 186d (0xBA).
I checked the SPI bus with the scope, and I have seen pulses on all 4 lines (MISO, MOSI, SCK, CS).
I have tried any possible combination of SPI component properties (clock polarity, clock phase, sample point) but the result is the same.
Could you check please if there is an error on my properties setting?

properties.jpg (73.73 KiB) Viewed 14495 times

Here is the SPI bus specification of SX1272

spi_specification.jpg (71.86 KiB) Viewed 14495 times

Thanks

[fotios]

Here is the SPI Write macro

spi_write.jpg (29.9 KiB) Viewed 14493 times

Here is the SPI Read macro

spi_read.jpg (32.26 KiB) Viewed 14493 times

I should refer that, with the same SPI Read-Write macros I have success in the communication of the P16F18877 with an ATM90E32AS energy monitor IC connected to SPI Channel 1.
The Semtech SX1272 is connected to SPI channel 2 of P16F18877.
However, I haven't tried both SPI channels working simultaneously so far.

Having your review regarding the FC SPI component properties and the FC Read-Write macros, I could make later a question in RF-Solutions which is the provider of the LoRa module.

Thanks for any help

[fotios]

The application system clock is the P16F18877 INTOSC running at 8MHz.
The SCK prescaler is set to Fosc/16 so the SCK = 500KHz.
In the previous post, you could see on the FC pics the setup time from SS Enable (CS Low) to MOSI and MOSI to CS High that is 5μsec.
I think both are within the range of SX1272.
Here the SPI timing specification of SX1272:

SPI_timing.jpg (79.25 KiB) Viewed 14486 times

Thanks

[fotios]

Attached is a small FCF with the SPI macros.
You could see the last SPI Write 0x01 to SX1272 OpMode Register (Address 0x01).
I try to Read it later and returns 194d (0xC2) instead of 1d (0x01).
The same applies to the Version Register (0x42), in SPI Read returns 194d (0xC2) instead of 0x22 (34d) which is the SX1272 ID silicon version.
If I try to read any other register, the return value is always the same 194d.
I use a 4X20 LCD to follow the values.
You should note that the SDO2 (MISO2) is mapped to RB3.
The SS2 (CS2) is mapped to RB4 while, by default is mapped to RB0. But the PPS (remapping) is executed within the Component Properties window?
Checking the actual hardware with the scope, the MOSI signal appears as High To Low transitions (so idle = High) while the MISO signal appears as Low To High transitions (so idle = Low).
I also checked the SPI channel 1 where is connected the other slave ATM90E32, with the scope. Here the things are inverted, MOSI Low To High transitions and MISO High To Low transitions.

Thanks

LoRa_SPI.fcfx

(24.5 KiB) Downloaded 381 times

[fotios]

Hi everyone

In my hardware, the SCK 2 and SDI 2 (MOSI) are mapped to the default ports RB.1 and RB.2 respectively.
The SDO 2 (MISO) is mapped to RB.3.
Only the SS 2 is remapped to RB.4 instead of the default port RB.0

Today I tried any possible change on FC.
In both SPI Write and SPI Read macros I also enabled-disabled the RB.0 beside the RB.4 (SS 2).
The result is the same, while I send SPI Write 0x81 to register 0x01 when I try to read it back the SPI Read returns 194d (0xC2).
I exchanged the MOSI and MISO by remapping them at RB.3 and RB.2. The read returns now 255d (0xFF).
I also moved the SPI component to Channel 1. The read returns 0.
I also moved the other peripheral ATM90E32 which is working fine on SPI channel 1, to channel 2. All reads return 0.
I checked the SPI1 and SPI2 definitions on C code line by line but there are some supplementary defines that I don't understand.

Code: Select all

/*========================================================================*\
   Use :cal_spi1
       :Variable declarations
       :Macro function declarations
\*========================================================================*/
#define MX_SPI_SS_TRIS_1 tris
#define MX_SPI_MISO_PORT_1 portb
#define MX_SPI_SCK_TRIS_1 trisb
#define MX_SPI_SCK_PIN_1 (1)
#define MX_SPI_MOSI_TRIS_1 trisb
#define MX_SPI_BMODE_1 (2)
#define MX_SPI_MISO_TRIS_1 trisb
#define MX_SPI_MOSI_PIN_1 (2)
#define MX_SPI_MISO_PIN_1 (3)
#define MX_SPI_SS_PIN_1 (0)
#define MX_SPI_PR_SCALE_1 (16)
#define MX_SPI_SS_PORT_1 port
#define MX_SPI_SCK_PORT_1 portb
#define MX_SPI_MOSI_PORT_1 portb
#define MX_SPI_CHANNEL_1 (1)


/*=----------------------------------------------------------------------=*\
   Use :cal_spi1
       :Supplementary defines
\*=----------------------------------------------------------------------=*/
#define MX_SPI_REF1
#define MX_SPI_REMAPPABLE_1 1
#define MX_SPI_MOSI_RPOR_1 RB2PPS
#define MX_SPI_MOSI_SDO_1 21
#define MX_SPI_CLK_RPOR_1 RB1PPS
#define MX_SPI_CLK_SCK_1 20
#define MX_SPI_MISO_RPINR_1 SSP1DATPPS
#define MX_SPI_MISO_RP_1 11

In my common sense, there are two cases:
Either in my FC code, there is a bug that I can't locate, or the Flow Code SPI channel 2 has a bug.
The case of a hardware mistake or a faulty device is very difficult because I have built two identical boards to make the tests.
The last case is the two RF-Solutions LoRa modules that I have mounted on my two boards, to be deficient. I don't say that is impossible, but it is very difficult to happen. In this case, firstly I should have a confirmation that the FC code is OK and then I could make a question to RF-Solutions regarding the issue.

Could you check please the FCF in my previous post?

Thanks

[LeighM]

Hi,
Only comment I can offer is, don't use Sample Point = Middle with 16F18877, it does not work,
but returns the first bit read for all the byte, which seems to be the case with your 0 and 0xFF
Hope that helps
Leigh

[fotios]

Hi,
Only comment I can offer is, don't use Sample Point = Middle with 16F18877, it does not work,
but returns the first bit read for all the byte, which seems to be the case with your 0 and 0xFF
Hope that helps
Leigh

Thanks, Leigh

I can confirm that the "Sample Point = Middle of the bit" is working just fine with the other peripheral ATM90E32 connected at SPI Channel 1.

I can confirm that I've tried any possible combination of SPI component properties.
However, I gave a last try just now by changing the Sample Point = End of the bit.
The LoRa module returns 194d for both registers, which is wrong.
I changed again the Sample Point = Middle of the bit and return again 194d.
I had 0x00 and 0xFF readings when exchanged the MISO - MOSI ports.

Here is a schematic of my hardware that could help you better?

Capture-1.jpg (40.91 KiB) Viewed 14428 times

It would be precious for me a confirmation that the SPI Channel 2 is free of bugs within Flow Code. Then, something is going wrong with the LoRa module, and I could make a question to RF-Solutions.

By anyway, thank you so much for your care.

Thanks

[LeighM]

I can confirm that the "Sample Point = Middle of the bit" is working just fine with the other peripheral ATM90E32 connected at SPI Channel 1.

That's interesting, I'll have a chat with Ben just to make sure my recollection of the issue is correct

Can you just confirm: You are using Flowcode V7 and are you up to date with the fixes (from the forum post)?
Ben usually ports most V8 fixes back into V7 (FCDs etc), but again, I'll get that checked with him.

[fotios]

I can confirm that the "Sample Point = Middle of the bit" is working just fine with the other peripheral ATM90E32 connected at SPI Channel 1.

That's interesting, I'll have a chat with Ben just to make sure my recollection of the issue is correct

Can you just confirm: You are using Flowcode V7 and are you up to date with the fixes (from the forum post)?
Ben usually ports most V8 fixes back into V7 (FCDs etc), but again, I'll get that checked with him.

Hi Leigh
Unfortunately, I can't locate any "fix" for the SPI Channel 2 issue.
Perhaps, there is not a bug within FC7 regarding it?
Could you confirm it?
It took me 10 days to convert the readily offered LoRa TX-RX mpasm files by RF-Solutions, to Flow Code 7.
It was a real labyrinth, a very tiring work.
Now, I got stuck for 3 days and can't proceed in the debug of the FC code because of the SPI CH2 issue.
For that reason, I compiled the small FCF above just to check the SPI CH2 transactions.

Thanks

[fotios]

Hi
I placed SPI components on both SPI channels and compiled the code so you could make a line by line comparison of the definitions in C.

Here the definitions of SPI CH1:

Code: Select all

/*========================================================================*\
   Use :cal_spi1
       :Variable declarations
       :Macro function declarations
\*========================================================================*/
#define MX_SPI_SS_TRIS_1 tris
#define MX_SPI_MISO_PORT_1 portc
#define MX_SPI_SCK_TRIS_1 trisc
#define MX_SPI_SCK_PIN_1 (3)
#define MX_SPI_MOSI_TRIS_1 trisc
#define MX_SPI_BMODE_1 (2)
#define MX_SPI_MISO_TRIS_1 trisc
#define MX_SPI_MOSI_PIN_1 (4)
#define MX_SPI_MISO_PIN_1 (5)
#define MX_SPI_SS_PIN_1 (0)
#define MX_SPI_PR_SCALE_1 (16)
#define MX_SPI_SS_PORT_1 port
#define MX_SPI_SCK_PORT_1 portc
#define MX_SPI_MOSI_PORT_1 portc
#define MX_SPI_CHANNEL_1 (1)


/*=----------------------------------------------------------------------=*\
   Use :cal_spi1
       :Supplementary defines
\*=----------------------------------------------------------------------=*/
#define MX_SPI_REF1
#define MX_SPI_REMAPPABLE_1 1
#define MX_SPI_MOSI_RPOR_1 RC4PPS
#define MX_SPI_MOSI_SDO_1 21
#define MX_SPI_CLK_RPOR_1 RC3PPS
#define MX_SPI_CLK_SCK_1 20
#define MX_SPI_MISO_RPINR_1 SSP1DATPPS
#define MX_SPI_MISO_RP_1 21

And here the definitions of SPI CH2

Code: Select all

/*========================================================================*\
   Use :cal_spi2
       :Variable declarations
       :Macro function declarations
\*========================================================================*/
#define MX_SPI_SS_TRIS_2 tris
#define MX_SPI_MISO_PORT_2 portb
#define MX_SPI_SCK_TRIS_2 trisb
#define MX_SPI_SCK_PIN_2 (1)
#define MX_SPI_MOSI_TRIS_2 trisb
#define MX_SPI_BMODE_2 (2)
#define MX_SPI_MISO_TRIS_2 trisb
#define MX_SPI_MOSI_PIN_2 (2)
#define MX_SPI_MISO_PIN_2 (3)
#define MX_SPI_SS_PIN_2 (0)
#define MX_SPI_PR_SCALE_2 (16)
#define MX_SPI_SS_PORT_2 port
#define MX_SPI_SCK_PORT_2 portb
#define MX_SPI_MOSI_PORT_2 portb
#define MX_SPI_CHANNEL_2 (2)


/*=----------------------------------------------------------------------=*\
   Use :cal_spi2
       :Supplementary defines
\*=----------------------------------------------------------------------=*/
#define MX_SPI_REF2
#define MX_SPI_REMAPPABLE_2 1
#define MX_SPI_MOSI_RPOR_2 RB2PPS
#define MX_SPI_MOSI_SDO_2 23
#define MX_SPI_CLK_RPOR_2 RB1PPS
#define MX_SPI_CLK_SCK_2 22
#define MX_SPI_MISO_RPINR_2 SSP2DATPPS
#define MX_SPI_MISO_RP_2 11

In my FC, the SPI CH1 (which is working flawlessly) is mapped as follows:
MISO_1: RC.5
MOSI_1: RC.4
SCK_1: RC.3
SS_1: RA.5

The SPI CH2 (which is not working) is mapped as follows:
MISO_2: RB.3
MOSI_2: RB.2
SCK_2: RB.1
SS_2: RB.4

Please note that in my hardware the micro used is a P16F18877 in TQFP44 package and its ports are allocated on different pins compared to PDIP40 package. Perhaps the problem arises from that?

Here the PIC16F18877 pin-port default mapping after reset:

Code: Select all

              PDIP40 pin     TQFP44 pin

SCK_1(RC.3)         18                  37
SDI_1 (RC.4)         23                  42
SS_1 (RA.5)           7                   24

SCK_2 (RB.1)         34                   9
SDI_2 (RB.2)          35                  10
SS_2 (RB.0)           33                    8

SDO_1 (RC.5)        24                  43     (Is not mapped by default, it is PPS remappable)
SDO_2 (RB.3)        36                  11     (Is not mapped by default, it is PPS remappable)

Here the new FCF:

LoRa_SPI.fcfx

(29.35 KiB) Downloaded 376 times

Thanks

[fotios]

Good morning

I found bug and in SPI CH1.
Just to remember that we talk for the P16F18877.

The CH1 is working flawlessly with the following component properties:
MOSI = RC.4
MISO = RC.5
SCK = RC.3
This is not the default mapping of CH1 after reset.

I exchanged the mapping of MOSI - MISO and now the CH1 present bug:
MOSI = RC.5
MISO = RC.4
SCK = RC.3
This is the default mapping after reset.

Then, I mapped the CH1 to the default pins of CH2:
MOSI = RB.3
MISO = RB.2
SCK = RB.1
It presents bug

Exchanging the MOSI - MISO mapping also presents bug:
MOSI = RB.2
MISO = RB.3
SCK = RB.1

I'm pretty sure that the remapping (PPS functionality of P16F18877) is incomplete and contains many bugs.

Could you take care of it, please?

I'm in waiting for the 4th day.
I have to debug a big FC LoRa TX-RX code!

Thanks

[LeighM]

Hi,
Thanks for the further information.
I have been checking the C code for the remap against the datasheet and all looks OK so far.
If the issue is blocking your work, could you try setting software SPI mode in the component and continue with that for your LoRa testing for now?

[fotios]

Hi,
Thanks for the further information.
I have been checking the C code for the remap against the datasheet and all looks OK so far.
If the issue is blocking your work, could you try setting software SPI mode in the component and continue with that for your LoRa testing for now?

Hi
You mean that instead of "Channel 2" I could select "software" in properties?
And then I could write in C code the properties?
Like SSP2DATPPS = 0x0B to asign SDI2 at port RB.3 etc?
I thought the same few days ago and I tried it without success because I had no idea about the selection "software".
Unfortunately, I lost the related C code after the fail.
But there is no problem, I will write and try it again.

Thanks

[LeighM]

Hi,
You should not need any C code.
Just set the SPI properties to
Channel: Software
MOSI: $PORTB.2
MISO: $PORTB.3
CLK: $PORTB.1

[fotios]

Doesn't work
I will try later writing C code

[gdt]

Hello,
PIC16F18877 is probably not the only one to have problem on SPI harware channel.
I had the same issue with PIC16LF26K80 communicating with an SPI display gLCD_SSD1331: on Channel 1 it didn't work but on Software was ok.
Could it be a common problem?

Regards
Giuseppe

[fotios]

Hello,
PIC16F18877 is probably not the only one to have problem on SPI harware channel.
I had the same issue with PIC16LF26K80 communicating with an SPI display gLCD_SSD1331: on Channel 1 it didn't work but on Software was ok.
Could it be a common problem?

Regards
Giuseppe

Hi Giuseppe
Regarding P16F18877, I think both "Channel" or "Software" settings are working just fine.
It is confirmed by LeighM and Benj.
This PIC offers two independent SPI buses, I don't know for 16LF26K80.
I tried both settings on SPI_1 with success, but at this bus is connected a known ATM90E32.
The PPS module is also free of bugs.
At the SPI_2 is connected an unknown RF-Solutions LoRa module.
For that module, I developed an FCF based on the Semtech SX1272 LoRa chip.
Finally, after the confirmation that both the SPI are free of bugs within FC, I realized that the module incorporates the Semtech SX1262, which is completely different!
Tomorrow I will modify the FC to fit with SX1262 and I will try both settings on SPI_2. Then I will let you know if works OK.

Thanks