• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 694 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.

EDMA PARAM register access denied

JasonD3
Intellectual 750 points

I'm having a problem accessing the EDMA registers on a custom DM647 board.  I found that my code was not modifying the PARAM registers as it was doing on the DM648 EVM.  So I did a little experiment:

No GEL file, no code involved.  I power up the EVM and connect to it with an emulator and CCS.  I open the memory view window and go to a PARAM location.  I can modify the values with no problems.  When I set the OPT parameter - bit 31 changes from a 1 to a 0, indicating that a User modified this register.

I do the same thing with the custom board and I cannot modify any of the PARAM registers.  Is there something in the hardware startup that would put the DSP in a mode where a user could not modify PARAM?  I've looked at all the privilege registers and they all are set to allow user access.  I don't even really think this matters since these registers should only govern shadow regions.

Does anybody have an explanation for this?

Thanks in advance.

  • 0
    TI__Mastermind 41665 points

    While I do not know of anything specific you could do in hardware to prevent accesses to the EDMA PaRAM area, since this seems to be specific to your particular hardware, the first areas I would check are the reserved pins on the device in your schematic as well as the boot mode pins, as sometimes reserved pins and other pins that the datasheet says must be pulled in a certain direction at boot can put the device in an odd state if not handled properly. Beyond this ensuring the voltages and clocks are nice and clean would be another good step to take, noise on the input clocks or unstable voltage rails could cause strange reactions within the device. These are long shot suggestions, but are the most common hardware specific failures I have come across, and can lead to a wide variety of strange symptoms.

  • 0 in reply to Bernie Thompson TI
    Intellectual 750 points

    Bernie,

    Thanks for your reply.  All of the bootmode pins are pulled up/down as intended and the RSV pins are connected as the datasheet specifies.  The clocks and voltages check out to be good.  This is a strange problem because pretty much everything else on the board works correctly.  I can run code from DDR, I have tested SPI and UART interfaces, and the EMIFA works correctly with on board flash.

    I have determined that I can write to any of the EDMA control registers - except for PaRAM.  Any change that I try to make to a PaRAM set will just not be accepted.  I have tried to reset the EDMA module by using the PSC and that does not change this behavior.  I have also compared all of the EDMA registers between my board and the EVM board on startup and the only registers that are different are the PaRAM (of course) and the Event Queue Entry Registers.  Do you know of any software conditions that would lock the PaRAM registers?  Maybe the EVM is running some bootcode that sets something up that I am missing.

    Thanks,

    Jason

  • 0 in reply to JasonD3
    TI__Mastermind 41665 points

    JasonD3 said:
    Do you know of any software conditions that would lock the PaRAM registers?

    Unfortunately I do not, though I do not do much work with DM647 so if there is something special about the EDMA3 implementation (or the protection schemes) on it perhaps someone else can comment.

    JasonD3 said:
    Maybe the EVM is running some bootcode that sets something up that I am missing.

    To make the EVM and the custom board boot the same way it may be worth setting them both to a unbootable mode, such as no boot or hpi boot, to take any code that happens to be in the static memories of the boards out of the system, this way you could check on the PaRAM accessability without any software potentially skewing the results.

    I am curious if your EVM and your board are both using the same silicon revision?

     

  • 0 in reply to Bernie Thompson TI
    Intellectual 750 points

    They are not the same silicon revision - the EVM is Ver 1.0 and the custom board has Rev 1.1

  • 0 in reply to JasonD3
    Intellectual 750 points

    Bernie,

    I seem to have found the issue - although I can't fathom why this would be.  I was using a custom-made isolater board between our emulator and the custom board in question.  We have used this isolator board on many C2000 applications in the past, and we thought it was a good idea to protect our emulator for the bring up of this new custom DM647 board.  It turns out that when I remove the isolator and just connect the emulator directly to the custom board, I can change the PaRAM registers without any problem.  I have no idea why this would be the case -  I could modify other registers with no problem.  Also, when I hooked up the emulator to the EVM through the isolator board, it worked fine.  Very strange - but I am no longer stuck on EDMA registers.  Thanks for your time.

  • 0 in reply to JasonD3
    TI__Mastermind 41665 points

    That is extremely strange, particularly that something as specific as the PaRAM area would be inaccessable because of a isolater on the emulator, in general if there was a fault in the emulator connection I would expect a more catastrophic result (i.e. the emulation works fine or not at all). My best guess would be that the isolator was somehow impacting some of the emulation pins (perhaps the EMU pins), though again I would normally expect a more obvious failure to connect than something like inability to access PaRAM, this is certainly a unique case to my memory. In any case I am glad to hear that it is fixed; thank you for posting the solution.