• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 380 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.

TMS570LC4357-EP: VIM RAM fault injection: ESM ISR not being cleared

Abhimanyu Ghosh1
Prodigy 80 points
Part Number: TMS570LC4357-EP
Other Parts Discussed in Thread: HALCOGEN, TMS570LC4357

Hi all,

First off, apologies if this ends up in the wrong forum. I navigated to the Hercules forum and attempted to create a new thread, but the moment I use the actual part number I'm using, it appears my post gets assigned to "Other microcontrollers forum".

Question/issue 1:

In any case, I'm facing an issue performing fault injection of a correctable (i.e. single-bit) error into some word within the VIM RAM address space. I have generated a project in Halcogen where I enable ESM Group 1 line 83 (which as I understand it is the correctable VIM RAM ECC error.) I also verified VIM RAM ECC is enabled under VIM configuration. I set the ESM group 1 line 83 error to assert an ESM low-level IRQ (i.e. not FIQ) event, and then output some debug info within the esmGroup1Notification callback provided by Halcogen in HL_notification.c

To trigger the ECC error, I followed the procedure set out in the TMS570LC4357 TRM VIM chapter:

- I make sure ECCENA is set and VIM RAM has been initialized. (This is handled already by vimInit() which I call from main())

- I then enable ECC bits mapping by writing 0x5 << 8 into ECCCTL (more specifically, I write the absolute mask: 0xA << 0 | 0x5 << 8 | 0xA << 16 | 0xA << 24 into ECCCTL)

- Following this, I have tried either reading a word within the VIM ECC address space (which I map with a volatile struct containing an array of u32 entries), flipping one of the 6 LSBs, and writing that word back.... -or- doing the same but to vector entries within the VIM RAM itself.

In both of the above cases, I get an IRQ and vector to the esmGroup1Notification (from the esmLowInterrupt within HL_esm.c). When I print out the channel argument, I can see that it's correct (when I add back the offset the ISR took off, I see it's a notification for ESM channel 83). However, it seems the ISR keeps being called repeatedly, and I can't escape from the interrupt context. This is despite looking through TI's ISR code, where it's clear the ISR is clearing the error flag correctly by writing 1<<19 to SR4, as per the TRM.

For completeness, I am using Halcogen 04.07.01, targeting GCC tools. I am using GCC 10.2, built from the standard upstream crosstool-ng project, with the necessary big-endian multilib support.

The Halcogen project is the standard TMS570LC43x-targeted project, with the LIN1 High, RTI Compare 0 and ESM Low-level IRQs enabled. 

Thanks!

- AG

  • 0
    TI__Guru**** 190806 points

    Hi,

      Can you clear the interrupt flag early in the ISR instead of at the end right before ISR is exited. The clear action takes some cycles to propagate to the status register. It is possible that the ISR is exited but the clear action has not reached the register. In this case, the flag is still pending and it will trigger the interrupt again.

  • 0 in reply to Charles Tsai
    Prodigy 80 points

    So, from what I can see, the ISR is actually already cleared pretty fast. The first function being vectored to is esmLowInterrupt (this is actually the function registered in VIM RAM for the ESM Low level channel.)

    Immediately at function entry, I'm seeing a read of the IOFFLR register, which itself should clear a number of conditions according to the TRM. Right after that, after checking the value read from IOFFLR, the handler immediately writes to the correct SRx register at the right bit offset. It is only after all this that the esmGroup1Notification is called to run user code.

    As far as I can tell, this is the fastest a correctly-written IRQ handler can clear the ESM error condition flag. Is there an alternate procedure or some errata I have missed here?

    Thanks!

    - AG

  • 0 in reply to Abhimanyu Ghosh1
    TI__Guru**** 196306 points

    Hi AG,

    I reviewed the ESM ISR generated by HALCoGen, and noticed that there is a bug in the code. The highlighted part below should be vec-128 rather than vec-64

    I will submit a bug ticket later and add bug workaround to the release note. Thanks AG

  • 0 in reply to QJ Wang
    Prodigy 80 points

    I think our messages were about to cross paths Slight smile. I noticed that yesterday and fixed it based on the TRM chapter on the ESM registers.

    I also observed that I needed to actually clear the VIM SBERR flag and perform a write-back of the corrected vector based on SBERRADDR in order to correctly clear the event. It appears now that I am able to reliably inject single-bit recoverable errors into the VIM RAM.

    I have a few other questions but instead of hogging this thread I'll create a new topic.

    Thanks for the help, and I'm glad this also led to a bug being identified.