ClockInit Bootloader issues

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

cross mob
efor
Level 2
Level 2
10 sign-ins 5 replies posted 5 sign-ins

Hello All,

In my latest project I have implemented a bootloader using the DFU source code. I have changed from using a UART/SPI to some NVM that requires a PLL in order to copy my app1 onto the flash and this part of my project works well. My issues arises once I switch into my app1.  I use the Debug-> Attach to running target in order to test my app1. It seems to be getting stuck in the ClockInit function in cyfitter_cfg.c where it does:

status = Cy_SysClk_PllManualConfigure(1u, &pllConfig);

I have found a small patch for my issue by adding in:

Cy_SysClk_PllDisable(1u);

Onto the line directly before configure line and this seems to fix my problem. However, this is from the PSoC generated source (I believe) so if any top design changes are made I would have to re-enter this line to allow my code to work again. I know there is the CyClockStartupError function which contains 

CY_CFG_Clock_Startup_ErrorCallback();

Which looks like a possible solution to my problem but I have no clue how to implement that functionality there or if it is the correct spot.

To summarize:

When I use a PLL on app0 and app1, app1 will lock unless I disable the PLL before starting it. I have tested it and the patch works but I don't know how to implement it such that it doesn't disappear when I need files regenerated.  Could anybody give me some advice or direction as to how I should proceeded or what documentation to look at in order to implement this correctly?

Thanks!

0 Likes
1 Solution

Hello Alakananda,

Interestingly enough I found a solution to my problem with enough digging on the community site. So in short terms the answer for my app1 problem lied in app0 and this post explains it clearly:

CYBLE-416045-02 app1 does not start 

To go more into depth, the problem with my clocks not starting was a red herring. I quickly found out after this post that none of my pdl was starting with the hack that I had found to start the clock. So, I then figured it was something with the way I was starting app1 and I couldn't understand the difference between Cy_DFU_ExecuteApp and Cy_Bootload_SwitchToApp. That is when I found the linked post and it appears to be a solution to my problem.

My final comment on this topic is that there should be more clear documentation about the necessity of including this handler in a bootloader project so that your code doesn't fail upon start. Or if it is in the documentation it should be more clear because I was able to easily miss it.

Thanks!

View solution in original post

0 Likes
2 Replies
Alakananda_BG
Moderator
Moderator
Moderator
50 likes received 250 sign-ins 250 replies posted

Hi,

Can you please share your project so that we can have a clear understanding about the issue.

Regards

Alakananda
0 Likes

Hello Alakananda,

Interestingly enough I found a solution to my problem with enough digging on the community site. So in short terms the answer for my app1 problem lied in app0 and this post explains it clearly:

CYBLE-416045-02 app1 does not start 

To go more into depth, the problem with my clocks not starting was a red herring. I quickly found out after this post that none of my pdl was starting with the hack that I had found to start the clock. So, I then figured it was something with the way I was starting app1 and I couldn't understand the difference between Cy_DFU_ExecuteApp and Cy_Bootload_SwitchToApp. That is when I found the linked post and it appears to be a solution to my problem.

My final comment on this topic is that there should be more clear documentation about the necessity of including this handler in a bootloader project so that your code doesn't fail upon start. Or if it is in the documentation it should be more clear because I was able to easily miss it.

Thanks!

0 Likes