I have the following setup on an RX63N:
0xFF7FC000 - User boot application
0xFFF40000 - New firmware image
0xFFFA0000 - Primary firmware image
My hope was to have the primary firmware image receive a new image via SPI and write it to the new image location and then reset using the software reset register. Then the user boot application would erase the primary image and copy the new image to the primary image location.
All of this is working except the software reset. I'm thinking that the RX63N doesn't go back through user boot on a software reset (or any other "internal reset").
Has any one else had any success with this?
If you do a hard reset does it then execute the boot loader followed by a jump to the new image or does it go straight to the new image or does the boot loader run but it fails when the new image is run?
Have you compiled the new image to target the FFFA0000 of the final destination that it will run from or the FFF40000 that it is loaded into
In reply to Paul Brown:
It does boot correctly on a hard reset. The bootloader correctly erases the primary image and writes the new image to the primary location then jumps to the primary image. I tried letting the watchdog timer trip and reset the board and that didn't work with user boot either.
I've given up on user boot at this point. Between this issue and another post I had about not being able to use either the Renesas E1 or the Segger J-Link to debug in user boot it wasn't worth the trouble.
I changed to using the top 8 or so sectors of flash for the bootloader with the same basic scheme as described in the original post. The only catch there is that the bootloader now owns the fixed vector table. I made a shared memory area for the primary firmware to "register" handlers for those exceptions. The bootloader looks for a valid handler in the shared memory and if it exists it calls it rather than its own handler.
In reply to tshannon:
Just in case you want to upgrade: The RX64M can also move the fixed vector table.