AD Sampling of ADuc7039 Chip Needs External Reset,how to solve it?

When I using ADUC7039, Iam found that the system needs external reset after power Down or restart, otherwise the sampling voltage acquisition is incorrect.

By observing that the AD sampling voltage acquisition is twice the correct value, (For example, after resetting aduc7039, the AD sampling value is 3.1V, while the non-resetting AD sampling value is 6.2V)we checked the manual to find out what is the reason, and it can not be solved by software reset.

I don't know if the parameter configuration is incorrect or if there are other configurations?

while((PLLSTA&0x2)==0) {} // Ensure That thePLL is locked to the 3%
// SysClock=20.48MHz/2=10.24MHz (POWCON:CD=1 by default)
/* Timer2 setup ADuC7039 */
T2CON = 0; // Disable watchdog timer

/* Timer0 setup ADuC7039 */
T0CON = 0x002A; // clock = SysClock/16384=625Hz, Count down, Periodic
T0LD = 625; // 625Hz/625 = 1Hz


/* ADC setup ADuC7036/39 */
//ADC0CON = 0x0001; // disable I-ADC, twos complement, gain=2
ADC1CON = 0x8200; // enable V-ADC & T-ADC, select V-ADC, uniplolar coding, internal Temp sensor
ADCFLT = 0x961f; // AF=0,SF=7,F_ADC=512KHz/(SF+1)/64=1KHz
ADCMSKI = 0x02; // enable all ADC interrupt
ADCMDE = 0x01; // ADC normal mode, continuous conversion 
//ADC_VBAT_SetUp();

/* GPIO setup ADuC7039 */
GPCON = 0x00001111; // all GPIO configured as general purpose IO ÅäÖÃΪ SPI ¿Ú
GPSET = 0x00000000; // GPSET=0 does not affect GPIO output level
GPCLR = 0x00000000; // GPCLR=0 does not affect GPIO output level
GPDAT = 0x34000000; // GPIO_2(MISO)/4/5 set as output, write 1; others GPIO_x£¨/SS, SCLK, MOSI£
SPICON = 0x0341; // 0b41 0809 bit 0x8301

/* IRQ/FIR setup */ 
IRQ = Vector_IRQ;
FIQ = Vector_FIQ;
IRQEN = 0x00000200; // Enable SPI interrupt 0x20 SPI inti 0x4: Enable Timer0 int 0x00000004
FIQEN = 0x00000100; // ADuC7039 only: Enable ADC int

  • 0
    •  Analog Employees 
    on Jun 14, 2019 8:01 AM over 1 year ago

    The ADC settings listed do not show anything out of order. 
    I would suggest to used the JTAG interface to halt the device in run time and read back the ADC1DAT register when the issue is present and when the issue it is not present.
    If the issue is related to the ADC circuit, the retrieved ADC1DAT values should have a 2:1 ratio.

    However there is a SPI related anomaly listed in the ADuC7039 anomaly sheet, if this SPI anomaly results in a 1 bit shift the read back result from the ADuC7039 could be double.

    Can this phenomena be seen on ADC0 as well?

    regards
    Holger

  • I use JTAG interface to simulate acquisition is correct, when using JTAG simulation will appear reset chip, AD sampling is correct.

    I did not use ADC0 channel.

    What do you mean is it possible that SPI abnormalities cause data transfer shifts?

  • If it's caused by SPI anomaly, how can I handle it?

     Thank you !

  • I set up the simulation mode. Through JTAG simulation, I found that AD data acquisition is not correct, which is twice the correct value. For example, ADC1DAT values are 0x3A40, corresponding AD voltage is 6.55V. However, the value I passed through the multimeter is 3.28V.

    Are there any special points for attention in the peripheral circuit design of ADUC7039? The circuit schematic can not be pasted here.

  • 0
    •  Analog Employees 
    on Jun 28, 2019 7:34 AM over 1 year ago in reply to lixinjun1788

    from the anomaly sheet:
    Issue: When the ADuC7039 SPI interface is configured in slave mode and SPICON[2] = 0, the SPI may transmit incorrect data not reflecting data written to the Tx FIFO.

    I am not 100% sure how the anomaly manifests itself but a shift by one bit is most likely as the bits are transmitted at the start or the end or the bit dependent on SPICON[2], also it explains the issue you're seeing.

    When this scenario happens only a device reset can reset the SPI interface.
    Unfortunately there is no on-chip function that allows to reset the SPI interface. 

    Assuming a s/w reset can get the device out of this anomaly scenario, I'd suggest to implement a SYNC byte in your SPI communication. This should allows slave and master to detect SPI communication issues.

    As the stave transmission is affected, when the master detects a incorrect SYNC byte, it can send a "reset" command to the slave.

    The only other option I can see is to use the ADuCM330 or ADuCM331 device.
    These devices are the next generation IBS devices have therefore the same functionality as the ADuC7039, but have more powerful core and more memory.