• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 81 subscribers
  • Views 2146 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.

SYSRSTIV 0xA security violation, MSP430F5438A

Josef Janda
Prodigy 230 points


Hi,

I am geting  security violation flag in SYSRSTIV after self reset of my application. The reset usually comes after severeal hours of running. So it is hard to reproduce this error. Please could you tell me all reasons for generating the security violation reset of system? In the manual there is not much information. I only know this reset is usually caused by unauthorised memmory access such as restricted address of stack overflow.....  I will focus at stack overflow, but I think, there will not be problem. I use interrupts from RTC and timerB0, I do not use nested interrupts.  Are there any other reasons?

Thanks, Josef

  • 0
    Guru 227245 points

    I jsut checked teh users guide and the term 'security violation' only appears twiche in the whole guide: both in teh description of teh SYSRSTIV register and the reset logic. I actually don't know what triggers this reset.

    But the most likely reason why it happens is that the processor runs in the wild.
    One reason might be a stack overflow, but the same effect (only a reversed reason) is an index out of bounds access to arrays.

    Also, nested interrupts are only one possible reason for a stack overflow. Another one are recursions (code that directly or indirectly calls itself).

  • 0
    Guru 12160 points

    Hi Josef,

    As far as I know, the only thing that can cause the security violation is accessing the flash memory where the TI BSL resides (0x1000 - 0x17FF).  Even just reading this memory area without first disabling the protection (bit SYSBSLPE in register SYSBSLC) causes a security violation and subsequent reset.

    Do you have any ISRs written in assembly language?

    Have you tried looking for the "high-water mark" in your stack?

    Jeff

  • 0
    Prodigy 130 points

    I just had this problem.

    The reason was that I was modifying the DMAxSA, DMAxDA and DMAxSZ registers before turning off the DMAx (DMAxCTL.DMAEN = 0). I am using the DMA in repeated single-transfer mode with both source and destination addresses unchanged, so I am confident I was not accessing secured areas (like boot memory).

    I changed my code so the DMA is configured as follows and the problem disappeared:

    1. DMAxCTL.DMAEN = 0
    2. Set DMAxSA, DMAxDA and DMAxSZ with the appropriate values
    3. DMAxCTL = DMADT_4 | DMADSTINCR_0 | DMASRCINCR_0 | DMAEN

  • 0 in reply to Nuwanda
    Guru 227245 points

    When you set DMAxSA or DMAxDA to a 20 bit value (above 64k), this happens in two 16 bit writes, lower word first. If a DMA transfer happens just between these two, it might go to a wrong address, maybe the BSL area.

  • 0 in reply to Jens-Michael Gross
    Prodigy 130 points

    I am fairly certain that what you're describing was not the issue in my case, because the DMA was triggered by a timer with a 1-second timeout, and the problem happened around 500 ms after the previous transfer.

  • 0 in reply to Nuwanda
    Guru 227245 points

    It's also possible that writing these registers while the DMA is active will trigger a bogus transfer. I wouldn't expect this from a DMA module, but it is of course possible. It's surely not the normal condition that the DMA setup changes while a transfer is active.
    Other modules clearly state that changing certain registers while the module is active will lead to undefined behavior. (e.g. the USCI module)

**Attention** This is a public forum