ProSolutions

Problem 1:

When testing sending serial text file through terminal, the serial task id is changed with idle task. I doubted that any interrupt occurs inside the critical section.

Solution: Inside the SVC, interrupt occured. The SVC priority setting was wrong. Instead of higher priority, lowest priority was set. So, interrupt occured inside. Just check any changed done in code.

Problem 2:

When _dispatch? function is step-executed using EWARM in Cortex-M0+ kernel till the end of the function and run, hardfault exception occurs.

Solution: The Cortex-M0+ kernel is using PendSV and the exception does not jump to PendSV_Handler while step-executing even when PendSV request is pending. When you run, the PendSV occurs in unexpected location and the PendSV handler performs the context switch and returns assuming the original location, the register values might have corrupted. So, excetion occurs. Thus, this does not mean the software issue, instead the debugger setting maybe, to allow branching to PendSV handler immediately.

Problem 3:

Abort at the entrance of MainTask in Arm. There are no specific instructions causing them.

Solution: Acutally, in the CPSR, the A flag which Disables the Asynchronous Aborts has delayed the abort exception from the actual location of abort. So, try to Make the A flag to 0 at starting of the program, so that you can find the exact location and cause. In Cortex-A52, the master MPU program needs to be done from CPU0. Since I tried to program it in CPU1, it caused it. But, since inside the kernel, the A flag was 1, it did not occur there. Once entered MainTask with A flag 0, it caused exception.

Problem 4:

I was trying to FPGA program the Agilex 7 F series evaluation board. But, it failed.

Solution: Installed the Agilex 7 device support. After that I could program the FPGA using the board test software (BTS) provided .sof files. But, not my own .sof. Because when looking at the design provided by FPGA design store, it was for another board of same Agilex 7 F device. Look carefully at the board type.

Problem 5:

When debugging Nios V, the exeuction goes to Enviornment call easily, though there is no interrupt enabled at that point.

Solution: Do not doubt the interrupt. That means it is exception. Please check mepc register to know about from where the exception occurred.