ADS1248: Problems with preset FSC values

Hi Joseph, 

Thanks for your response.

This was a bit tricky as the hardware doesn't have a debug port anymore as it is a production unit. I reconfigured a couple of lines of the programming port to act as a bit-bashed RS232 to get data out from the system ( I got my original data by directly accessing the PIC memory)

This is the code snippet I used

It is written in CCS PICC. I haven't included the subroutines that deal with the chip as they clearly work

Basically I read the startup SYS0, print it, set SYS0 to 98 (gain 64, 20SPS), read SYS0 again as a check, read and print the default FSC, set FSC to 0x400000, read and print the new value.

//----------------------------------------------------------------------------------------------

// SYS0 - Gain = 64, 20 Samples Per Second (20 SPS = 1 every 50 mS)

//----------------------------------------------------------------------------------------------

   iReg = 0;

   iCheckReg = readADS1248Reg(iDev,SYS0);

   fprintf(debug, "Read and print the startup value of SYS0 \n\r");

   fprintf(debug, "Startup SYS0 %u \n\r", iCheckReg);

   iReg = (iReg | GAIN_64 | SPS_20);                                 //gain = 64

   writeADS1248Reg(iDev, SYS0, iReg );                               //write register

   delay_ms(1);

   iCheckReg = readADS1248Reg(iDev,SYS0);

   fprintf(debug, "read and print the new value of SYS0 \n\r");

   fprintf(debug, "Newly Set SYS0 %u \n\r", iCheckReg);

   fprintf(debug, "read and print the FSC bytes and assemble into INT32 format \n\r");

   i32FSC = 0;

   ireg = readADS1248Reg(iDev, FSC2);

   fprintf(debug, "FSC MSB %X \n\r", iReg);

   iFSCMSB = ireg;

   ireg = readADS1248Reg(iDev, FSC1);

   fprintf(debug, "FSC MDB %X \n\r", iReg);

   iFSCMDB = ireg;

   ireg = readADS1248Reg(iDev, FSC0);

   fprintf(debug, "FSC LSB %X \n\r", iReg);

   iFSCLSB = ireg;

   delay_ms(1);

   i32FSC = Make32(0,iFSCMSB,iFSCMDB, iFSCLSB);

   fprintf(debug, "Default FSC %LX \n\r", i32FSC);

   fprintf(debug, "Set FSC to 0x400000, read and print the FSC bytes and assemble into INT32 format \n\r");

   writeADS1248Calibration(iDev, 0x00400000);

   i32FSC = 0;

   ireg = readADS1248Reg(iDev, FSC2);

   fprintf(debug, "FSC MSB %X \n\r", iReg);

   iFSCMSB = ireg;

   ireg = readADS1248Reg(iDev, FSC1);

   fprintf(debug, "FSC MDB %X \n\r", iReg);

   iFSCMDB = ireg;

   ireg = readADS1248Reg(iDev, FSC0);

   fprintf(debug, "FSC LSB %X \n\r", iReg);

   iFSCLSB = ireg;

   delay_ms(1);

   i32FSC = Make32(0,iFSCMSB,iFSCMDB, iFSCLSB);

   fprintf(debug, "Set FSC %LX \n\r", i32FSC);

Here is the output......You can see that the default FSC is 0xFFFFC0

Read and print the startup value of SYS0

Startup SYS0 0

read and print the new value of SYS0

Newly Set SYS0 98

read and print the FSC bytes and assemble into INT32 format

FSC MSB FF

FSC MDB FF

FSC LSB C0

Default FSC FFFFC0

Set FSC to 0x400000, read and print the FSC bytes and assemble into INT32 format

FSC MSB 40

FSC MDB 0

FSC LSB 0

Set FSC 400000

If I exchange the chip for one with a different batch/date code I get the following, which is much more expected

Read and print the startup value of SYS0

Startup SYS0 0

read and print the new value of SYS0

Newly Set SYS0 98

read and print the FSC bytes and assemble into INT32 format

FSC MSB 40

FSC MDB D

FSC LSB C0

Default FSC 400DC0

Set FSC to 0x400000, read and print the FSC bytes and assemble into INT32 format

FSC MSB 40

FSC MDB 0

FSC LSB 0

Set FSC 400000

I'm struggling to see this as a software issue!

Do you know how the default FSC is stored on the chip? Is the memory volatile? Could it have degraded on the older batch of chips?

I need to bottom out this problem before we do any more production.

Best regards,

Mark

Mark,


Thanks for the code snippet. I still think it would have been better to run the test with the reset and the read. With that sequence, I could ensure that the reset would set the register back to the default. It eliminates the possibility that there aren't any other communications in between that could set off any change in the FSR register (like an unintentional write or a calibration command). On another note, it would have been good to record several FSR values for different gains, just to make sure that the device has different values programmed into it.

However, if you haven't changed your code and you've only swapped devices (by unsoldering the device off the board and soldering a new one on), it does look like the problem is with the device.

The device is programmed with structures similar to flash memory and it is non-volatile. I don't know of any cases where the memory was corrupted or degraded (let alone a whole batch of units). Which distributor did these devices come from? Normally, if we think the devices have some defect, should be should be returned to the distributor and we'd start some sort of failure analysis.


Joseph Wu

Hi Joseph,

I tried adding the reset as suggested  (code snippets below) but to no avail. The reported FSC is always 0xFFFFC0. I have tried this on 6 different chips now and they all report the same FSC value. Not sure why the last 6 bits of the FSC are zero, is the FSC actually 18 bits and shifted?

The board manufacturer has confirmed that the chips came from a box of 2000 units with lot number 1342, i'm guessing from the date code that these were remaindered stock from another project.

Having established the root of the problem, I can fix it relatively easily, by checking FSC once the gain is set and if it is greater than 0x420000 setting it to 0x400000. This works well as a fix, as we subsequently do a secondary calibration (not using the chip factors) in our software, to accommodate minor differences in thermocouples. I have two concerns however: firstly, the ADCs obviously have some form of defect and I worry that there may be other problems I have yet to discover; and secondly, the instrument calibration will be compromised if the ADC resets for any reason whilst running.

I have run an instrument with these chips and a software fix for about 3 days without issue, but ultimately these boards are intended for customer use and I am wondering if I should change out the chips.

In your first reply you implied that this fault cannot happen in production, this would mean that the problem has been caused by some external factor, and would lead me to feel that changing the chips would be sensible. If, on the other hand, it is possible that the FSC memory was wrongly written during production then I would be more inclined to go with the software fix.

Any thoughts on this would be welcome.

Best regards,

Mark

Code

ResetADS1248();

   fprintf(debug,"Reset the ADS1284 by pulsing reset pin low for 250ms, then set high and wait 20ms to stabilise \n\r");

   fprintf(debug, "read and print the FSC bytes and assemble into INT32 format \n\r");

   i32FSC = 0;

   ireg = readADS1248Reg(iDev, FSC2);

   fprintf(debug, "FSC MSB %X \n\r", iReg);

   iFSCMSB = ireg;

   ireg = readADS1248Reg(iDev, FSC1);

   fprintf(debug, "FSC MDB %X \n\r", iReg);

   iFSCMDB = ireg;

   ireg = readADS1248Reg(iDev, FSC0);

   fprintf(debug, "FSC LSB %X \n\r", iReg);

   iFSCLSB = ireg;

   delay_ms(1);

   i32FSC = Make32(0,iFSCMSB,iFSCMDB, iFSCLSB);

   fprintf(debug, "Default FSC %LX \n\r", i32FSC);

   fprintf(debug, "Set FSC to 0x400000, read and print the FSC bytes and assemble into INT32 format \n\r");

   writeADS1248Calibration(iDev, 0x00400000);

   i32FSC = 0;

   ireg = readADS1248Reg(iDev, FSC2);

   fprintf(debug, "FSC MSB %X \n\r", iReg);

   iFSCMSB = ireg;

   ireg = readADS1248Reg(iDev, FSC1);

   fprintf(debug, "FSC MDB %X \n\r", iReg);

   iFSCMDB = ireg;

   ireg = readADS1248Reg(iDev, FSC0);

   fprintf(debug, "FSC LSB %X \n\r", iReg);

   iFSCLSB = ireg;

   delay_ms(1);

   i32FSC = Make32(0,iFSCMSB,iFSCMDB, iFSCLSB);

   fprintf(debug, "Set FSC %LX \n\r", i32FSC);

The reset function is 

//================================================================================

// void resetADS1248(void) - reset the ADS1248 devices

// The Reset pin of the ADS1248 device must be held low to reset the device. The reset period is a

// function of the samples per second - see the table on page 35 of the TI ADS1248 datasheet,

// The slowest data rate (5 SPS) requires a reset of 200.26 mS.

// A further delay of 2 to the power of 16 system clocks are required before communications with //the chip can be started. Using the internal oscillator of 4.096 MHz, this delay is 15.99 mS.

//================================================================================

void resetADS1248(void)

{

   output_low(ADS1248_RESET);                                           //reset low

   delay_ms(250);                                                       //wait 250 mS

   output_high(ADS1248_RESET);                                          //reset high

   delay_ms(20);                                                       //wait 20 mS

}

Mark,

A colleague brought up one possibility that you should also check. I would verify that the system meets the timing requirements and switching characteristics for the SPI listed in 7.6 and 7.7 on pages 11 and 12 of the datasheets. If you've run the clock too fast, or violate any other timing or switching specification, then the errors may be unusual and the results may change from device lot to device lot. One common error is that the SCLK frequency is run too fast. Another violation that might give communication errors is the tSCCS specification, where there is a 7 tclk requirement between the last SCLK falling edge to the rising edge of /CS. I would go through both tables to make sure that the communication is set up correctly.

It would also be good to plot the SPI communications on an oscilloscope just to see if there are any other noise problems. If you still have the RESET/FSC read code, it would be good to show that one in particular. Once you generate the plot, you can post it back here.

As for the units and your boards, I have several concerns. If the units are really performing incorrectly, I would return them. The fact that they're not working means that there is some wrong, and perhaps there more wrong that we haven't discovered yet. Just because you can program the units to work on your board doesn't mean it's good, and there aren't errors that won't pop up for cases you haven't tested yet. As you mention, calibration would be compromised if the ADC resets while running.

Normally, units are returned through the distributor. This would trigger a quality analysis to determine the point of failure. To return the units, I'd start with finding the Ship Track Code from the box. It looks like this:

Right now, I'm concerned that these units show an error that I don't think should be possible. I don't think it's possible that we've sent out mis-trimmed parts, and I've never seen cases of any trim value degradation (let alone an entire batch of units that have the same error). Is it possible that these are grey market units? I could see this as an error if someone had a batch of units that were already bad or damaged. The reason I asked for the Ship Track Code is to find where these units came from.

Joseph Wu

Hi Joseph,

Getting SPI data traces from this circuit has been a challenge. It is a production board and has no debug tabs, coupled with the fact that the chips are all 0.5mm pitch, it has been something of a soldering nightmare.

I modified the software that runs on the controller PIC24EP256MC204 so that I could toggle one of the pins to act as a trigger for the scope and thereby access particular SPI transactions. I am mainly software, so I have limited tools for this type of work, so the data was collected on a 200MHz bandwidth, 2 channel picoscope. The SPI baud rate is 625kHz so the picoscope should be satisfactory. 

First up is CS low to first clock and last clock to CS high

The timing is about 3us at each end so much larger than the 10nS required.

Secondly I have SDO and clock

The outbound message reads 0x2900 (read register, register 9(FSC2), 1 byte) and looks OK

Next I have SCK and SDO for the read of FSC2 immediately after the reset.

This plot worried me, it shows the data reading as 0xFF but then SDO decays over several mS. What is happening here, I presume, is that the ADS1248 simply abandons the pin after the SPI transaction is complete and the residual voltage discharges through the high impedance PIC input pin. To prove this I moved the scope trigger to the read of FSC2 after setting FSC to 0x400000 and got the below trace.

The value now is 0x40 as expected

So you can see from this that the SPI appears to be working. I can’t see any timing issues based on the datasheet.

I am still waiting on the STC code for the parts from the Chinese manufacturer. I will let you know when I hear.

Best regards,

Mark