selftest will block _enable_interrupt_();

cc liu

Other Parts Discussed in Thread: TMS570LS1227, HALCOGEN

Dear All

I am using tms570ls1227, I'd like to do some selftest at the beginning of booting. But I find that if I use fmcBus1ParityCheck(); or checkRAMAddrParity, both of them will have side effect on the _enable_interrupt_(); function in main. When goes to _enable_interrupt_, the program will reset again and again.

And strangely, even I tick all the checkbox in the safety init in HALCOGEN, I still didnt find anywhere these two functions have been called. It looks like the TI engineers write these two function but not intend to use them.

So I deliberately called them with others selftest fucntions, but as I said above, the _enable_interrupt_ can not work properly. But I alter _enable_interrupt_ to enableIRQ, it looks OK.

Could you guys try this for me and Let know how to solve this problem, many thanks.

Regards

Leo

over 9 years ago

0 Charles Tsai over 9 years ago

TI__Guru**** 191906 points

Hi Leo,
The fmcBus1ParityCheck() and checkRAMAddrParity() are to check the address/control parity between the CPU and the Flash controller/RAM controller respectively. In HalCoGen, I don't see any checkboxes for them. I guess this is why you said it has no effect when you check all the boxes. Note that if you check the Enable Flash ECC check and Enable ESRAM ECC check they only perform selftest for the ECC which is on the datapath, not on the address/control path.

When the flash controller is subject to the address/control parity check using fmcBus1ParityCheck(), the controller will generate an external error to the CPU and the CPU is supposed to take an abort exception. Did you notice this? Can you place a breakpoint at either the prefetch abort or data abort exception? I tend to think you will get a prefetch abort exception.

0 cc liu over 9 years ago in reply to Charles Tsai

Expert 1150 points

Dear Charles
Thank you for your advice, but what I observed is different from what you guessed. I placed breakpoints at each branch here:
resetEntry
        b   _c_int00
undefEntry
        b   undefEntry
svcEntry
        b   svcEntry
prefetchEntry
        b   prefetchEntry
        b   _dabort
        b   phantomInterrupt
        ldr pc,[pc,#-0x1b0]
        ldr pc,[pc,#-0x1b0]

when I go _enable_interrupt_();   it goes to   resetEntry immediately. You mentioned the "external error" , can you elaborate this, how can I observe this signal? I know that esm will do something on the nERROR pin, but on our board, we didnot use the nERROR .
Now I'd like to know which is the source to the reset? Warm reset? External pin reset or the cpu internal reset.
I also have done one experiment to check the IRQ FIQ factors, I use :
    _enable_IRQ();
    _enable_FIQ();
instead of _enable_interrupt_();

the _enable_IRQ can be go through but _enable_FIQ cannot,
I know that esm high priority interrupt can only go to FIQ, so now I think maybe fmcBus1ParityCheck has generate some high esm error which results in FIQ interrupt.
I need some help with
1. when it goes to resetEntry , please provide me some methods to find the source of the reset
2. Please teach me how to treat the FIQ properly?
Best Regards
Leo

0 Charles Tsai over 9 years ago in reply to cc liu

TI__Guru**** 191906 points

Hi Leo,

Can you step through the disassembly code inside the _enable_interrupt_() to find out how and when the reset is taken. Is it upon entry to the _enable_interrupt_() or within the code inside the function or upon exit from the _enable_interrupt_() that causes reset. Normally you can find out the cause of the reset by reading the SYSESR register in the SYS module. But I kind of doubt your reset is due to WD or CPU reset or external reset. This is the first thing to check. I suspect that somehow there may be some corruption of the memory (i.e corruption of the stack).

I'm interested find out if you replace the _enable_interrupt_() with any function to see if you have the same result. For example, change your code sequence such that you call gioInit() or any function before _enable_interrupt_(). Will you see the same reset issue?

Also if I remember correctly, perhaps the fmcBus1ParityCheck() is intended for use in conjunction with the CPU running code out of the RAM instead of the flash. As I said this function is intended to test the address and control signals between the CPU and the flash. For this test, you will run code from RAM first. You will then put the flash in the diagnostic mode where you will try to do a read from the flash. This read will then cause the address and control signals to fail the parity checking. When you run code from the flash and try to call this diagnostic test, I think the cod fetching itself will get an abort. However, you stated that you don't see any abort.

What happens right after you call fmcBus1ParityCheck() before it even goes to main()? Do you get an abort or any errors in the ESM?

0 cc liu over 9 years ago in reply to Charles Tsai

Expert 1150 points

Dear Charles
Thanks for your constructive suggestions. I have spent whole day on this.
1. I steped through the disassembly code inside the _enable_interrupt_() , when I use step into, it works when I use step over, the probles occurs.
2. I monitored the System Exception Status Register (SYSESR) [offset = E4h] , when the reset occurs, EXTRST is set, but our nRST is connected to nothing, so it is low all the time, for nPORRST, we connect it to a 3.3v so it is high all the time.
3. I also tried to change the position of calling of these functions, please refer to the "sys_startup.c " :

/* USER CODE BEGIN (72) */
/* USER CODE END */

/* Enable IRQ offset via Vic controller */
_coreEnableIrqVicOffset_();

/* USER CODE BEGIN (73) */
/* USER CODE END */

/* Initialize VIM table */
vimInit();

/* USER CODE BEGIN (74) */
/* USER CODE END */

/* Configure system response to error conditions signaled to the ESM group1 */
/* This function can be configured from the ESM tab of HALCoGen */
esmInit();

when I call these either in USER CODE BEGIN (72) or /* USER CODE BEGIN (73) */ , it failed.
but when I call them in /* USER CODE BEGIN (74) */ ,it works.
4. But, there is still something I am not satisfied with.

First, can you elaborate the CPU RESET and SYSTEM RESET of CCS5.5 in debug mode, I find them so different.
When I reset the system, everything is correct. But when I do cpu reset, it will first goes to esmGroup2Notification when I do the selftest.
It looks like CPU reset will remain enabling the esm interrupt.
Best Regards
Leo

0 Charles Tsai over 9 years ago in reply to cc liu

TI__Guru**** 191906 points

Hi Leo,

cc liu said:
I monitored the System Exception Status Register (SYSESR) [offset = E4h] , when the reset occurs, EXTRST is set, but our nRST is connected to nothing, so it is low all the time, for nPORRST,

Are you monitoring the nRST using a scope? You just said that the nRST is low all the time? This is a weird behavior. If nRST is low all the time then the device is always in reset. You also said that only EXTRST bit is set. Do you see any other flags? Before you step over the _enable_interrupt_() what did the SYSESR show? I want to make sure if the EXTRST was already set prior to the calling of _enable_interrupt_().

cc liu said:
when I call these either in USER CODE BEGIN (72) or /* USER CODE BEGIN (73) */ , it failed.
but when I call them in /* USER CODE BEGIN (74) */ ,it works.

What do you mean by it failed. When you call _coreEnableIrqVicOffset_(), does it reset just like when you called _enable_interrupt_()? Or it failed with different signature. If you are getting a reset after calling _coreEnableIrqVicOffset_() then how can it advance to the next instruction. You will forever get reset upon calling _coreEnableIrqVicOffset_(), isn't? Or you comment out the _coreEnableIrqVicOffset_() and try out calling vimInit() doing one at a time.

cc liu said:
First, can you elaborate the CPU RESET and SYSTEM RESET of CCS5.5 in debug mode, I find them so different.
When I reset the system, everything is correct. But when I do cpu reset, it will first goes to esmGroup2Notification when I do the selftest.
It looks like CPU reset will remain enabling the esm interrupt.

In debugger, the system reset is reset that will reset the device. The CPU reset is not really a reset. It merely moves the CPU's PC (program counter) to 0. So the CPU reset does not really reset anything.

0 cc liu over 9 years ago in reply to Charles Tsai

Expert 1150 points

Dear Charles
Thank you for your help. So far, my problem is solved, please allow me to do more tests then I will verify the answer.
Best Regards
Leo

0 cc liu over 9 years ago in reply to Charles Tsai

Expert 1150 points

Dear Charles
I'd like to know what the __TI_auto_init(); do?
Before calling the __TI_auto_init, I have done my CPU selftest and I record the result in ram. But after __TI_auto_init, the ram is cleared.
To be more precise, I use the static struct variable to record the selftests' result and I intended to use SCI connected to PC to read this variable out. But after __TI_auto_init, it became all 0.
I need your help.
Regards
Leo

0 Charles Tsai over 9 years ago in reply to cc liu

TI__Guru**** 191906 points

Hi Leo,
The function __TI_auto_init is part of the TI ARM compiler, the source code is part of the compilers C standard library. It's purpose is to initialize the C environment such as, global variables, static variables.

0 cc liu over 9 years ago in reply to Charles Tsai

Expert 1150 points

Hi Charles
So __TI_auto_init will clear the ram,right? If so, how can I keep the variables which were generated before __TI_auto_init such as selftest results?
Best Regards
Leo

0 cc liu over 9 years ago in reply to Charles Tsai

Expert 1150 points

Hi Charles

I have also noticed a strange thing, according to SPNS226E page81:

N2HET2 - RAM parity error Group1 34

the N2HET2 - RAM parity error will go to ESM Group1 channel 34

but I didnt see that in the esmGroup1Notification, so I check the HALCOGEN(newest ver4.6),

It can not be checked, I tried N2HET1 everything is right.

and for channel 44 it should be reserved, but in the HALCOGEN, it can be checked even there is no name for this channel.

And for the ESM group2(channel 10 and 12 ), I can see the register is changed through memory browser, the it does not go into interrupt, for all the other ESM group channels, it works.

Looking forward to you reply.

Best Regards

Leo

0 Charles Tsai over 9 years ago in reply to cc liu

TI__Guru**** 191906 points

Hi Leo,
For the uninitialized variable you can take a look at this post. .

I will suggest that you post your question to the compiler team as they will be more knowledgeable to get it working. I was trying a different method (creating a .bss symbol in an assembly file) but it didn't work for me. I'm still trying to understand why.

On the N2HET2 issue in the HalCoGen, I was able to see the same problem. I will open a ticket to the HalCoGen team.

I'm not clear on your last question about the ESM GP2.10 and 2.12. Which register was changed? This is an ESM GP2 error. It will go to the FIQ interrupt, not IRQ interrupt. Did you enable FIQ interrupt?

0 cc liu over 8 years ago in reply to Charles Tsai

Expert 1150 points

Hi Charles

Thank you for your help. I am quite sure that I enable the both of FIQ and IRQ interrupt, because when I created other esm group 2 errors, the esmGroup2Notification can be enter, such as channel 4 6 8. But when I create ram address bus parity error, the esmREG->SR1[1U] bit 10 and 12 is set., but the esmGroup2Notification will not be entered, and also checked "void esmHighInterrupt(void)" , it was not entered either.

Today I gor another problem, we was using the TMS570ls1227, now we changed to 0714. We didnot change our code, but something wrong with the TI_Fee_Init();

when I call TI_Fee_Init(); it goes to dataabort , and in detail, it was caued by

/* Enable Single bit error correction */
Device_FlashDevice.Device_BankInfo[FEE_BANK].Device_ControlRegister->EeCtrl1.EE_CTRL1_BITS.EE_EDACMODE = 0xAU;

after entering the dabort, it goes to "noRAMerror" and finally goes to "subs pc, lr, #8 ; restore state of CPU when abort occurred, and branch back to instruction that was aborted"

then I guess you can image what will happed next, it will execute

"Device_FlashDevice.Device_BankInfo[FEE_BANK].Device_ControlRegister->EeCtrl1.EE_CTRL1_BITS.EE_EDACMODE = 0xAU; ” again and again in a infinite loop

Strangely , even if there is single bit ecc error , the data abort will not be called, because correctable and uncorrectable fee ecc errors are all esm group1 error(channel 35 36), why it will cause data abort?

Best Regards

Leo

0 Charles Tsai over 8 years ago in reply to cc liu

TI__Guru**** 191906 points

Hi Leo,
Can you please tell me how you created the address parity failure?

Do you see the parity error flag set in the RAMERRSTATUS register in the TCRAMW module? Do you see the correct address which caused the address parity error that is captured in RAMPERRADDR register in the TCRAMW module?

As for the data abort issue? Please check the data fault status register (DFSR) and data fault address register (DFAR) inside the CPU. What do these two registers indicate? It will give you clues on the cause of the abort.

0 cc liu over 8 years ago in reply to Charles Tsai

Expert 1150 points

Dear Charles
Sorry for the late reply. My projects work fine and thank you so much for your help.
Best Regards
Leo

Arm-based microcontrollers

Arm-based microcontrollers forum

selftest will block _enable_interrupt_();