• AVR Freaks

Hot!PIC32MX795F512H: SPI locks up PIC

Author
PhreakShow
Starting Member
  • Total Posts : 43
  • Reward points : 0
  • Joined: 2011/05/13 01:35:01
  • Location: 0
  • Status: offline
2019/12/08 16:57:35 (permalink)
0

PIC32MX795F512H: SPI locks up PIC

Hi.
 
I am trying to communicate with an lNAP375 over SPI. I set it up with:
 
SpiChnOpen(SPI_CHANNEL3, SPI_OPEN_MSTEN|SPI_OPEN_SMP_END|SPI_OPEN_MODE8|SPI_OPEN_CKE_REV, 80);
 
That yields a clock of 250kHz, the datasheet states a maximum of 11MHz and no minimum, so I think I'm ok there. I am trying to read register 0x72 which should contain a revision id. So I try this for reading:
 
CS2 = 0;
Delay10us(10);
SpiChnPutC(SPI_CHANNEL3, 0x72);
SpiChnPutC(SPI_CHANNEL3, 0x00);
nTemp[0] = SpiChnGetC(SPI_CHANNEL3);
CS2 = 1;

 
My oscilloscope shows this (clock is red, blue is MOSI, green is MISO, CS is not shown but applied correctly) (spi1.png)
 
 
The data is being transmitted correctly, but the response is weird. But it gets weirder...
 
The picture shows the first transmission after a cold start. If I send it again (same piece of code), it yields all zero. If I do it again, I again get zeros.
 
But if I send it a forth time, I get this (spi2.png)
 
 
That is the correct answer, a chip revision of '101' starting from the MSB, yielding 0xA8 in hex. But as soon as the SPI slave sends this answer, the PIC32 locks up and does not respond anymore. If I try this in a debugging session, the debugger does not jump to a position in my code. I can reset it, though, so it's not completely dead.
 
Now at least two questions arise... 
 
Why does the SPI slave respond after the forth time I sent this, not the first time?
Why does the PIC32 lock up if it gets the correct data, and not in the other three cases?
 
On another project, I communicated with the lNAP375 using a PIC18F, without issues like these. Sent 0x72, sent dummy 0x00, got 0xA8 back. Everytime, all the time. Whats different here?

Attached Image(s)

#1

7 Replies Related Threads

    ric
    Super Member
    • Total Posts : 28335
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: PIC32MX795F512H: SPI locks up PIC 2019/12/08 18:22:48 (permalink)
    4 (1)
    PhreakShow
    ...
    My oscilloscope shows this (clock is red, blue is MOSI, green is MISO, CS is not shown but applied correctly) (spi1.png)
    ...
     

    "not shown but applied correctly" always raises my suspicions.
    What exactly do you mean by "applied correctly" ?
    Would it be that hard to actually show it too?
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #2
    PhreakShow
    Starting Member
    • Total Posts : 43
    • Reward points : 0
    • Joined: 2011/05/13 01:35:01
    • Location: 0
    • Status: offline
    Re: PIC32MX795F512H: SPI locks up PIC 2019/12/09 04:45:49 (permalink)
    0
    I uploaded the screenshots and realized, that I did not connect the scope to the CS line. I measured it earlier, though. I will add another screenshot with CS connected to the scope as well, later.
    #3
    PhreakShow
    Starting Member
    • Total Posts : 43
    • Reward points : 0
    • Joined: 2011/05/13 01:35:01
    • Location: 0
    • Status: offline
    Re: PIC32MX795F512H: SPI locks up PIC 2019/12/09 15:59:24 (permalink)
    0
    Here's the screenshot (spi3.png)

    Attached Image(s)

    #4
    andersm
    Super Member
    • Total Posts : 2839
    • Reward points : 0
    • Joined: 2012/10/07 14:57:44
    • Location: 0
    • Status: offline
    Re: PIC32MX795F512H: SPI locks up PIC 2019/12/09 16:22:27 (permalink)
    0
    It looks like your reads and writes are imbalanced. In the snippet you posted, "nTemp[0]" will hold the byte clocked in when sending the byte 0x72, while one byte will remain in the FIFO.
    #5
    sborden
    Super Member
    • Total Posts : 1960
    • Reward points : 0
    • Joined: 2010/08/05 02:12:53
    • Location: 0
    • Status: offline
    Re: PIC32MX795F512H: SPI locks up PIC 2019/12/10 04:24:53 (permalink)
    0
    Make sure the INAP375 is correctly set up for CPHA and CPOL. Datasheet shows 4 combinations. Also, why not post a scope of the signals from the working projects? That should give better indications as to what the issue is.
    #6
    PhreakShow
    Starting Member
    • Total Posts : 43
    • Reward points : 0
    • Joined: 2011/05/13 01:35:01
    • Location: 0
    • Status: offline
    Re: PIC32MX795F512H: SPI locks up PIC 2019/12/10 16:29:37 (permalink)
    0
    andersm
    It looks like your reads and writes are imbalanced. 

     
    That's on purpose, actually I do not care for any data. I just want to see the answer on the scope as a proof of concept, no matter what the PIC does with the answer(s). Is that a problem is the FIFO creates an overflow, or is it the cause for the hang up?

    sborden
    Make sure the INAP375 is correctly set up for CPHA and CPOL. Datasheet shows 4 combinations. Also, why not post a scope of the signals from the working projects? That should give better indications as to what the issue is.



    It is set to both CPHA and CPOL being zero, which is the default setting. I also configured the SPI for mode 00, at least that's what I think my init snippet does.
    #7
    PhreakShow
    Starting Member
    • Total Posts : 43
    • Reward points : 0
    • Joined: 2011/05/13 01:35:01
    • Location: 0
    • Status: offline
    Re: PIC32MX795F512H: SPI locks up PIC 2019/12/13 16:33:43 (permalink)
    4 (1)
    I found the cause of my problems. It turned out that the SPI slave actually received the first message, and tried to answer. But this raises the slave's power consumption a bit. Normally not a problem...
     
    A capacitor responsible for decoupling the slave's supply was either faulty from the start, or it did not survive the soldering. I replaced all 100nF caps on the boards, and everything is working fine now. Maybe one of the PIC's caps was dead too, because now it keeps running even if there is overflowing data on the MISO line.
    #8
    Jump to:
    © 2020 APG vNext Commercial Version 4.5