Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

PSoC™ 5, 3 & 1 Forum Discussions

KyTr_1955226
Level 6
50 solutions authored 250 replies posted 100 replies posted
Level 6

Hi all,

I have a kind of unique problem that I'm hunting for solutions on.

I'm using a PSoC5LP as a COM Express carrier board controller, handling ATX power sequencing as well as other low-level functions.  One of the features of this carrier board controller is the ability to be loaded via bootloader from the host COM Express module OS.  I have the process of loading working correctly.  The bootloader is entered when a certain button combination is held while DC power is applied to the system.  But one little gotcha is the reset/jump to application after the loading is complete (with either a pass or a fail).

The issue is that when a load fails partway through, or completes successfully, there is no way to actually tell the result on the host OS because the system immediately resets (since the PSoC5 is controlling the ATX power sequencing).  A reset of the PSoC results in cutting power to the COM Express module as it restarts.

What I'm looking for is a way to either delay or entirely prevent the bootloader from automatically jumping to the application after it completes in order to allow the status to be communicated back to the user, or in the case of a successful load, allow the user to cleanly shut down the COM Express OS before manually cycling power to return to normal operation.

The only way I've come up with is to manually insert a delay before the CySoftwareReset() calls in the API functions such as Bootloader_Exit()/CyBtldr_CheckLaunch()/Bootloader_LaunchApplication(), etc.  If I want to prevent jumping to the application entirely I could just remove the CySoftwareReset() calls.  This is not ideal since as soon as code is regenerated for any reason, these modifications will presumably be removed.  One option could be to make these changes then use the "Suppress API Generation" option in the Bootloader module settings to lock it in place.

Are there any other options I'm missing?  Would I basically be stuck with the plan above or could there be a cleaner way to accomplish what I'm looking to do?

Thanks in advance for the input!

0 Likes
1 Solution
KyTr_1955226
Level 6
50 solutions authored 250 replies posted 100 replies posted
Level 6

Yes, that's the idea I had in the OP, and what I'm currently doing:


The only way I've come up with is to manually insert a delay before the CySoftwareReset() calls in the API functions such as Bootloader_Exit()/CyBtldr_CheckLaunch()/Bootloader_LaunchApplication(), etc. If I want to prevent jumping to the application entirely I could just remove the CySoftwareReset() calls. This is not ideal since as soon as code is regenerated for any reason, these modifications will presumably be removed. One option could be to make these changes then use the "Suppress API Generation" option in the Bootloader module settings to lock it in place.

In my case I ended up completely removing the CySoftwareReset() calls so that the bootloader will spin in place after a completed/failed load and will allow the user to cleanly shut down the OS and power cycle the system.

The downside to this solution being that any changes to the Bootloader component will clobber any changes I make to the API.  The workaround being to Suppress API Generation for the Bootloader component, and including the previously generated API in the project manually.  Not ideal, but it works I suppose and I'll just have to manually merge any changes to Bootloader configuration.

View solution in original post

0 Likes
3 Replies
Alakananda_BG
Moderator
Moderator 250 sign-ins 250 replies posted 100 solutions authored
Moderator

Hi @KyTr_1955226 ,

You can use a delay before the CySoftwareReset() calls in the API functions  to prevent the bootloader from automatically jumping to the application.

Regards,

Alakananda
0 Likes
KyTr_1955226
Level 6
50 solutions authored 250 replies posted 100 replies posted
Level 6

Yes, that's the idea I had in the OP, and what I'm currently doing:


The only way I've come up with is to manually insert a delay before the CySoftwareReset() calls in the API functions such as Bootloader_Exit()/CyBtldr_CheckLaunch()/Bootloader_LaunchApplication(), etc. If I want to prevent jumping to the application entirely I could just remove the CySoftwareReset() calls. This is not ideal since as soon as code is regenerated for any reason, these modifications will presumably be removed. One option could be to make these changes then use the "Suppress API Generation" option in the Bootloader module settings to lock it in place.

In my case I ended up completely removing the CySoftwareReset() calls so that the bootloader will spin in place after a completed/failed load and will allow the user to cleanly shut down the OS and power cycle the system.

The downside to this solution being that any changes to the Bootloader component will clobber any changes I make to the API.  The workaround being to Suppress API Generation for the Bootloader component, and including the previously generated API in the project manually.  Not ideal, but it works I suppose and I'll just have to manually merge any changes to Bootloader configuration.

0 Likes
Alakananda_BG
Moderator
Moderator 250 sign-ins 250 replies posted 100 solutions authored
Moderator

Hi @KyTr_1955226 ,

Yes, you have to manually merge the changes to the Bootloader configuration.

Regards,

Alakananda
0 Likes