Report
2 years, 4 months ago.

uvisor and FlashIAP on K64F board

Hello, I am trying to write one page in flash after erasing a sector with uvisor enabled with K64F board. I am erasing in the public box. I was getting this error:

HALT_ERROR(./core/vmpu/src/vmpu.c#431): This is not the PC (0x2000A08A) your were searching for

After debugging, I found that there was a bus fault with accessing Watchdog and Flash Controller registers by the Flash_ALGO code. So I included the following peripherals in the MAIN ACL list:

{WDOG, sizeof(*WDOG), UVISOR_TACLDEF_PERIPH}, \ {FTFE, sizeof(*FTFE), UVISOR_TACLDEF_PERIPH}, \

But now, after debugging, on the flash erase call, the debugger simply resets the board and I hit the main() entry point again. I checked whether the WAtchdog has reset the board, but when I read the WDOG_STCTRLL register, the INTFLG was not set.

Any clue of whats happening?

Regards, Jain.

Comment on this question

1 Answer

2 years, 4 months ago.

Hello Jain,

This issue might be caused by several factors and is not necessarily due to uVisor.

The first thing you can try is to check if there is any call to NVIC_SystemReset. Alternatively, a "reset" might be observed if a broken value is being loaded into the program counter, for example by a `ldr` or a `pop` instruction that loads a very small number into the program counter (thus effectively hitting the reset handler). Executing the reset handler doesn't necessarily mean that the system was reset, though. Also, keep in mind that because you are re-writing flash (which is done by executing from SRAM), as soon as you try and execute back from flash, you could hit a location in code that had been overwritten.

If you have access to single stepping you could find the instruction where the code goes from SRAM back to flash and check the program counter.

The issue might depend on uVisor if you set up a uVisor debug box. A debug box resets the system automatically when a critical fault is hit. Under normal circumstances, uVisor halts the system, so you shouldn't observe a reset because of a fault.

Finally, a reset might be triggered by the debugger itself to exit a lockup. Lockup is entered if a fault occurs when executing the NMI or HardFault handlers, so to check this you could put a breakpoint on the hard fault handler.

Let me know if any of these ideas work. It will be very helpful to identify the instruction that triggers the reset by single-stepping into the code.


You need to log in to post a question