I'm currently working with TQMa117xL and use this bsp Already, we have a demo application with the default configuration explained in README.md. We can generate the binary with debug+ram and debug with Ozone debugger - Segger. The next step is to flash the device and boot from flash
To Reproduce
Environment (please complete the following information):
Steps to reproduce the behavior:
To flash the device, we recompile with debug+flash configuration and use MCUXpresso Secure Provisioning Tool with the necessary configuration to flash into TQMa117xL, we follow the normal process to upload the binary into flash, with burned fuses and boot mode needed. (This process is already tested with other binary generated with MCUXpresso Integrated Development Environment (IDE))
Expected behavior
The normal process in Secure Provisioning return a SUCCESS result, but when we reboot the board with Internal Boot mode, the binary is not loaded and the board have not code loaded.
Is it needed an additional process to flash the board?
Please let me know if you need additional information.
Hi @Jandro20, this BSP/board seems not be released by official NXP, thus our development team does not have the environment to support the issue, it will be closed.
Describe the bug Hello
I'm currently working with TQMa117xL and use this bsp Already, we have a demo application with the default configuration explained in README.md. We can generate the binary with debug+ram and debug with Ozone debugger - Segger. The next step is to flash the device and boot from flash
To Reproduce
Expected behavior
The normal process in Secure Provisioning return a SUCCESS result, but when we reboot the board with Internal Boot mode, the binary is not loaded and the board have not code loaded.
Is it needed an additional process to flash the board?
Please let me know if you need additional information.
Thanks!