I think the software reset is required because all the hardware settings for the components including the wiring is done at reset. What is the reason you want to just "jump" to application?
Thanks for your reply. I am developing hitless module. It required module keep working during application firmware upgrade. So I do expect the hardware no reset, the pin status and DAC output keep no change.
Like STM32F4xx MCU, It can be jumped to application or bootloader without software reset. Just set MSP, jump to application and relocate system interrupt vector is OK. why seems cypress MCU can't work after do the same operation?
Bob's answer makes a lot of sense since the PSoC has no 'real' HW until the registers are configured for your application. Unlike the STM32F4xx CPU which is defined at birth with all the components it will ever have, the PSoC is flexible.
However, I believe I understand your desire.
Question: After you load the 'new' code with your bootloader, where do you want to 'jump' to?
If you jump to main(), which is possible, you bypass the HW configuration code prior to main(). The difficulty is that early in the main() code you probably initialize and start your components including your DAC and your pins. You'd have to make sure that the component initialization stage will support this. Also, a straight jump into main() can be dangerous since the stack pointer needs to be adjusted to the correct value otherwise multiple bootload events can possibly create a stack overrun. Note: You may want to launch the bootloader from the main() level of code.
The other difficulty with what you are looking to do is that once you've define the components you plan on using at bootloader compile time, these are the components that remain in the PSoC for its lifetime. This includes some component configuration values and routing.
If the statement in the above paragraph will be a problem, you might want to consider a bootloader with multiple loading options. If your bootloader keeps the components the same and the run time values are retained, you can jump to main(). If you need to change your components and/or internal routing, you need to jump to the Reset vector.
The old PSoC1 had the ability in SW from the PSoC Designer to have multiple HW configurations that can be changed at run-time. These PSoCs are substantially more complicated to configure but significantly more flexible. Ahh. The good ol' days!
I've never needed to jump directly into main(), but I did modify bootloader code to allow me to either perform a full bootload of application code (jump to Reset vector) or load only calibration parameters into FLASH while the current application is running. This last bootload type can be tricky and it does require that you have all your calibration parameters isolated from App code in their own FLASH pages. You don't want to accidentally write App code.
I shall share some guidelines for your application. As you would like to retain pin states as well as the internal states of the firmware IPs during transition, the bootloadable pre-main code should not be executed. The new image code needs to start being executed from the bootloadable main() function.
To have the exact same initialization code, the TopDesign and pinout must be identical between the two images. Also, the CyDWR configuration needs to be the same. Both images should have the same number of interrupts and the same interrupt handlers.
The location of the interrupt handlers might change in the new image. Hence, user needs to initialize the interrupt vector to make sure they are pointing to the correct functions. The interrupts should be disabled before switching to the new image, and re-enabled after initializing the interrupt vector.
Thank GeonaM_26 for your reply. It's almost clear about the implementation. One more question, how to avoid executing bootloadable pre-main code?