• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 31 subscribers
  • Views 901 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.

TM4C1294KCPDT: CFGCTRL MAINPEND SWTRIG

Genatco
Guru 56043 points
Part Number: TM4C1294KCPDT


How can repeated unprivileged SW writes to SWTRIG REG52 (page 163) not cause NMI exceptions when ever CFGCTRL (REG60) MAINPEND bit (page 175) has never being set?

Seems reasonable after reading datasheet several times the only way to enable privileged mode for SW is by enabling the MPU for the default memory map (Table2-4). Even though MPU is never being configured in any Tivaware example that ever used SWTRIG REG52, should be causing NMI exception BUSFAULT according to the datasheet. So how or where is MAINPEND being set that allows privileged writes to other registers that require an UNLOCK KEY to make aligned writes, such as REG58 and others do require a key? Seemingly it should require an UNLOCK KEY to access SWTRIG if the MAINPEND bit is never set first by SW writes to SWTRIG?

Of particular interest in blue:

3.4 NVIC Register Descriptions
This section lists and describes the NVIC registers, in numerical order by address offset.
The NVIC registers can only be fully accessed from privileged mode, but interrupts can be pended
while in unprivileged mode by enabling the Configuration and Control (CFGCTRL) register. Any
other unprivileged mode access causes a bus fault.
Ensure software uses correctly aligned register accesses. The processor does not support unaligned
accesses to NVIC registers.
An interrupt can enter the pending state even if it is disabled.
Before programming the VTABLE register to relocate the vector table, ensure the vector table
entries of the new vector table are set up for fault handlers, NMI, and all enabled exceptions such
as interrupts. For more information, see page 170.

 

  • 0
    TI__Guru**** 191906 points

    Hi BP101,

     Can you check the CONTROL register (REG21). It will tell you if you are in privilege mode.

     As far as the statement "An interrupt can enter the pending state even if it is disabled.", what is your question about it? I don't see an issue with this statement. It merely says the interrupt can be pending. The PENDx register can set after receiving an interrupt request from the peripherals. However, this does not mean an exception will be taken by the core, not until the interrupt is enabled. This is no different than the RIS register and the IM register in the peripherals. The RIS (like the PENDx register in the core) register can set but without the IM (interrupt enabled) the interrupt request is not generated. 

  • 0 in reply to Charles Tsai
    Guru 56043 points

    Hi Charles,

    Charles Tsai said:
    Can you check the CONTROL register (REG21). It will tell you if you are in privilege mode

    REG 21 POR 0 = Only privileged software can be executed in Thread mode.

    According to datasheet MCU automatically switches from handler mode into thread mode after POR. So how has any Tivaware example project even ones using LWIP 1.4.1 with Semaphore SWTRIG interrupt ever set TMPL bit  in REG21? How are other SWTRIG SW interrupts pending and active if the MCU is in NON-Privileged mode? It would seem the MCU is always in privileged mode or SWTRIG interrupts would never pend and act as if they were disabled, yet they do not. This seems to indicate issues with NVIC handling of SUB priority levels is also failing as described in this forum and again this thread below!

    Charles Tsai said:
    As far as the statement "An interrupt can enter the pending state even if it is disabled.", what is your question about it?

    This statement is made in the context of NVIC and may explain REG21 SWTRIG issues with NVIC if the CPU is not in privileged mode. Disabled interrupts can still PEND and switch back to Active mode during the time NVIC handles and process illegal peripheral Pends after first attempting AHB arbitration access and not flagging an BUS fault in the process.

    I recently posted very issue about edge counter being disabled after entering handler clearing interrupt allowed reentrance during 500ms periods that only re-enabled edge counts interrupt. That 500ms delay to control interrupt state of another timer under SUB priority interrupt control failed inside the 500ms Oneshot launched from edge counters interrupt context. The edge counters and one shots SUB priority levels were being ignored by NVIC, why?

    Might it have something to do with SWTRIG REG21 illegal Accesses of SUB priority interrupt groupings somehow pollute NVIC individual SUB priority levels in a 3:5 split? How many illegal NVIC SUB priority accesses violate ARM cortex AHB arbitration rules and 256 levels of any single interrupt thus causing mayhem in TI modified handling of only 3 bits within REG58 [10:8] bit splits? How can NVIC be SPEED up lower priority interrupts handling when higher priority grouping interrupt handlers start to arbitrate data/address space on the AHB?  That behavior goes beyond anything of reasonable logic as the lower priority grouping handlers if anything should SLOW down.

    I'd say that is a very good example of the statement above remains unclear why it is being stated links relative to protected mode of SWTRIG register.  

  • 0 in reply to Genatco
    Guru 56043 points

    Ensure software uses correctly aligned register accesses. The processor does not support unaligned accesses to NVIC registers.

    Alternatively how is uint32_t (DWORD) writes to set peripheral _MIS bits maintaining 16 bit (WORD) aligned accesses to preempt NVIC? So NVIC may not fully support unaligned DWORD interrupt requests via AHB writes to his register, yet still pends requests but without SUB priority levels for AHB arbitration handling.

    The datasheet seems to imply the difference between Aligned register access and Unaligned register access directly infers the word length determines each access mode. If that is indeed true, Tivaware HWREG calls NVIC with unaligned access.

  • 0 in reply to Charles Tsai
    Guru 56043 points

    Table 2-10 also shows mode EXC_RETURN behavior (Thread/Handler) and seems 0x0 being set to LR on entry from handler after RST.

    Oddly (below) only see BX instruction and LR call _C_INT00 but after Reset no EXC_RETURN value behavior is being set to LR. Again as Higher priority INT group assert handlers (PWM0, ADC0, GPTM4) are speeding up the lower priority handlers when they assert pends active. Perhaps a result of illegal SWPEND [15:0] DWORD access via an unprivileged mode default behavior of LR? Who knows what NVIC is doing but he sure ain't handling priority groups as expected if seemingly always in Handler mode when pend or unpend relative MSP/PSP occurs.

    2.5.7.1
    At the same time, the processor writes an EXC_RETURN value to the LR, indicating which stack pointer corresponds to the stack frame and what operation mode the processor was in before the entry occurred. If no higher-priority exception occurs during exception entry, the processor starts executing the exception handler and automatically changes the status of the corresponding pending interrupt to active. (e.g. even if disabled???)
    If another higher-priority exception occurs during exception entry, known as late arrival, the processor starts executing the exception handler for this exception and does not change the pending status of the earlier exception.


    386 ;----------------------------------------------------------------------
    387
    388 ;*****************************************************************************
    389 ;* FUNCTION NAME: ResetISR *
    390 ;* *
    391 ;* Regs Modified : *
    392 ;* Regs Used : LR *
    393 ;* Local Frame Size : 0 Args + 0 Auto + 0 Save = 0 byte *
    394 ;*****************************************************************************
    395 00000000 ResetISR:
    396 ;* --------------------------------------------------------------------------*
    397 .dwcfi cfa_offset, 0
    398 .global _c_int00
    399 00000000 BFFEF7FF! b.w _c_int00 ; [KEEP 32-BIT INS]
    400 $C$DW$28 .dwtag DW_TAG_TI_branch
    401 .dwattr $C$DW$28, DW_AT_low_pc(0x00)
    402 .dwattr $C$DW$28, DW_AT_TI_return
    403 00000004 4770 BX LR ; [DPU_3_PIPE] ; [ORIG 16-BIT INS]
    404 ; BRANCH OCCURS ; []
    405 .dwattr $C$DW$27, DW_AT_TI_end_file("../tm4c1294kcpdt_startup_ccs.c")
    406 .dwattr $C$DW$27, DW_AT_TI_end_line(0xf8)
    407 .dwattr $C$DW$27, DW_AT_TI_end_column(0x01)
    408 .dwendentry
    409 .dwendtag $C$DW$27

  • 0 in reply to Genatco
    Guru 56043 points

    The point BX followed by LR instruction is not required or (may) somehow force Reset Thread mode back to Handler when it should not. Since the datasheet control analysis implies the CPU enters Thread Privileged mode automatically, not by force loading LR to the desired Thread mode. Please feel free to branch this post to a new thread since it does jump to a new topic however still relative to the same issue why NVIC is not behaving as expected he should. 

    Again I return to NVIC SUB priority order (AIRCR) AKA REG58 table 3-9 differs from ARM Cortex M4v7 technical reference Table B1-7. TM4C1294x datasheet Table 3-9 has not fully explained Tivaware SUB priority grouping splits (4:4, 3:5) seemingly don't exist in the M4v7 NVIC priority schema. How or way does ARM say one thing and TI the exact opposite table 3-9 to ARM B1-7? Why would TI attempt to confuse the community by changing the subpriority interrupt grouping already configured in M4v7 Arm Cortex NVIC? Logically it seems that is what has occurred! 

    ARM Technical reference shows 8 priority group levels set by 3 bits [10:8]. Yet we still have to configure the lower 4:0 bits of SUB priority interrupt fields in 7:5/7:4 split. Tivaware IntPrioritySet() configures the interrupt level priority the same as the groups. Seemingly only shifted upper 3 group bits into lower 4 bits for each specific interrupt sub priority assignment. Tivaware IntPrioritySet() incorrectly assigns the same sub priority to all interrupts in the same grouping thus conflicting with AIRCR split and sub priority set by 4:0 sub priority bits specified by AIRCR [10:8] bits.

  • 0 in reply to Genatco
    Guru 56043 points
    Seemingly ARM table B1-7 suggests 7:5 split any single priority grouping can assign [4:0] bits {INA,INTB,INTC,INTD} producing 16 levels of sub priority, not simply 1 as shown in table 3-9. How does AIRCR 7:5 split lower [4:0] bits relate to interrupt application handling of peripherals _MIS processing speeds some how increasing for lower priority groups as higher priority exceptions assert relative to AHB bus arbitration, remains unanswered.

    Again the lower priority peripheral MIS groups should if anything SLOW down application processing speed. Not SPEED up as higher priority interrupt pends immediately assert an active state in NVIC. Especially true for slower late arrivals (30Hz) already tail chaining in lower priority groups should slow down according to ARM priority handling split schema.