 |
 |
| View previous topic :: View next topic |
| Author |
Message |
allenhuffman
Joined: 17 Jun 2019
Posts: 554
Location: Des Moines, Iowa, USA
|
| PIC24: What can make spi_xfer() hang? |
 Posted: Wed Mar 22, 2023 8:33 am |
 |
|
Some code I am looking at, which was working fine half an hour ago, has started hanging. Using printf and then the debugger to verify, it is hanging at a spi_xfer() that was working fine earlier:
| Quote: | spi_xfer (ADS8353_SPI_STREAM_MODE1, 0, 48); | Code: |
The only thing that has changed is enabling debugging so I could use printf() and test this driver code. (This is existing code that is running in production and has been for over a year.)
Can the spi_xxx() calls block? I know I2C can hang, but I didn't think SPI could?
Thanks, much. |
|
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9243
Location: Greensville,Ontario
|
|
| Posted: Wed Mar 22, 2023 8:38 am |
|
|
Obvious things, you've probably thought of...
Any chance the ADS8385 has become 'defective' ?
PCB trace is cracked ?
Power to ADS8385 has failed ?
The PIC24 has overheated ? |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 554
Location: Des Moines, Iowa, USA
|
|
| Posted: Wed Mar 22, 2023 8:43 am |
|
|
| temtronic wrote: | obvious things, you've probably thought of...
any chance the ADS8385 has become 'defective' ?
PCB trace is cracked ?
power to ADS8385 has failed ?
The PIC24 has overheated ? |
This was not obvious to me, but now is something else for me to check. This is a fresh board I only hooked up a few days ago. I went through verification steps (it's an RF board with four RF outputs, and eight RF inputs) with signal generators and power meters and all worked fine.
This morning, I added some code to print the raw ADC values I am reading from this SPI driver (outside of the driver code, printing what the driver "read" returns) and it was working ... until it stopped.
With I2C devices, I can use ACK/NAK response to see if the part is there. To do that on this SPI device, we read a configuration register. It's hanging on that, but I would expect it to return 0 if there was no response to the clock pulses.
I'll stick production firmware back on it and see if it's still working. If it is, then I'll mark this up as a "strange compiler thing" and contact CCS support.
Thanks!
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9243
Location: Greensville,Ontario
|
|
| Posted: Wed Mar 22, 2023 11:13 am |
|
|
hmm with SPI,
if the data line was low, yes, you'd get 8 zeros
but
if data was high, wouldn't you get 8 ones ??
never really thought about it until your post....
'fresh' board.. maybe there's an open between ADC and SPI data connection? Something you can't see except with a microscope?
I got bit decades ago. One remote board (of 240+) went 'odd'. Good one swapped out, bad came home. It was fine...then 'funny'....The slight flexing of the PCB finally showed I'd not soldered the wiper of a pot. Old school dbl sided, plated thru holes ,DIPs....2 seconds of soldering FIXED the issue.
I think today's PCB have less copper on them so might be prone to 'flex and break' ??
At least it's one more thing to see, then check it off the list.... |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19539
|
|
| Posted: Wed Mar 22, 2023 11:48 am |
|
|
The only thing that can normally hang an spi_xfer on a PIC24, is that
something is holding the clock line. On the PIC24, the same clock, that
is sent, is also used to clock the input. So if the line is shorted the
spi_xfer will hang, because nothing clocks the input shift register. |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 554
Location: Des Moines, Iowa, USA
|
|
| Posted: Mon Apr 17, 2023 11:32 am |
|
|
| Ttelmah wrote: | The only thing that can normally hang an spi_xfer on a PIC24, is that
something is holding the clock line. On the PIC24, the same clock, that
is sent, is also used to clock the input. So if the line is shorted the
spi_xfer will hang, because nothing clocks the input shift register. |
I did not realize a SPI transfer could block. The issue "just went away" but I'm expecting it to pop back up when it is least convenient.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19539
|
|
| Posted: Wed Apr 19, 2023 1:29 am |
|
|
Normally it can't.
However as I said, the one thing that can make it hang, is the clock.
On most of the later PIC's, the clock is fed out on a pin, and that signal
is fed back _from the pin_, to the input shift register. So what
can happen, is if this signal is shorted, the input register doesn't receive
a clock. Result, the input transfer doesn't happen. Hang.....
Obviously you can get this two ways. First a physical problem external
to the chip. Second the peripheral has got a configuration problem. For
example the PPS has got misconfigured on this pin, or the peripheral
itself has hung.
On my own code, at boot, I test before connecting the SPI, that the
clock pin can be raised and lowered. If it can't, there is an error message.
Otherwise the PPS and SPI is all setup.
The chip will watchdog, if there is an SPI hang, so if there is an external
problem the error message will then be displayed. If it was just a peripheral
problem, this will be cleared by the new setup. |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 554
Location: Des Moines, Iowa, USA
|
|
| Posted: Wed Nov 06, 2024 1:51 pm |
|
|
| Ttelmah wrote: | Normally it can't.
However as I said, the one thing that can make it hang, is the clock.
|
I ran in to this again today dealing with a Spansion S25FLxxxS flash partt.
Symptoms are the same -- working just fine, pulling data via messages going across I2C, then at some point, the board locks and the watchdog restarts (RESTART_WATCHDOG).
What might I be able to test? I assume the PIC just gets configured and generates the clock on its own. If my code locks up at a spi_xfer(), I am not sure what I could do from a code standpoint.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9243
Location: Greensville,Ontario
|
|
| Posted: Wed Nov 06, 2024 6:19 pm |
|
|
Are you 100% sure it's the code controlling the Spansion xxx part that 'locks up the PIC' ??
Have you bypassed all access to it to confirm it IS the source of the 'lock up' ??
If not,add code like the PC POST card does. Just before a function or subroutine is started ,you send a unique number to the local LCD ,if applicable or to a PC terminal program.
The idea is that you'll see a sequence of numbers 1,2,3,4,5.....56,57.... and then loop when main() loops around. When the PIC 'locks up', the LAST number on display is the start of whatever causes the lockup..
Yes it can involve a lot of time to add the diagnostic code but it'll pinpoint the source of the lockup...
If it randomly fails... then you may have a power problem
If it always fails at the same number/location....it's probably software. Perhaps something isn't setup correctly, or some variable is being change by something else, perhaps memory is being overridden ? maybe wrong datatype. Some PICS default to 8 bits, others 16 for 'type'.
I'm sure others will have ideas as well......
hmm, got the humidifer running ? dry air can cause random static and 'tis the season', at least here in Canada,eh ! |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 554
Location: Des Moines, Iowa, USA
|
|
| Posted: Wed Nov 06, 2024 7:03 pm |
|
|
| temtronic wrote: | | Are you 100% sure it's the code controlling the Spansion xxx part that 'locks up the PIC' ?? |
I spent some time with this, hijacking the two LEDs I have available, trying to catch it leaving one on. I am no longer 100% it is related to the spi_xfer(), like my original problem with an ADS part was. I had assumed it was going to be the same thing, but I did some extensive "read 1000s of times" and "write 1000s of times" testing and never saw it happen.
I thought maybe something else was messing with SPI, but this is the only SPI device on the board.
Thanks for your reply. I'll keep digging.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19539
|
|
| Posted: Thu Nov 07, 2024 6:22 am |
|
|
Have you thoroughly checked the errata for your particular PIC?.
There are odd ones on some chips that can lead to a processor hang. |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 554
Location: Des Moines, Iowa, USA
|
|
| Posted: Mon Nov 11, 2024 8:27 am |
|
|
| Ttelmah wrote: | Have you thoroughly checked the errata for your particular PIC?.
There are odd ones on some chips that can lead to a processor hang. |
We certainly have one with one of our PIC24 chips on the I2C side, with "no known workaround".
After I did more and more digging on this one, I eventually eliminated the spi_xxx() routines used by the flash part. It now appears it was unrelated to spi, but had to do with the an i2c_read() locking up. I need to post a different topic about this one, as it seems related to missing the stop bit or "next incoming character" bit, leaving the code handing at an i2c_read() until watchdog kicks in. i2c_poll() will help there, but without being able to detect the stop bit, my code does not know when a flexible-sized message is done being written so this new "feature" (in code that has been working great for years) is going to be problematic ;-)
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 554
Location: Des Moines, Iowa, USA
|
|
| Posted: Wed Nov 13, 2024 5:04 pm |
|
|
No sooner than I move on from the other project which was not a spi_xfer() lockup like I suspected, I am back to another and debugging has led me here:
| Code: |
putc ('d');
// Frame (F) - one empty frame of at least 48 CLKs
output_low (SlaveSelectPin);
spi_xfer (ADS8353_SPI_STREAM_MODE1, 0, 48);
output_high (SlaveSelectPin);
putc ('e');
|
All the early init code seems to be writing/reading back from the SPI part until it gets here, and then it locks.
That is the state right now, as I put putc() debug things in trying to figure out where. Not sure what to make of that currently.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1354
|
|
| Posted: Thu Nov 14, 2024 10:21 am |
|
|
if you are crafty and very very careful, you can setup a timer interrupt, then in the ISR handler inspect the stack to figure out where the interrupt occurred in the main code. If you are running a debugger perhaps you could then write that address to a variable and watch that to see where roughly you are getting stuck.
It is not an easy task, you need to really research how to inspect the stack after CCS is in the ISR handler |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19539
|
|
| Posted: Fri Nov 15, 2024 3:12 am |
|
|
Have you tried splitting the transfer?.
| Code: |
putc ('d');
// Frame (F) - one empty frame of at least 48 CLKs
output_low (SlaveSelectPin);
spi_xfer (ADS8353_SPI_STREAM_MODE1, 0, 32);
spi_xfer (ADS8353_SPI_STREAM_MODE1, 0, 16);
output_high (SlaveSelectPin);
putc ('e');
|
Have you used a 48 bit transfer anywhere else?.
I've just never used a single transfer larger than 32bits, and worry this
might cause an issue. The function is overloaded to support an int8,
int16 or int32 for the transfer, but does not show an int64.
Alternatively have an array of six blank bytes, and use SPI_transfer
saying you are sending 6 bytes.
It may be that the effect of a data overflow when doing the transfer is
intermittent, depending on what else is happening befoe/after. |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
