• AVR Freaks

AnsweredHot!PIC16F1503 SPI mode problem?

Author
abel11
Starting Member
  • Total Posts : 21
  • Reward points : 0
  • Joined: 2011/09/17 10:32:52
  • Location: 0
  • Status: offline
2020/02/13 03:52:51 (permalink)
0

PIC16F1503 SPI mode problem?

Hello.
 
Im trying to run pic16f1503 as slave SPI 4 lines (with nCS) in mode 3, master device is dsPIC33CK (SPI also mode 3) and it sends data 0x71 in 100us intervals - just for test purpose.
Slave device is configured as daisy chain, mean SSP1BUF overflow will not genereate overrun error.
When I connected the logical analyzer, I got strange results, MOSI and CLK lines are as expected, but MISO looks broken, it should receive the same 0x71, but instead I received 0x79 or 0xF2. Then I wrote a simple code to read the buffer piece by piece and send data to different pin during ISR, just for double checking.
Logical analyzer data for issue above is in attachment PIC16F1503_SPI_ISSUE.
 
Later, I decided to test all SPI modes for slave 0-3 to see if it changes anything, but it doesn't change anything. If change mode in master to 1 then got valid data at MISO. Unfortunately read buffer data bit by bit and send it to RA1 gives invalid data. Have no idea why did I miss something?
Logical analyzer data for issue above is in attachment PIC16F1503_SPISortOK.
 
PIC16F SPI code is more or less the same MCC generated one, may be slightly different because I changed buffer to simple table and made some minor changes during searching for solution.
 
void SPI_Initialize(void)
{
    // SPI setup
    SSP1STAT = 0x40; // CKE = 1
    SSP1CON1 = 0x14; // CKP = 1, SSPM = SLAVE + CS
    SSP1CON2 = 0x00;
    SSP1CON3 = 0x10; // BOEN = 1;
    SSP1ADD = 0x09;
        
    PIR1 = 0; // clear flag
    
    PIE1bits.SSP1IE = 1;
    TRISCbits.TRISC0 = 1;
        
    SPI_SetIsrHandler(SPI_Isr);
}

 
void SPI_Open()
{
    while(!PORTCbits.RC0); // wait for valid CLK idle state = high
    SSP1CON1bits.SSPEN = 1;
    
    // dummy read just in case
    spiBuff[0] = SSP1BUF;
    
    return;
}

 
void SPI_Isr(void)
{
    mask = 0x80;
    LATAbits.LATA1 = 0;
    
    if(PIR1bits.SSP1IF == 1){
        spiBuff[0] = SSP1BUF;
        
        while(mask > 0x0){
            LATAbits.LATA0 = 0;
            LATAbits.LATA1 = (spiBuff[0] & mask) ? 1 : 0;
            LATAbits.LATA0 = 1;
            mask >>= 1; NOP();NOP();NOP();
        }

        LATAbits.LATA1 = 0;
        SSP1CON1bits.WCOL = 0;
        SSP1CON1bits.SSPOV = 0;
        
        cnt++;
        if(cnt >= 30) cnt = 0;
    }
    
    LATAbits.LATA1 = 1;
    LATAbits.LATA0 = 0;
    PIR1bits.SSP1IF= 0;
}

 
 Edit:
I forgot to add, I already read topic at https://www.microchip.com/forums/m711636.aspx it was about some register address missmatch - I'v checked registers and everything is ok.
post edited by abel11 - 2020/02/13 04:02:49

Attached Image(s)

#1
Aussie Susan
Super Member
  • Total Posts : 3685
  • Reward points : 0
  • Joined: 2008/08/18 22:20:40
  • Location: Melbourne, Australia
  • Status: offline
Re: PIC16F1503 SPI mode problem? 2020/02/13 18:26:35 (permalink) ☼ Best Answerby abel11 2020/02/17 02:34:17
+3 (3)
I've not read your whole post but one word caught my eye and the images seemed to confirm it.
The settings for CKP and CKE are NOT directly related to the 'industry standard' for 'mode' - see https://openlabpro.com/guide/spi-module-in-pic18f4550/ for one of many pages that sow the relationship.
Looking at the first image, the MOSI and MISO lines are transitioning at different edges of the clock. What I suspect is happening is that you are actually sampling somewhere along the line while the input signal is changing. This is leading to you sometimes reading a 0 or a 1, depending on the vagaries of the internal electronics and signal propagation.
Just something to look in to....
Susan
#2
LdB_ECM
Super Member
  • Total Posts : 300
  • Reward points : 0
  • Joined: 2019/04/16 22:01:25
  • Location: 0
  • Status: offline
Re: PIC16F1503 SPI mode problem? 2020/02/13 20:32:17 (permalink) ☄ Helpfulby abel11 2020/02/14 00:35:36
+2 (2)
Your slave is not in MODE 3 it is clearing not changing data on the falling edge it is clearly doing that on the lifting edge AKA it is not in MODE3
post edited by LdB_ECM - 2020/02/13 20:33:21
#3
abel11
Starting Member
  • Total Posts : 21
  • Reward points : 0
  • Joined: 2011/09/17 10:32:52
  • Location: 0
  • Status: offline
Re: PIC16F1503 SPI mode problem? 2020/02/14 00:59:43 (permalink)
0
Thanks for the answers.
Aussie Susan
Thanks for link it help a lot, I never thought CKP and CKE setup for mode could vary between chip manufacturers.
settings for CKP and CKE are NOT directly related to the 'industry standard' for 'mode'

I still set all modes in slave just for check but it didn't work before change it in master, on Monday I gonna check it again with Your link info, maybe I just miss right one.
Chips are close to each other like ~20-30 mm so im not expecting too much noise, scope probe did not reveal any significant - it was my first conception.

LdB_ECM is right that this is not MODE3 and before Susan pasted the link, I did not know why.
 
On Monday, I will update the topic after applying information from you, I hope these mode mismatches are the case.
 
#4
Aussie Susan
Super Member
  • Total Posts : 3685
  • Reward points : 0
  • Joined: 2008/08/18 22:20:40
  • Location: Melbourne, Australia
  • Status: offline
Re: PIC16F1503 SPI mode problem? 2020/02/16 18:10:53 (permalink)
+4 (4)
"Design" - don't "Guess". It's the only way to get reliable operation.
Susan
#5
abel11
Starting Member
  • Total Posts : 21
  • Reward points : 0
  • Joined: 2011/09/17 10:32:52
  • Location: 0
  • Status: offline
Re: PIC16F1503 SPI mode problem? 2020/02/17 02:38:53 (permalink)
0
You're right that was the case, I have to remember Microchip have non industry standard mode selection for SPI, thanks again. And I shouldn't suppose it is like everywhere else, should just check it like You said.
#6
Jump to:
© 2020 APG vNext Commercial Version 4.5