• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 895 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

PGA970: SPI DIG_IF_CTRL and MICRO_INTERFACE_CONTROL read values zero after setting

PGA970: FRAM and DEVRAM write issues from SPI

Kenneth Sroka
Prodigy 135 points
Part Number: PGA970
Other Parts Discussed in Thread: UNIFLASH

Steve, need your urgent help

Getting further but still having unexpected results while writing to the PGA via SPI.  I can write and read the DIG_IF_CTRL and MICRO_INTERFACE_CONTROL registers with the expected results.   I have a routine that writes to FRAM and then reads back the values which works fine as long as I don't power off the chip.  If I power off the chip and try to read the values, I get FFs .  Yes I set the above registers at boot time to put the proc in reset.  If I re-write the FRAM and check so long as I don't power down ( I can even hard reset the slave cpu) then I can read the FRAM results without having to rewrite them.  I checked the REMAP register and get 0x00 as expected. One note is that I read the PSMON1 and PSMON2 and get 0xa8 and 0x18 respectively.  I checked all the external bypass cap voltages and they are correct. 

The FRAM_STATUS register is 0x00  however I found the following errors in the PDF:

P 62, 7.6.2 the CLK and FRAM_STATUS registers have the same offset but different M0 address.

P 42 section 7.3.1.14.3.3 in the table the line for Read FRAM byte 7 has the page address as 101 where it should be 100 if REMAP is 0 or 011 with REMAP 1

Lastly if I try to write to the DEV_RAM in the same way as the FRAM, I get all zeros no matter what. My page addresses are:

#define DI_PAGE_ADDRESS_DEV_RAM 0x03
#define DI_PAGE_ADDRESS_FRAM    0x04

I behind on a customer design so any help or suggestions would be welcome.  Are there tests or areas I can read to verify communication?

Thanks, Ken

  • 0
    TI__Mastermind 31655 points
    Hi Ken,

    When you leave the PGA970 powered on after programming the FRAM and then run the microcontroller, does the program execute properly?

    Also, is there any chance that the SECLOCK bit is being set?

    Regards,
  • 0 in reply to Scott Cummins
    Prodigy 135 points

    No and SECLOCK is 0x00, FRAM_STATUS=0x00. 

    I set the gpio2 bit for output, high via the SPI and it works,  load the FRAM area with your 1.6 test code that should make gpio2 input, release the processor by writing 0x00 to MICRO_INTERFACE_CONTROL and the gpio2 bit stays high.  I have also tried the above by writing the program to DEV_RAM, setting REMAP and releasing the processor and it still did not run the program.

    I can also:

    Program and test the DEVRAM area. (loose on power cycle)

    Program and verify the DATARAM area.(loose on power cycle)

    Turn on REFCAP - voltage verified goes from 0 to 2.5 when set

    Set WAVEFORM_GEN_CTRL (verified by read back (generator running bit is set) but no waveform output - after waveform loaded in memory)

    I cannot:

    Save FRAM on power cycle

    get a waveform output - still trying options

    run the microprocessor

    I have replaced the chip and the numbers on them are: PGA970Q 72T AXCJ

    I may try programming via SWDIO and the test pin output.  

    Any help is appreciated, I feel like it is so close.

    Thanks, Ken

  • 0 in reply to Kenneth Sroka
    Prodigy 135 points

    Scott, we finally got the chip programmed with a XDS110 via the SWDIO pins and the FRAM seems to be working because it survives a power cycle.   I compiled your 1.6 demo software and programmed it but I still am not getting an output on the PI pin.   I can modify the GPIO ports via the ARM code and have enabled the defines to load a waveform, turn on  vref and disabled loop back.   Any debug suggestions or pre-compiled binary I can try?

    FYI we have been able to program it via CCS 9 using the custom target config from a previous thread.  However the UniFLash 5 default config for the 970 PGA does not work.  We did get UniFlash 5.0 working if we load the custom .ccxml file that we created in CCS and were able to program and verify a .out format file but the .hex failed.   Not sure why.

    Thanks, Ken

  • 0 in reply to Kenneth Sroka
    TI__Mastermind 31655 points

    Hi Ken,

    As you may have seen from another thread our support for PGA970 firmware requests is being suspended on E2E. More details are here: https://e2e.ti.com/support/sensors/f/1023/t/802433

    Since we were already in contact before the support model change, please add me as a friend on E2E and we will continue offline in private message.

    Regards,

  • 0 in reply to Scott Cummins
    Prodigy 135 points

    Scott, can you accept my friend request?  I need to ask  a few questions on issues I am having on my custom board. 

    Thanks,Ken 

  • 0 in reply to Kenneth Sroka
    TI__Mastermind 31655 points

    Hi Ken,

    Sorry about that. I thought it was accepted earlier, but it didn't go through. You should be able to message me now.


    Regards,

  • 0 in reply to Scott Cummins
    Prodigy 135 points

    Scott, we resolved the issue.   I decided to replace the chip and we noticed the assembler did not flow solder on the bottom pad to the PCB.   We hand soldered the chip and made sure the pad was connected to the ground pad and the new chip is now generating a signal on PI.   

    For others reference, the ground pad is mandatory for operation.  The EVM schematic shows a ground connection to the chip pad while the datasheet page 21 block diagram does not.  We noticed in the block diagram a ground connection for the analog, digital, lvdt, etc except the VDD which made us suspect about the connection.   With a voltmeter, we verified the pad was not connected to any other pins so we inferred it must be the ground for VDD.  Surprising we had any parts of the chip working but we were able to read/write registers and ram with SPI, manipulate the GPIO, but FRAM did not save and we could not get an output on PI.   If you see this, check the ground pad or replace the chip. 

    Ken