• State
  • Locked Locked
  • Replies 10 replies
  • Subscribers 30 subscribers
  • Views 561 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.

MSPM0L1306: Hard fault from SysTick access

Jose Valdes
Prodigy 30 points
Part Number: MSPM0L1306
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

Hello,

We have been running a project successfully with a MSPM0L1306SDGS20 for around one year. We had to change to a larger version and switched to MSPM0L1306SDGS28, so from 20 pin to 28 pin. The same code that runs OK in the 20-pin generates a hard fault in the 28-pin micro. Some testing suggests that the hard fault is linked to read access of the SysTick->VAL register.

Other symptom is the fact that the timing for the hard fault to occur is variable but most of the times being between 150-200ms which means that there are a lot of valid SysTick accesses before a faulty one. This also means that the value of SysTick->VAL is different after every crash.

We were under the assumption that the only difference is the IC package footprint but the same in every other way. Any other differences that could be the issue here?

  • 0
    TI__Guru 71216 points

    Hi Jose,

    This is quite odd.  It does say in the TRM that access to the Systick registers must be on 32-bit word alignment, but  I would agree that simply switching to a larger pin-count device would not make sense. 

    Can you tell me about the build environment, complier, using sysconfig, etc?

  • 0 in reply to Dennis Lehman
    Prodigy 30 points

    Hi Dennis,

    We use our own build environment with IAR compiler and not using sysconfig.

    We actually "fixed' the issue already by initializing the entire memory region manually in addition to the IAR services that supposedly do that. Knowing this, the hard fault was likely caused by a memory ECC error. It seems different versions of the MSPM0 lineup have different combinations of ECC check, parity check or nothing, Could there be a difference on that aspect between the 2 devices?

  • 0 in reply to Jose Valdes
    TI__Guru 71216 points

    Hi Jose,

    Interesting.  Within the MSPM0L11xx/MSPM013xx the memory configurations are the same.  Just so I understand better what you did, in addition to the IAR services, what/how did you manually initialize the memory?

  • 0 in reply to Dennis Lehman
    Prodigy 30 points

    Hi Dennis,

    It was just creating a pointer to the RAM start address (0x20000000), write a zero to the pointer location and advance the pointer until the RAM end address (0x20000FFF) is reached .

  • 0 in reply to Jose Valdes
    TI__Guru 71216 points

    I believe the top of the stack is setup at 0x2000.0100 by default and is defined in starting address 0x0000.0000.  That would mean you are writing over the stack when you perform you initialization?

  • 0 in reply to Dennis Lehman
    Prodigy 30 points

    That description seems accurate. The stack is linked from 0x2000.0C00 to 0x20000.FFF, and the top address allocated in 0x0000.0000

  • 0 in reply to Jose Valdes
    TI__Guru 71216 points

    Hi Jose,

    Jose Valdes said:
    Some testing suggests that the hard fault is linked to read access of the SysTick->VAL register.

    Ok, how are you accessing this register? Directly, pointer, etc?

  • 0 in reply to Dennis Lehman
    Prodigy 30 points

    The content of a pointer to SysTick->VAL is copied into a 32-bit variable

    0x8AE8 = location containing the address of the 32-bit variable

    0x8AD8 = location containing the address of SysTick->VAL (- 4 bytes for some reason and this offset is compensated in the next LDR operation)

  • 0 in reply to Jose Valdes
    TI__Guru 71216 points

    Hi Jose,

    From what you show, I would appear that maybe the SysTick base address is loaded into r7 first, then the offset to the SysTick->VAL register is used in the indexed ldr instruction, but looking at the ARM structure (TIClang) it shows it at an offset of 8, not 4.

    Hmm...

    Let me keep digging.  With your workaround, are you able to move forward with your project for now?

  • 0 in reply to Dennis Lehman
    Prodigy 30 points

    Hi Dennis, I don't think the intention is to get the SysTick base address instead it seems just some addressing method or some situation with the byte order. I captured data again (with different addresses - sorry). At the end address 0xC6B4 is correctly pointing to E000E018 which is the SysTick->VAL address

    To answer your question, yes with the workaround we were able to move forward with the project.