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.

PCM3070RHBEVM-K: EEProm on USB-MODEVM vs. EEProm on PCM3070EVM

Part Number: PCM3070RHBEVM-K
Other Parts Discussed in Thread: PCM3070

I'm having mixed success with the USB-MODEVM and PCM3070EVM : after an initial play with the PCM3070 module I removed it and linked across to the PCM3070 on my own board - audio playing back nicely etc. BUT - I'm constantly plagued with the USB-MODEVM appearing to lose it's identity/settings.

My project needed 48kHz sample rates (only); so I use the instructions from this forum to download the appropriate BIN file - BUT - the dialog boxes that appear never quite make sense: When it asks to set the eeprom address to 10100000, does this refer to U1 on the USB-MODEVM or U2 on the PCM3070EVM?! (I presume the USB-MODEVM as it controls the sample rate in the TAS1020B etc).

Is it possible I need to download something to the PCM3070EVM U2 now if I've put the TAS1020B firmware in by mistake? What does that part (U2 on PCM3070EVM) specifically do?

Thanks :)

  • Hi, Jason,

    From the GUI point of view, only one EEPROM is seen in the evaluation kit, and it is selected according to its configured address. In order to use the EEPROM in the motherboard, you need to set switch 2 (A1) on  SW2 of the motherboard to the ON position and keep W13 header of the PCM3070EVM open. If you want to use the EEPROM of the EVM, change the position of the mentioned switch to OFF position and put a shunt in header W13. 

    Best Regards,

      -Diego Meléndez López
       Audio Applications Engineer

  • Thanks for your reply. I've been around the loop in the recovery instructions many times; the board still reverts to a DFUUSB device upon cable re-insertion.
    Can you explain why/what the dual-step process of first loading the DFUEE.bin followed by the USB-Audioxxxx.bin file does? It seems that both times it insists on having the EEProm address at 10100000 for it to succeed, this would imply the first file gets overwritten - or is it in different eeprom blocks?
    In general the DFUTEST program complains bitterly after a first download - the 'detach' call fails followed by many other fail dialogs in a row.
    It always asks for the eeprom address to be set to something other than 10100000 -which surely then means the TAS1020B won't find it?

    It would be helpful to have a more detailed explanation of how this all works - I can't see why it should always revert to a DFUUSB.

    Can you confirm that the TAS1020B looks for 10100000 at power up to determine if there is firmware, or does it scan other I2C addresses?
    Thanks
    Jason
  • Success :) I had been skipping the DFUEE.BIN step sometimes; now the DFUTEST app works well, and I get persistent USB-Audio connection & sample rate. Making use of the EEprom on the USB-MODEVM at address 10100000 - very convenient now that I'm connected across to my proto and don't use the PCM3070EVM.

    Thanks for your patience.