TMS570LS3137-EP: TMS570LS3137 - Safety library implementation - Prefetch abort exception when power cycling the board

Hi Seb,

Can i get your complete project so that i can reproduce the issue and debug it?

You can even do a private message with complete project?

--

Thanks & regards,
Jagdish.

Hi

Thanks a lot for looking into this.

Find attached the project. I had to deal with an other issue so far today. Back into it now. 

Let me know if you need further info on the problem.

Bootloader_ZooxBoard_ExtNvm_Safety.zip

Thanks for your assistance.

Regards

Seb

Hi Jagadish

Did you have any chance to look into this ?

Thanks.

Seb

Hi

I managed to isolate the line where it happens  in syst_startup.c

Just before enabling the interrupt we can see that FIQ channel 0 pending and IRQ Channel 21:

FIQ Will be prioritized but FIQVecReg is loaded with an invalid address:

IRQVecReg is loaded with with the address VIM Parity error handler:

In the VIM, both ESM High and Low are enabled.

ESM High is hardwired to channel 0 as FIQ.

The VIM Parity register shows a parity error even is disabled :

When enabling interrupts, CPU branches into address in FIQVecReg going to exception with abort registers showing and address close to the branch address in FIQVecReg:

Now why I get a spurious address in FIQVecReg …

It happens during the VIM parity check in sys_startup.c

We have the VIM parity registers going as with FbParErr used to point to the parity error handler taking the address 0xC83CE02 shown during the abort:

Interrupt registers now showing FIQ As pending and FIQRegVec showing the erroneous address:

CRC Calc on VIM RAM creates a parity error on the VIM After parity check being enabled line #1269

Partial solution found - Introduce a call to vimInit before parity checks on peripheral RAM. This to ensure that FIQRegVec gets a correct value in before any FIQ can be triggered by a parity check.

This is resolved the prefetch abort but now stuck into an esm low interrupt with the VIM parity - seems interrupt is never cleared as Parity error handler is never called ...

I was looking into the demo project for the safe library and I might have missed sonethign. I triple checked though but can't find anythiung really diffrent.

Could you please let me know if I'm implementing the safety library the coirrect way or if I missed something ?

Thanks

Regards

Seb

Hi Seb,

Sebastien Chapeau said:

FIQ Will be prioritized but FIQVecReg is loaded with an invalid address:

IRQVecReg is loaded with with the address VIM Parity error handler:

When parity error is injected and RAM location with parity error is read, the content of fallback register is assigned to IRQVECTOR and FIQVECTOR registers. In HalCoGen code, the content of fallback register is the address of parity error handler.

Sebastien Chapeau said:

Interrupt registers now showing FIQ As pending and FIQRegVec showing the erroneous address:

If ESM interrupt is enabled for VIM parity error, and the interrupt is mapped to FIQ, you will get a pending FIQ when reading the location with parity error.

I saw that both FIQVEC and IRQVEC have a correct value: 0xC83CE02 

Sebastien Chapeau said:

CRC Calc on VIM RAM creates a parity error on the VIM After parity check being enabled line #1269

vimParityCheck() restores the VIM RAM back to the correct data after parity self-test, so CRC Calc on VIM RAM should not creates a parity error.

Sebastien Chapeau said:

Could you please let me know if I'm implementing the safety library the coirrect way or if I missed something ?

Can you please disable the interrupt because the parity self-test? 

Hi QJ

Thanks a lot for your feedback. I'm picking the subject back up after a 2 weeks break.

OK. I think I get why we have the behavioour we observe. I will disable the interrupt and check, I will also come back to you regarding the CRC creating the parity error after disabling the ingterrupt.

I'd like to understand the following though:

- Why 0xC83CE02 is a correct value ?

- What's the best way to check about modules parity at run time ?

I see for example that parity errors are not mapped to ESM in the safety lib example but the idea we have is to enable those for VIM / CAN / SPI and deal with the error at application level onbce flagged by an interrupt.  

The safety example does run time check instead.

Would you also have an example of a selftestFailNotification() implementation ?

Many thanks.

Regards

Seb

Sebastien Chapeau said:

- Why 0xC83CE02 is a correct value ?

0xC83CE02 is the VIM fall-back ISR address defined in FBPARERR. When VIM table has an error, the ISR address in FBPARERR will be provided to RQVECREG and FIQVECREG. The "correct" means value of interrupt vector register = address in FAPARERR.

Sebastien Chapeau said:

I see for example that parity errors are not mapped to ESM in the safety lib example but the idea we have is to enable those for VIM / CAN / SPI and deal with the error at application level onbce flagged by an interrupt.  

Yes, the ESM interrupt is disabled before doing the parity selftest. The SDL uses the polling mode to check if the ESM flag is set or not.

Sebastien Chapeau said:

Would you also have an example of a selftestFailNotification() implementation ?

No, I don't have an example of selftestFailNotification().

Hi QJ

Thanks for your feedback.

Disbaling VIM Parity interrupt in ESM solved being stuck into an esm low interrupt with the VIM parity.

The CRC at init causing a parity error does not appear any more.

Still I have to keep the vimInit() here : 

Otherwise I get he prefecth abort I had previously, caused by the vimParityCheck() function. FIQVecReg gets loaded with the address in FBPARERR.

What I can observe is that the execution arrives to enableParity() functionwith FIQ == 0x01 indicating an esmHigh interrupt is already pending.

The pending interrupt is caused by SRAM Selftest.

IRQ are disabled within the SL_SelfTest_SRAM() function but a FIQ is trigerred instead. I believe this is normal behavior as RAM address bus parity error is linked to ESM group 2 which is not maskable.

At this stage FIQRegVec contains the following: 

So in summary, before entering the parity checks section, a pending FIQ exists.

When parity checks executes on the VIM, the FiqVecReg gets loaded with the adress in FBPARERR.

When enabling interrupt, because of the pending FIQ, preftech abort occurs.

I'll check with the safety project but would appreciate pointers on what I might have missed.

Regards

Seb