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
Ah, thanks, that must be it!
That also explains some of the issues I’ve had with running the debugger on the armclang/gcc mcuboot images :)
I have not implemented this.
Looks like I have work set out for me next week :)
/Thomas
Thomas Törnblom, Product Engineer IAR Systems AB Box 23051, Strandbodgatan 1x-apple-data-detectors://6/1 SE-750 23 Uppsala, SWEDENx-apple-data-detectors://6/1 Mobile: +46 76 180 17 80tel:+46%2076%20180%2017%2080 Fax: +46 18 16 78 01tel:+46%2018%2016%2078%2001 E-mail: thomas.tornblom@iar.commailto:thomas.tornblom@iar.com Website: www.iar.comhttp://www.iar.com/ Twitter: www.twitter.com/iarsystemshttp://www.twitter.com/iarsystems
27 sep. 2019 kl. 18:25 skrev Jamie Fox Jamie.Fox@arm.com:
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
--
*Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom@iar.com mailto:thomas.tornblom@iar.com Website: www.iar.com http://www.iar.com Twitter: www.twitter.com/iarsystems http://www.twitter.com/iarsystems -- TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m
tf-m@lists.trustedfirmware.org
-
Jamie Fox -
Thomas Törnblom