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.

M4 IPU Cache Enabling TIMER2 Hard_FAULT

Hi,

directly after enabling the cache with UNICACHEEnable(SOC_IPU1_UNICACHE_MMU_CONF_REGS_BASE) I configure the GP-Timer2.

If I don't insert a wait loop after cache enabling I get a HARD_FAULT.

Do I need to wait after cache enabling or what else could it be?

Thanks

Andreas

  • Hi Andreas,

    Can you provide more details on the scenario where you are getting hard fault like AMMU config, memory where you are running. etc.

    Regards,
    Rishabh
  • Hi Rishabh,

    It happens during TIMERReset() function. The code is running on DDR RAM 0x9E000000.

    The structure is like this:

       UNICACHEEnable()
    
       for(uint32_t x = 0;x < 9999999; x++)
       {
          __asm__("nop");
       }
    
        TIMERReset()
    

    Do I need some wait time?

    Regards,

    Andreas

  • Hi Andreas,

    You don't need any wait after enabling cache.
    Ideally you should not have faced this issue, most probably some sequence is not absolutely correct in the system context.

    As a workaround can you add UNICACHEInvalidateAll after enabling cache and try.

    Regards,
    Rishabh
  • Hi,

    I have the following message when TimerReset() is triggered:

    [ 10.512559] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x23c/0x368()
    [ 10.512581] 44000000.ocp:L3 Custom Error: MASTER IPU1 TARGET L4_PER1_P3 (Read): Data Access in User mode during Functional access
    [ 10.512595] Modules linked in:
    [ 10.512624] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.84-SMS_MONOLYTHIC-svn36 #25
    [ 10.512640] Hardware name: Generic DRA74X (Flattened Device Tree)
    [ 10.512654] Backtrace:
    [ 10.512695] [<c0012f6c>] (dump_backtrace) from [<c0013108>] (show_stack+0x18/0x1c)
    [ 10.512710] r6:20000193 r5:ffffffff r4:00000000 r3:00000000
    [ 10.512765] [<c00130f0>] (show_stack) from [<c029804c>] (dump_stack+0x88/0xa8)
    [ 10.512789] [<c0297fc4>] (dump_stack) from [<c0041844>] (warn_slowpath_common+0x80/0xbc)
    [ 10.512802] r8:c075d670 r7:00000009 r6:00000093 r5:c02c88f8 r4:c081bd60 r3:c081a000
    [ 10.512859] [<c00417c4>] (warn_slowpath_common) from [<c0041924>] (warn_slowpath_fmt+0x38/0x40)
    [ 10.512872] r8:c060ab34 r7:c075d8b4 r6:eee0d910 r5:c075d5cc r4:80080003
    [ 10.512924] [<c00418f0>] (warn_slowpath_fmt) from [<c02c88f8>] (l3_interrupt_handler+0x23c/0x368)
    [ 10.512937] r3:eee0d780 r2:c075d68c
    [ 10.512970] [<c02c86bc>] (l3_interrupt_handler) from [<c0089dec>] (handle_irq_event_percpu+0x64/0x164)
    [ 10.512984] r10:eedfa240 r9:c086d6fa r8:00000017 r7:00000000 r6:00000000 r5:eedfa2a0
    [ 10.513030] r4:eee0dc80
    [ 10.513055] [<c0089d88>] (handle_irq_event_percpu) from [<c0089f2c>] (handle_irq_event+0x40/0x64)
    [ 10.513068] r10:c081bf10 r9:eec08000 r8:00000001 r7:00000000 r6:c082766c r5:eedfa2a0
    [ 10.513112] r4:eedfa240
    [ 10.513137] [<c0089eec>] (handle_irq_event) from [<c008d0f8>] (handle_fasteoi_irq+0xe4/0x1ac)
    [ 10.513150] r6:c082766c r5:eedfa2a0 r4:eedfa240 r3:00000000
    [ 10.513194] [<c008d014>] (handle_fasteoi_irq) from [<c008961c>] (generic_handle_irq+0x20/0x30)
    [ 10.513206] r7:00000000 r6:c08163fc r5:00000017 r4:c08163fc
    [ 10.513248] [<c00895fc>] (generic_handle_irq) from [<c008975c>] (__handle_domain_irq+0x70/0xec)
    [ 10.513269] [<c00896ec>] (__handle_domain_irq) from [<c0009504>] (gic_handle_irq+0x40/0x84)
    [ 10.513281] r10:00000000 r9:00000000 r8:fa213000 r7:fa212000 r6:c081bf10 r5:c081d948
    [ 10.513326] r4:fa21200c r3:c081bf10
    [ 10.513356] [<c00094c4>] (gic_handle_irq) from [<c0013c74>] (__irq_svc+0x54/0x90)
    [ 10.513371] Exception stack(0xc081bf10 to 0xc081bf58)
    [ 10.513389] bf00: 00000001 00000000 00000000 fe600000
    [ 10.513412] bf20: c05d322c 00000000 c0817558 c0815364 00000001 00000000 c081d56c c081bf6c
    [ 10.513431] bf40: c081bf4c c081bf60 c0034f74 c001073c 60000013 ffffffff
    [ 10.513444] r10:c081d56c r8:00000001 r7:c081bf44 r6:ffffffff r5:60000013 r4:c001073c
    [ 10.513504] [<c0010718>] (arch_cpu_idle) from [<c007c65c>] (default_idle_call+0x28/0x34)
    [ 10.513526] [<c007c634>] (default_idle_call) from [<c007c7b8>] (cpu_startup_entry+0x150/0x27c)
    [ 10.513549] [<c007c668>] (cpu_startup_entry) from [<c05ca0d8>] (rest_init+0x7c/0x94)
    [ 10.513561] r7:c0870000
    [ 10.513587] [<c05ca05c>] (rest_init) from [<c07cacc8>] (start_kernel+0x368/0x3e0)
    [ 10.513599] r4:c0870040 r3:c081a000
    [ 10.513630] [<c07ca960>] (start_kernel) from [<8000807c>] (0x8000807c)
    [ 10.513644] ---[ end trace b0aa3858056ad469 ]---

  • Hi,

    UNICACHEInvalidateAll seems to work. Do you have an idea why?

    Thanks
    Andreas
  • Hi Andreas,

    It is working as the cache was not in a clean state when you enabled.
    Invalidate made it clean.

    Regards,
    Rishabh
  • Hi,

    sorry after some testing I have to tell that the problem is still there.
    I am quite sure that Linux is not using GP-Timers.
    And Timer1 I can reset without a problem. Timer 2/3/4 cause hard fault.

    Andreas
  • Hi Andreas,

    Did you check if the Timer2/3/4 were running when you tried to reset?

    Regards,
    Rishabh
  • Hi,

    I checked the registers and I saw that if I enable TIMER2 (MODULEMODE = 0x2) before TimerReset(), the register 0x4a009738 is equal to 0x00020002 which says  "0x2: Module is in Idle mode (only OCP part). It is functional if using separate functional clock". But it should be "0x0: Module is fully functional, including OCP" ,right?

    What does OCP means? 

    Regards

    Andreas

  • Hi Andreas,

    This means you are trying to access Timer2 registers when Timer2 is off.
    May I know what exactly do you want achieve?
    OCP is protocol for communication used by hardware. You can search internet for details.

    Regards,
    Rishabh
  • Hi Rishabh,

    I found the problem. By mistake I changed a part of the A15 (Linux) clock. Now the HARD_FAULT is gone and the timers and code are running. But the TIMERX_CLKCTRL register of TIMER2/3/4 are still 0x00020002. I watched the register directly after reboot of linux and at start of main() of M4, so I guess that linux is doing this.

    So is this a correct setting or not?

    Regards,
    Andreas

  • Hi Andreas,

    This setting is correct, it means nobody in the system is using TIMER2/3/4.

    Regards,
    Rishabh
  • Hi,

    ok, but after TIMER_RESET(TIMER2) and TIMER_Configuration (M4 is now using TIMER2) I can see that the register is toggle between 0x00020002 and 0x00010002 (maybe I don't see 0x00000002 cause its changing to fast). Is this behavior correct?

    Andreas
  • Hi Andreas,

    The behavior could be ok depending on how M4 is using Timer2.
    Can you clarify how M4 is using Timer2.

    Regards,
    Rishabh
  • Hi Rishabh,

    TIMER2:

    - configuration: TIMER_AUTORLD_NOCMP_ENABLE, TIMER_FREE, TIMER_NONPOSTED, TIMER_INT_OVF_EN_FLAG
    - counting till counter overflows
    - interrupt at overflow
    - reload counter and start counting again

    Regards,
    Andreas
  • Hi Andreas,

    Although I don't know your full system, Timer configuration seems to be fine.
    I will close the thread if there are no further questions.

    Regards,
    Rishabh
  • Hi,

    ok, thanks for your support.

    Andreas
  • Hi Andreas,

    Kindly mark the post the answers your query as "This resolved my issue" in order to close the thread.

    Regards,
    Rishabh