Hercules RM57 Prefetch abort happen after Flash ECC two bits mode self test and RAM ECC self test

Hello Jack,

  I don't think the ECC selftest will cause a prefetch abort. It is probably the invoking of the flash ECC test causing something else to happen that results in a prefetch abort. In the CPU you can find out the source of the prefetch abort by reading out the content of IFSR (instruction fault status register) and IFAR (instruction fault address register) registers. Additional information can be found in AIFSR (auxiliary instruction fault status register). Can you please tell me the content of these three registers when the prefetch abort happens?

Hi Charles:

Thanks a lot for fast responding!

I ran these self tests, below is the value captured by CCS:

IFSR: 0x00000000
IFAR: 0x12121210
AIFSR: 0x00000000

It seems AIFSR always has same value after several times running.

Thanks a lot!

Jack Gu

Hi Jack,
It looks like you are getting a MPU background fault. For some reason the address that is causing the error is 0x12121210. This is an illegal address. Can you try to use the Link Register (IR) to find out how the program counter jumps to this location?
I think it may have something to do with the OS. Will it be possible for you to run the same selftest without the OS to see if it is OS related?

Hi Jack,

  Have you resolved the problem?

  I have a simple example running all the safety diagnostic tests. After it finished all the tests it jumped to the main() without problem. My example does not have any OS. Please take a look and see if you can replace example SafetyLib.c in my example to your project. I generated the example from HalcoGen.

1651.RM57_Safety_library.zip

Hi Charles:

Thanks lot for your support! I checked your sample startup code, after SRAM and Flash test, MCU will be reset by triggerring STC test, this will have no prefetch abort happen as whole CPU is reset, which is similar what we are doing now. In our temporary implementation, after SRAM ECC and Flash ECC test, we trigger the software reset, so no prefetch abort happen also.

Today I think I made big progress for this, please find below detail information I found and the solution I implemented:

I compared whole MCU register before and after SRAM ECC test, I found one FIQ interrupt is triggered, but this interrupt is reserved interrupt (VIM Channel 1) from TI datasheet. The value of vimREG->INTREQ0 and vimREG-> FIQINDEX are 0x00000001 after test, when I cleared vimREG->INTREQ0 register to 0, even without CPU reset, no prefetch abort will happen anymore. I believe this could be the root cause of prefetch abort. Could you help to check why this reserved interrupt triggered? It will be triggered under SRAM ECC one bit and two bits self test, and Flash ECC two bits self test, but not for Flash ECC one bit self test.


Thanks a lot!

Jack Gu

Hello Jack,

  I think the microcontroller has detected an error. Please look at the ESM module and check all the error status registers and let me know which one was set after you run SRAM ECC.  I think you must have a ESM group 2 error. When there is an ESM error, the error becomes a FIQ interrupt to th VIM module. However, a FIQ interrupt should only result in a FIQ exception, not a prefetch abort exception.

Hi Charles:

No any ESM error (any group) was triggered after calling ECC self test function. Everything is fine except this reserved interrupt raised. The fact is that prefetch abort will definitely happen if this reserved interrupt not cleared. AfterI cleared this reserved interrupt after ECC self test, no prefetch abort happen any more. And this reserved interrupt will happen under Flash ECC two bits and SRAM ECC one bit/two bits self test, but not for Flash ECC one bit self test.

As we use Micrium uCOS in our software, prefetch abort happen immediately when first task starts to run, I guess it is because of content switch, this reserved interrupt somehow change the behavior of CPU.

My concern is why reserved interrupt triggered. I wonder whether some other self test will have same problem, it could be Ok to reset CPU after performing all the self test during startup, but if we want to do some self test periodically during run time, if such or similar reserved interrupt triggered, this will crash whole system.

Thanks a lot!

Jack Gu

Hi Jack,

 It is not a reserved interrupt. VIM channel 0 is connected to the ESM. VIM channel 1 is reserved. When you get an interrupt on channel 0 the vimREG->INTREQ0 will show 0x00000001. The FIQINDEX will also show 0x00000001 because 0x00000000 means there is no interrupt. 0x00000001 corresponds with channel 0 and 0x00000010 will correspond with channel 1 and so on. You do see 0x00000001 on the FIQINDEX register, isn't? You can think of the FIQINDEX as providing a value that is the channel# + 1.

  Back to your observation that you don't see any ESM errors but you see vimREG->INTREQ0 getting set for 0x00000001. I still can't explain it. Somehow the ESM flags are getting cleared after you run the selftests. As soo as you run the SRAM 2-bit ECC test can you immeidately stop tosee if any ESM flags are set? Perhaps you can put a breakpoint on the line right after you call the SRAM selftest.

 Have you had a chance to run these selftests without the OS? Will you still see prefetch abort. I kind of wanting to isolate the prefetch abort to make sure that it is the selftest alone that causes the abort of if it is a combination of selftests plus the OS that causes the abort.

You also mentioned that you will get a prefetch abort when OS starts the first task. Can you elaborate on this? Do you mean without any selftest you will see prefetch abort when the OS starts the first task?

Hi Charles:

You are right, the interrupt is ESM high level interrupt, the index 1 confused me.

ESM error will happen during ECC self test , but it will be cleared at the end of ECC self test function. This can explain why this interrupt triggered.

Without OS running, there is no prefetch abort even with this interrupt flag uncleared. And there is also no prefetch abort without performing ECC self test.

I still need to figure out why this interrupt trigger prefetch abort, maybe ESM ISR doesn't handle this interrupt properly, I will check in detail. The ESM ISR that we are using if from TI safety library sample code, it is from Sl_esm.c file.

Thanks a lot!

Jack Gu

Hello Jack,

  One thing I want to check with you is if you had created the HL_sys_startup.c with the selftest sequences from HalCoGen example for RM57 or you somehow port the HL_sys_startup.c from other Hercules devices? The example I sent you is based on a HalCoGen example for using safety library on the RM57 device. 

  Do you have the cache enabled? If you do, I'd like you to try disabling it. At the moment I don't know what could be the root cause. I just want to rule out if the cache can have any effect. Before the main() is called there should be a call to _cacheEnable_(). Comment out the call to enable cache and let's see if that makes a difference.

Hi Charles:

    HL_sys_startup.c is initially created from HalCogen, then I added self test which has similar sequence with your example. Cache is disabled before main function, so this means all self tests during startup are running with cache disable.

    I will debug the ESM high interrupt ISR more in detail to get some clue.

Thanks a lot!

Jack Gu