|
|
View previous topic :: View next topic |
Author |
Message |
allenhuffman
Joined: 17 Jun 2019 Posts: 554 Location: Des Moines, Iowa, USA
|
PIC24 trap exception error on spi_xfer() ... ? |
Posted: Thu Feb 22, 2024 10:03 am |
|
|
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: 19539
|
|
Posted: Thu Feb 22, 2024 11:47 am |
|
|
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: 554 Location: Des Moines, Iowa, USA
|
|
|
allenhuffman
Joined: 17 Jun 2019 Posts: 554 Location: Des Moines, Iowa, USA
|
|
Posted: Thu Feb 22, 2024 12:52 pm |
|
|
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: 19539
|
|
Posted: Thu Feb 22, 2024 11:54 pm |
|
|
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: 19539
|
|
Posted: Fri Feb 23, 2024 9:50 am |
|
|
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.... |
|
|
|
|
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
|