PIC24 - resetting SPI hardware?

[allenhuffman]

I have now seen several of our PIC24 boards have SPI issues on startup where attempting to read values just clocks back 0xFFs. This is most noticeable with an EEPROM that will return reads of FF FF FF FF FF when it happens. This causes our code to flag it as corrupt and try to reset the values back to factory defaults.

On one board, when this happens, I notice all SPI peripherals do not pass initialization (the ones where we can read back values, at least). A power cycle usually makes it work.

Now that I am looking for it, I found this on another board that uses the same PIC - 24FJ256GA106. While we have seen EEPROM issues with another board (24EP256GP202) I do not know if it is the same issue or not.

Using reset_cpu() looks like it works sometimes but usually it takes a power cycle.

Our code will do a spi_init() if switching to a different MODE, otherwise it's just the normal spi calls.

It's code that has been in service for years, but I see this state often after loading new firmware via a debugger, which makes me think it's related to not having a full power cycle restart.

My goal is to reset the hardware, if possible, on startup.

Is this a thing?
_________________
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]

I must admit I always tell people they must power the modules down
after a firmware upgrade. I've had too many PIC's over the years not work
correctly when reprogrammed, if you just carry on. Problem is that the
reprogram leaves most of the peripherals in an 'indeterminate' state.
Sometimes even completely locked.
There is obviously the errata issue with that PIC if you are using CKE=1
(so modes 2 or 3). This is an 'erratic' erratum, which seems to only apply
intermittently, but results in data being read at the wrong point in the clock.
Possibly this is being triggered by the reprogramming...

[asmallri]

[Ttelmah]

For me, I suspect it is the 'other devices' that cause issues, and one
particular part of the PIC hardware.
Remember if you reprogram the PIC, though it may receive a reset, nothing
else on the board does. Many of the chips will be in programmed states,
that may well mean they are half way through transactions etc..
Though my 'wake up' code is always designed to try to reset everything,
and does things like taking CS lines high at boot, and sending extra
clocks to I2C devices, I have had a couple of board designs, where there
are sometimes problems after reprogramming.
In particular, after reprogramming, the watchdog on the main chip
does not seem to start. It does after a hardware reset. I suspect that
part of the actual ICD programming code explicitly disables the watchdog,
to prevent issues during the programming, and that this requires a
hardware reset to get turned back on.