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.

66AK2G02 - PRU access to system resources, can't get to work

Other Parts Discussed in Thread: 66AK2G02

Hi,

I'm developing some custom PRU code on the 66AK2G02 EVM. I use the GEL file as is out of the box to connect to the C66x DSP from CCS using the on-board XDS200 emulator. This GEL file enables the PRU subsystems. I then use CCS and JTAG to write code for the PRUs. The problem I'm facing is, I can't get to any of the system resources outside of the PRU from my PRU code. I can access all the internal PRU resources using the PRU local addresses, just can't get to anything outside of the PRU. For example, I can't get to the SoC pin mux registers (padconfig) starting at address 0x02621000. I also tried accessing the DSP L2 RAM and EDMA1 parameter RAM. I tried accessing from both code and CCS memory window, neither works, always returns zeros.

Can somebody tell me what I'm doing wrong? Is there some MMU or something that needs to be setup? I have the following line of code in my main() which all the PRU examples seem to have in them.

 // Clear SYSCFG[STANDBY_INIT] to enable OCP master port
  CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;

Thanks

  • Brad,

    It seems you will not be able to access system registers and memory from CCS Memory browser due to some limitation with the emulation interface but you should be able to access these registers through code so in order to debug, you will need to write to registers in code and then look at the memory/regsiter location from the DSP or the ARM core. There seems to be some inherent limitation in CCS that prevents the system registers/memory to be accessed from the PRU cores through memory browser.

    Can you please provide the snippet of code that you are using for us to look at.

    Regards,
    Rahul
  • Below is a snippet of code. As an experiment, I tried reading from two different locations. The first one is the EDMACC peripheral ID register, it reads back ok. The second one I tried reading the first pad configuration register (PADCONFIG) and it returns zero even though I see it has a value of 0x00140003 when viewed from the C66x. I'm wondering if there's a permission issue or something like that with the PADCONFIG registers. I'd really like to access the PADCONFIG registers so I can on-the-fly switch between inputs and output on certain PRU GPIO pins. Can you think of any reason why the PRU can't access the PADCONFIG registers?

    Thanks

    /*----------------------------------------------------------------------------*/
    int main(void) {

      volatile int x;

      // Clear SYSCFG[STANDBY_INIT] to enable OCP master port
      CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;

      x = *(volatile unsigned int *)0x02700000;
      // x returns 0x4001AB00, this is the expected value
     

      x = *(volatile unsigned int *)0x02621000;
      // x returns zero, it should return 0x00140003

    }

  • Have you unlocked the KICK registers to access the PADCONFIG Regsiters.

    Regards,
    Rahul
  • No, I didn't unlock the kick registers.However, I didn't unlock them on my C66x code either which had no problem writing to the PADCONFIG registers. I'm guessing the GEL file left them unlocked. Regardless, the kick mechanism only prevents writes to the registers, in my PRU code, I can't read nor write the PADCONFIG registers.

    I went ahead and added in the kick unlock (see snippet below) but that didn't solve my problem.

    int main(void) {

      volatile int x;

      // Clear SYSCFG[STANDBY_INIT] to enable OCP master port
      CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;

      // unlock the BOOT_CFG space kick mechanism
      *(volatile unsigned int *)(0x02620038) = 0x83E70B13; // BOOTCFG_KICK0
      *(volatile unsigned int *)(0x0262003C) = 0x95A4F1E0; // BOOTCFG_KICK1

      x = *(volatile unsigned int *)0x02700000;
      x = *(volatile unsigned int *)0x02621000;