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 trap exception error on spi_xfer() ... ?

 
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 trap exception error on spi_xfer() ... ?
PostPosted: Thu Feb 22, 2024 10:03 am     Reply with quote

Here's a weird one... We have a PIC24FJ256GA106 board that uses SPI to talk to an ADS8353 part. We just got a new batch of boards, and found a few of the new boards were rebooting from the watchdog timer.

We did some debugging and found that those boards hang at a spi_xfer() call.

We did more debugging and found that it was getting an address trap exception and ending up inside the Traps.c handler.

There are obviously defects on these boards since they behave differently with the same .hex file, but I found it odd that a spi_xfer() could hang/crash.

I pulled out all the code and dumbed it down to raw values (rather than using macros, functiosn, etc.). This code works on the good boards, but locks up at the " spi_xfer (SPI_MODE1, 0, 48);" line.

Anyone have any insight?

Code:
#include <24FJ256GA106.h> // Control Board

#use delay(clock=32MHz,crystal=8MHz)

#use rs232 (ICD) // Enable printf() output via ICD debugger.

#pin_select SCK2OUT=PIN_F2
#pin_select SDO2=PIN_F3
#pin_select SDI2=PIN_D11
#use spi (MASTER, SPI2, FORCE_HW, MODE=1, BAUD=8000000, STREAM=SPI_MODE1)

#FUSES NOWDT    //No Watch Dog Timer
#FUSES CKSFSM   //Clock Switching is enabled, fail Safe clock monitor is enabled

#include <stdio.h>
#include <stdint.h>

void main()
{
    uint16_t aValue = 0;
    uint16_t bValue = 0;
    uint16_t Value = 0;

    output_high (PIN_F6);
   
    // INIT:
    // Configure CFR
    spi_init (SPI_MODE1, TRUE);

    // Write Register
    output_low (PIN_F6);
    spi_xfer (SPI_MODE1, 0x8440, 16);
    spi_xfer (SPI_MODE1, 0, 32); // pad to 48 CLKs to force config to take affect
    output_high (PIN_F6);

    delay_ms (5); // Attempt to prevent hang on power up.

    // THIS PART MAY NOT BE NEEDED (it will use chip defaults)-----------------
    // Frame (F) - one empty frame of at least 48 CLKs
    output_low (PIN_F6);
    spi_xfer (SPI_MODE1, 0, 48);
    output_high (PIN_F6);

    // Frame (F+1)
    // To readback the user-programmable register settings, the appropriate
    // control word should be transmitted to the device during frame (F+1)
    output_low (PIN_F6);
    spi_xfer (SPI_MODE1, (3<<12), 16); // Write 16 bits.
    spi_xfer (SPI_MODE1, 0, 32);     // Pad to 48 CLKs.
    output_high (PIN_F6);

    // Frame (F+2)
    // During frame (F+2), SDO_A outputs the contents of the selected
    // user-programmable register on the first 16 SCLK falling edges
    output_low (PIN_F6);
    Value = spi_xfer (SPI_MODE1, 0, 16); // Write 16 bits.
    spi_xfer (SPI_MODE1, 0, 32);     // Pad to 48 CLKs.
    output_high (PIN_F6);

    // Configure REFDAC_A
    output_low (PIN_F6);
    spi_xfer (SPI_MODE1, 0x9348, 16);
    spi_xfer (SPI_MODE1, 0, 32); // pad to 48 CLKs to force config to take affect
    output_high (PIN_F6);

    // Configure REFDAC_B
    output_low (PIN_F6);
    spi_xfer (SPI_MODE1, 0xa348, 16);
    spi_xfer (SPI_MODE1, 0, 32); // pad to 48 CLKs to force config to take affect
    output_high (PIN_F6);
    // THIS PART MAY NOT BE NEEDED (it will use chip defaults)-----------------

    while (1)
    {
        output_low (PIN_F6);
        spi_xfer (SPI_MODE1, 0, 16);
        aValue = spi_xfer (SPI_MODE1, 0, 16);
        bValue = spi_xfer (SPI_MODE1, 0, 16);
        output_high (PIN_F6);

        printf ("A:%u  B:%u\r\n", aValue, bValue);
   
        delay_ms (1000);
    }
}

// End of main.c

_________________
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: 19238

View user's profile Send private message

PostPosted: Thu Feb 22, 2024 11:47 am     Reply with quote

First thing to do is read the chip revision.
Is it possible the faulty boards have the A3 revision chip???.
If so these have a bug where the buffer empty (or interrupt) sets one half
a bit early. This could result in the byte being overwritten during transmission.
Because this bug was fixed on later revisions the compiler defaults to not
applying a fix for this, so if you are programming for these you have to
manually enable this (device editor).
They would be very early chips if this was the case, but with the shortages
a while ago, old chips were sometimes being used.

I'd read the device ID, and the date codes on the face of the chips and
verify with MicroChip that they are legitimate.

As a minor thought, I would cast the passed '0' value to be an int64.
Otherwise you are trying to clock out more bits than you are passing.
Given the overloaded nature of the function, this could result in it trying
to load a value from a memory address that doesn't exist.
allenhuffman



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

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

PostPosted: Thu Feb 22, 2024 12:35 pm     Reply with quote

Ttelmah wrote:
First thing to do is read the chip revision.
Is it possible the faulty boards have the A3 revision chip???.


It turns out, I think we do have A3. I found the errata here:

https://ww1.microchip.com/downloads/en/DeviceDoc/PIC24FJ256GA110%20Family%20DS%20Errata%2080368e.pdf

The CCS LOAD tool shows mine is 0x1018 which shows up in the errata as A3.

This chip datecode is 2133, so 2021 week 33? We have others that say week 28 and different lots. We are now comparing.
_________________
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: 537
Location: Des Moines, Iowa, USA

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

PostPosted: Thu Feb 22, 2024 12:52 pm     Reply with quote

Ttelmah wrote:
As a minor thought, I would cast the passed '0' value to be an int64.
Otherwise you are trying to clock out more bits than you are passing.
Given the overloaded nature of the function, this could result in it trying
to load a value from a memory address that doesn't exist.


Sounds useful.

Our hardware folks have x-ray'd some of the bad boards and found things they can fix. It's going to be fun to learn what hardware change can cause the PIC's internal SPI stuff to crash. At least, that's what it seems ;-) when the same .hex file works on some boards but not others.
_________________
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: 19238

View user's profile Send private message

PostPosted: Thu Feb 22, 2024 11:54 pm     Reply with quote

If it is the A3 problem, recode with a loop sending a single byte at a
time. Add just a 2uSec delay between the bytes. Or test the clock bit
and wait till this goes to the idle state before sending the next byte.
Ttelmah



Joined: 11 Mar 2010
Posts: 19238

View user's profile Send private message

PostPosted: Fri Feb 23, 2024 9:50 am     Reply with quote

I'm getting more and more suspicious you may have some 'clone' chips,
or legitimate faulty ones that have been re-encapsulated. Just checked,
and the A5 revision was released in 2018!.... It should not be possible to
have an A3 revision chip with a 2021 date code.... Sad
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