Hi Thomas,
One way this can happen is if the QSPI driver is being executed in place from QSPI, so the device is never idle because instructions are being fetched from it.
On Musca-A, MCUboot is copied to Code SRAM before being executed to avoid this issue. There is some code in the Armclang/GCC scatter/startup files to support this. Is there something similar implemented for the IAR port?
Best wishes, Jamie
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Thomas Törnblom via TF-M Sent: 27 September 2019 15:40 To: tf-m@lists.trustedfirmware.org Subject: [TF-M] Issues with qspi_ip6514e_set_spi_mode with IAR
I'm trying to bring up TF-M on the Musca A with IAR Embedded Workbench and I'm having issues in mcuboot where the boot hangs with the following stack: --- qspi_ip6514e_is_idle qspi_ip6514e_set_spi_mode set_spi_mode mt25ql_config_mode ARM_Flash_Initialize main [_call_main + 0xd] ---
Apparently the idle bit (31) in the qspi_cfg register (0x4010a000) never gets set so it loops there.
I have no programmers manual for the Cadence qspi ip6514e so I'm at a bit of a loss as to what the issue might be.
Obviously something is different between the images built with armclang and gcc, which works properly, and the image I've built with IAR.
Ideas anyone?
/Thomas