I am developing dual core application on BF609 revision 0.2 under CCES 2.8.3
Core A runs under RTOS, Core B is bare metal H.264 encoder.
After the initialization everything works fine. Both cores work properly.
When I am trying to reset the core B by a core A a parity error occurs:
A non-recoverable error or exception has occurred. Description: Parity error in L1 data bank A cache General Type: ParityError Specific Type: DataBankACache Error PC: 0xc80bf182
The core B reset code looks as below:
/* Clear CORE B reset status bit */ *pREG_RCU0_CRSTAT = BITM_RCU_CRSTAT_CR1 ;
/* Disable system interfaces for CORE B */ *pREG_RCU0_SIDIS = BITM_RCU_SIDIS_SI1 ;
while ((*pREG_RCU0_SISTAT & BITM_RCU_SISTAT_SI1) == 0) ;
/* Reset CORE B */ adi_core_1_disable() ;
while ((*pREG_RCU0_CRSTAT & BITM_RCU_CRSTAT_CR1) == 0) ;
/* Re-enable system interfaces for CORE B */ *pREG_RCU0_SIDIS = 0 ;
/* Take CORE B out of reset */ adi_core_1_enable() ;
Anyone can help me in solving my issue
Hi,While looking into your query , we understand that you are trying to reset the core B by a core A runs under RTOS. While executing you are receiving a parity error. Please correct us if our understanding is wrong.For further assistance , can you please get back to the below information.1) While executing your application, exactly in which place the exception hits? Could you please try to step-through the code and let us know the observations.2) Were you facing the issue in ADSP-BF609 Ezkit or Custom Board? 3) If possible can you please share the screenshot of SEQSTAT register.BTW, it is mentioned in the Blackfin Processor Programming Reference, under section "Detection and Notification" (Page No: (339 / 1106)), Parity errors are checked for whenever L1 memory is read. Parity checking is distributed so that all simultaneous L1 read traffic (DAG reads, instruction reads, DMA reads, and victim reads) can be simultaneously examined. If a parity error is detected during any L1 read, an “L1 Memory Parity Error” is immediately signaled to the appropriate processor core, even if the read is speculative in nature.L1 reads bound for the processor (which include instruction fetch, data fetch, and ITEST/DTEST_COMMAND- triggered reads) are intercepted before they lead to further consequences. When these are detected, the processor receives an NMI, immediately stalls, and remains stalled until it vectors in response to the NMI. This guarantees that processor state is not modified based on corrupted L1 memory state, and the processor cannot, in turn, modify system state based on corrupted L1 memory.Please note that under the "ADSP-BF60x L1 Parity Errors and Reporting", it is mentioned that "Bits in the SEQSTAT register indicate which categories of errors were found"For more information, please refer the "Parity Error Handling"(Page No:(333 / 1106)) in the ADSP-BF60x Blackfin+ Processor Programming Reference manual. The link is given below.www.analog.com/.../Blackfin_pgr_rev2.2.pdfNotification of all current outstanding parity errors is provided by four PExx bits in the SEQSTAT register. One bit exists for each combination of L1 memory space (Instruction versus Data) and read destination (Processor versus L2). These bits reflect the current logical OR of associated L1 array parity error status bits. If determining Cache versus SRAM association is important, this information must be discerned by cross-referencing the array reported by the L1 Bank Parity Error Location register (L1_xBNKx_PELOC),with a knowledge of which L1 arrays are allocated to serve as cache (based on cache size).The location of a parity error can be determined by inspecting the SEQSTAT register in combination with the Instruction Memory Parity Error Status (SEQSTAT.PEIC) or Data Memory Parity Error Status (SEQSTAT.PEDC) registers.Regards,Anand Selvaraj.
Thank you for response and sorry for not being precised describing my issue.
I am trying to reset the core B by a core A running under RTOS.
The platform is a custom board.
Please find attached below screenshot of SEQSTAT register.
The parity error occurs only on core B while executing code in "app_startup.s" file. Core A is still running correctly.
Exactly the parity error occurs executing the following sequence in "app_startup.s" file:
// initialize the CPLBs if they're needed. This was not possible // before we set up the stacks. R0 = 63; // cplb_ctrl = 63 .EXTERN _cplb_init; .TYPE _cplb_init,STT_FUNC; CALL.X _cplb_init;
It seems to me as strange behavior because this code was executed correctly after power-up and now after reseting core B it suffers execution error.
Before reseting core B the program code on both cores runs correctly and data exchange between both cores performs without any problem. However for testing purpose I executed on core B very basic loop to avoid any side effects. All interrupts are switched off.
The previously described error occured when I switched off instruction cache parity checking. Now, with original contents of the "app_startup.s" file the following message appears:
A non-recoverable error or exception has occurred. Description: Parity error in L1 instruction bank C cache General Type: ParityError Specific Type: InstrBankCCache Error PC: 0xc80bf1c0
Hi Michał,Thanks for getting back with more details.There are two Silicon Anomalies listed 16000041(IFLUSH Instruction Causes Parity Error When Parity Is Enabled) and 16000042(Instruction Cache Failure When Parity Is Enabled). Can you please confirm if you are not hitting any of these?The link for downloading the Anomaly sheet is given below.www.analog.com/.../ADSP-BF60x-anomaly.pdfBTW, is it possible for you share a minimal project to replicate the issue on ADSP-BF609 Ez-kit? Regards,Anand Selvaraj.
I am not using IFLUSH instruction in any part of my code.
In my opinion the issue is easily replicable in any code running on Core B (ex. simple loop). It is enough to enable running Core B by a Core A and after certain period reset Core B by a sequence described above in my first post. If you wil not be able to replicate the issue I will send you whole Core B project.
Hello,Sorry for delayed response. Is it possible for you to test this in Ez-Kit? (or) Please share a complete project to replicate the issue on ADSP-BF609 Ez-kit? Regards,Lalitha.S