CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

PIC24 - resetting SPI hardware?

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
allenhuffman



Joined: 17 Jun 2019
Posts: 537
Location: Des Moines, Iowa, USA

View user's profile Send private message Visit poster's website

PIC24 - resetting SPI hardware?
PostPosted: Tue Sep 21, 2021 11:57 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Wed Sep 22, 2021 12:51 am     Reply with quote

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. Sad
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



Joined: 12 Aug 2004
Posts: 1630
Location: Perth, Australia

View user's profile Send private message Send e-mail Visit poster's website

Re: PIC24 - resetting SPI hardware?
PostPosted: Wed Sep 22, 2021 11:01 pm     Reply with quote

allenhuffman wrote:
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?


I have not seen this issue in more than a decade of working with the PIC24 family but his may be an issue to specific PICs. Could you have bus contention where a pullup is missing from a CS of one of the SPI devices?

Most of my devices that have SPI peripherals also have an SD card. I do force 80 SPI clock pulses onto the bus as this was historically (still is?) a requirement for SD card initialization.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!


Last edited by asmallri on Wed Sep 22, 2021 11:35 pm; edited 1 time in total
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Wed Sep 22, 2021 11:20 pm     Reply with quote

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.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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