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

Original question:

IOMM Error Enable Status Register Configuarion

RM48L952: IOMM Error Enable Status Register Configuarion

Jamie Wardlaw
Expert 1895 points
Part Number: RM48L952
Other Parts Discussed in Thread: HALCOGEN

Hello,

I am trying to invoke IOMM errors to exercise my ESM error handling mechanism. From the TRM on the RM48L952 section 4.4.1 I note that any write to the IOMM registers without first unlocking them would generate an error. I looked at the muxinit() code of Halcogen and copied logic to alter to the pinMuxReg->PINMMR at runtime. I expect this would generate the configured ESM error response. But nothing happened. 

Checking register values it is clear that ErrEna register is 0x0000000 so there is no error detection enabled in the IOMM module even though the ESM is configured to handle the channel 37 error with interrupt and nError driven low. 

I checked pinmux.c and nowhere do I see the ERR_ENABLE_REG set to catch the errors. So I have added logic to pinmux.c, before the IOMM pin muxing is disabled to enable error detection. Running this code, with my application writes to PINMMR4 I still can't throw the error. The register activity of IOMM indicates that nothing is being triggered and my ESM handlers are definately not being triggered by the channel 37 interrupt. 

See my code below, what am I missing here? How do I prove out the IOMM error detection?

Thanks

Jamie

  • 0
    Expert 1895 points

    So further investigation it became clear that my problems stem from the default startup logic leaving the MCU in Privileged mode. At runtime, after startup, there is no reason for our application to remain in privileged mode so I added assembler instruction to move to USER mode. See below:

    #ifdef __DEBUG__
                        /* Enter USER Mode  - ensures full protection on memory regions */
                        asm(" CPS #0x10");
                        pinMuxReg->PINMMR4 =    0xFAFAFAFA;

#endif

    I now successfully trap the channel 37 error with my ESM handler.

    I have been aware of the R4 modes for some time, but it had not yet occurred to me that they application would remain in USER mode which basically undermined the inherent memory protection functions of the MCU. It would be good if it was highlighted more clearly, perhaps in HALcogen, that entry to USER mode after system initialization is something to consider. Especially when the switch to user mode, if not implemented, essentially invalidates other settings presented in HALcogen.

  • 0 in reply to Jamie Wardlaw
    TI__Mastermind 21425 points
    Hello,
    I am glad you found a solution!

    Best regards,
    Miro