• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 99 subscribers
  • Views 968 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.

INTMUX register corruption on DM3730 with CCS4 and DSPBios

Susan Tremel
Prodigy 80 points
Other Parts Discussed in Thread: DM3730, OMAP3530

I'm using CCS Version: 4.2.1.00004, DSPBios 5.41.10.36, and a XDS510 USB emulator to debug on the Mistral DM3730 on the DSP. I am using the Gel files specified in the OMAP and Sitara CCS support wiki page. Things start off well. I connect to the arm, take the DSP out of reset and then connect to the DSP and load my code. My code is a simple hello world program modified to set up a HWI.

When I set up the HWI mapping using the dispatcher, either in the BIOS configuration file or at run-time in my code, the values written to the INTMUXj_* registers don't get the values that I'd expect. In fact INTMUXj_3 mirrors INTMUXj_1 after configuration. Then as I run my code--which goes into an infinite loop that just writes a single variable repeatedly -- the values of INTMUXj_3 change almost every time I break. I never reach my ISR even though the bit is set in the IFR register.

This feels like a configuration issue. Any ideas?

 

  • 0
    TI__Mastermind 32475 points

    Susan,

    Can you give more details on what interrupts your are trying to configure through configuration?  Maybe give a screen shot?  What values are you seeing in the INTMUX registers and what values do you expect?

    Are you using the omap3 based configuration for this device since I don't think DM3730 is specifically supported by DSPBios.

    Judah

  • 0 in reply to judahvang
    Prodigy 80 points

    Hi Judah,

    Yes I am using an OMAP3530 configuration.

    I was trying to map event 77, the GPIO5 interrupt, to interrupt 8. I eventually got that working by starting with a dsplink sample app and adding my interrupt configuration. I still don't know whether I wasn't configuring the OMAP or the BIOS correctly, but that turned out not to be a factor in the INTMUX behavior.

    For the following I'm trying to execute code in the debugger and check the CCS 4.2 INTMUX register to view the current value.

    When I executed the HWI_eventMap( 8,77) command I didn't see the mapping in the INTMUX register I expected which was in INTMUX2, instead the "4D" ended up in INTMUX1 and also in INTMUX3. If I modified INTMUX1 directly, the change was mirrored to INTMUX3. Then when I single-stepped through code that had no impact on the INTMUX registers, INTMUX3 would change with every step.  My conclusion is that these registers can not be relied on.

    I did notice that the base address for INTMUX is 0x01800104 in spru871k describing the C64x+ megamodule and 0x1800108 in the Technical Reference Manual for the OMAP3530 and DM3730.

    Susan

  • 0 in reply to Susan Tremel
    TI__Mastermind 32475 points

    Susan,

    I'm not familiar with the INTMUX register view so I can't speak to whether those register views are correct or not.  What I do know is that the address for INTMUX[0] = 0x01800104, INTMUX[1] = 0x01800108, and INTMUX[2] = 0x0180010C.  I would expect that a call to HWI_eventMap(8, 77) to do the correct thing in INTMUX[1].  Are you saying that this is now working for you?  If its not working, can you open up a "memory window" to address 0x01800108 to verify that its correct?

    Judah

  • 0 in reply to judahvang
    Prodigy 80 points

    According to both docs, there is no INTMUX[0], they are numbered from 1 to 3. The first 4 CINT interrupts which would fall into the INTMUX0 range are not mappable.

    The corresponding memory addresses did not display correctly in a memory window either.  The memory window  values was consistent with the register values.

    My call to HWI_eventMap (8,77) is working for me. I get the GPIO5 interrupt in interrupt 8. I just don't see the correct values in the registers.

     

    I don't think this chain of postings belongs in the Bios forum. Of all of the potential causes, bios is not very likely to be one of them.

    This is not a blocker for me, I just believe it is a TI bug of some kind.

  • 0 in reply to Susan Tremel
    TI__Mastermind 32475 points

    Susan,

    Your right.  I meant to say INTMUX[1], INTMUX[2], and INTMUX[3].  The addresses I listed are correct respectively to 1, 2 , and 3.  Hwi_eventMap(8, 77) should modify INTMUX2 as you stated before.  I have yet to see this as a problem on other TI devices, but It could be a problem on the specific device you are using.

    Judah

  • 0 in reply to judahvang
    Prodigy 80 points

    Judah,

    That would be my guess as well. I've seen it on both the OMAP3530 and the DM3730. Since the Technical Reference Manuals for these two devices conflict with the 64x+ Megamodule guide on the addresses of these registers that again supports the theory.

  • 0 in reply to Susan Tremel
    TI__Mastermind 18320 points

    Susan,

    I am going to go ahead and move this thread over to the DM37x forum in hopes that you can get further information there.  Of course, that won't prevent Judah from contributing further if he has any other suggestions.

    Dave