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.
Invoking the Sam-ba Monitor
Moderator: nferre
- blue_z
- Location: USA
Post
The only way to keep the SAM-BA Monitor active would be the same mechanism as the SAM-BA utility.
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
Re: Invoking the Sam-ba Monitor
No, the ROM is not even mapped into the SoC address space once the boot program loads and executes an application.3F800000 wrote: ↑Is it possible for my embedded software to invoke the Sam-ba monitor (BootROM) directly?
The only way to keep the SAM-BA Monitor active would be the same mechanism as the SAM-BA utility.
I don't quite follow what you're doing.3F800000 wrote: ↑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?
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
Post
Re: Invoking the Sam-ba Monitor
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.
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
- Location: USA
Post
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".
The last identifiable system state seems to be "executing my code".
So don't burn any fuses.
Regards
Re: Invoking the Sam-ba Monitor
That probably works that way because there is no battery for VDDBU?3F800000 wrote: ↑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.
"Burn the fuses" is vague.3F800000 wrote: ↑Say I load an app into flash and burn the fuses to boot the QSPI.
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".
What is "now"?3F800000 wrote: ↑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?
The last identifiable system state seems to be "executing my code".
What is "it", SAM-BA Monitor?3F800000 wrote: ↑ I can't use sam-ba to modify flash since the sam-ba monitor isn't running, it's running my code.
Another ambiguous use of the "it" pronoun".3F800000 wrote: ↑I have avoided experimenting with burning fuses as I fear it loadwill be bricked, i.e. I'll not be able debug and update.
So don't burn any fuses.
Regards
Post
Re: Invoking the Sam-ba Monitor
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.
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
- Location: USA
Post
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
Re: Invoking the Sam-ba Monitor
Yes, you're still not clear.3F800000 wrote: ↑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?
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
Post
Re: Invoking the Sam-ba Monitor
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.
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.
Return to “SAMA5D Cortex-A5 MPU”
Who is online
Users browsing this forum: No registered users and 1 guest