Invoking the Sam-ba Monitor

[3F800000]

Is it possible for my embedded software to invoke the Sam-ba monitor (BootROM) directly? I am concerned about burning fuses to allow booting from flash and not being able to update the firmware. (This is a development project, manufacturing concerns are a long ways off.)

Currently I'm using the backup registers to boot the QSPI flash and if I want to reprogram the part I simply have to cycle power and it enters the Sam-ba monitor. It will eventually be useful to program the device to boot to flash after a power cycle so I would need to burn fuses for that. But then I won't be able to update the firmware, right? So if that is the case I want to put a work around in my code to invoke the Sam-ba monitor. If that's not possible then perhaps I can just erase part of flash so the monitor runs on next reset/power cycle?

Thanks for any advice.

[blue_z]

Is it possible for my embedded software to invoke the Sam-ba monitor (BootROM) directly?

No, the ROM is not even mapped into the SoC address space once the boot program loads and executes an application.
The only way to keep the SAM-BA Monitor active would be the same mechanism as the SAM-BA utility.

But then I won't be able to update the firmware, right?
...
If that's not possible then perhaps I can just erase part of flash so the monitor runs on next reset/power cycle?

I don't quite follow what you're doing.
What SoC is this?

FYI whatever the SAM-BA Monitor can do, you could do the same in your program except you have to write (or adapt SoftPack code) and maintain it.

Regards

[3F800000]

SAMA5D27 SIP

We are developing a product based somewhat on the SAMA5D27 SOM1 Kit1.

Say I load an app into flash and burn the fuses to boot the QSPI. I can reset or cycle power and the ROM will execute my code.

Then I make some changes and I want to update the firmware in flash.

My JTAG ICE isn't functional now, right? I can't use sam-ba to modify flash since the sam-ba monitor isn't running, it's running my code.

I have avoided experimenting with burning fuses as I fear it will be bricked, i.e. I'll not be able debug and update.

[blue_z]

Currently I'm using the backup registers to boot the QSPI flash and if I want to reprogram the part I simply have to cycle power and it enters the Sam-ba monitor.

That probably works that way because there is no battery for VDDBU?

Say I load an app into flash and burn the fuses to boot the QSPI.

"Burn the fuses" is vague.
Whether or not you can override the fuses (with a BUREG and the BSC_CR) is one of the fuse bits!
BTW "load into flash" is awkward wording. A data transfer to nonvolatile memory is a "store" operation, and not a "load".

I can reset or cycle power and the ROM will execute my code.

Then I make some changes and I want to update the firmware in flash.

My JTAG ICE isn't functional now, right?

What is "now"?
The last identifiable system state seems to be "executing my code".

I can't use sam-ba to modify flash since the sam-ba monitor isn't running, it's running my code.

What is "it", SAM-BA Monitor?

I have avoided experimenting with burning fuses as I fear it loadwill be bricked, i.e. I'll not be able debug and update.

Another ambiguous use of the "it" pronoun".
So don't burn any fuses.

Regards

[3F800000]

If I program QSPI flash with a bootloader and an app, and then program the fuses with QSPI_0=QSPI_0_IOSET_3, I can turn off the power supply. Then when power is applied, the SAMA5D2 will execute the boot ROM sequence. In this case it will read the flash part on QSPI0, determine valid instructions are stored there, copy the bootloader to SRAM and execute it. Then, the bootloader will read the flash part on QSPI0 and copy code to another area of RAM and execute it. At that point my app is running on the SAMA5D2.

Now I make changes to my code, and want to reprogram the flash part on QPI0.

How can I do this? Prior to programming the flash part on QSPI0 with bootloader code and app, the SAMA5D2 would boot up and since no valid instructions were found on the flash part on QSPI0, the SAMA5D2 enters the SAM-BA monitor. But now the flash part on the QSPI0 interface of the SAMA5D2 is read on boot up, valid instructions are found, and SAM-BA monitor is not run; rather, the bootloader runs and invokes my app.

What options do I have (if any) to reprogram the flash part on QSPI0?

Thanks for any advice, and sorry if I am not clear, or if this is a dumb question. But so far I refuse to program the fuses since I fear I will brick a very expensive prototype board.

[blue_z]

Now I ... want to reprogram the flash part on QPI0.

How can I do this?
...
What options do I have (if any) to reprogram the flash part on QSPI0?

Yes, you're still not clear.
As already mentioned there are specific circumstances when you can or cannot continue to use the BUREGs to override the fuses.
You continue to ignore the status of DISABLE_BSCR and VDDBU.
As already mentioned there are means other than SAM-BA for erasing/writing flash.

Regards

[3F800000]

I'm not ignoring VDDBU, it is not deployed in our present design.

So it seems you're suggesting that if I command my app the erase the beginning of flash, on reset the SAMA5D2 will not find bootable flash, so it will run the SAM-BA monitor. Then I can program flash with updated firmware.